Flex’s IIAS for Merchants Explained with IRS Rules
Benjamin Cole
Head of Compliance
Updated: February 20, 2026
The IRS concept behind IIAS: Substantiation
When consumers use tax-advantaged accounts like FSAs and HRAs, these employer-sponsored plans must be able to show that reimbursed amounts were for qualified medical care expenses. The same is true for HSAs, though these accounts are owned by the individual.
The IRS first issued guidance on card-based payments with Revenue Ruling 2003-43 which outlines the core framework that certain transactions can be auto-substantiated at the point of sale, while others require follow-up verification and correction procedures (often called “pay and chase”).
This revenue ruling originally positions the burden of substantiation on Employers to substantiate purchases and/or impose limitations to where cards could be used. It also mandates that Employees retain sufficient documentation for any expense paid including invoices and receipts.
What does the IRS mean by “IIAS”?
Several years later, the IRS issued Notice 2006-69 to provide further guidance to clarify substantiation methods and requirements and formally introduced IIAS (Inventory Information Approval System).
IIAS exists because the IRS recognized that general retail environments sell a mix of eligible and ineligible items—and card-based payments must prevent ineligible spend from being treated as tax-free medical reimbursement.
The IRS definition of IIAS in Notice 2006-69 is straightforward: IIAS is a system provided by the payment card processor for approving and rejecting card transactions using inventory control information (SKUs, UPCs, GTINs, etc.) with merchants who aren’t exclusively health care providers.
At checkout, an IIAS-enabled flow does three key things:
Collect item-level inventory data (e.g. SKU) for what’s being purchased
Compare those SKUs to a list of items that qualify as medical care expenses under IRC §213(d)
Total the qualified eligible expenses and approve the card only for the eligible subtotal
If the cart contains a non-eligible expense subtotal, the system must support a split-tender transaction where the customer pays the remaining (non-eligible) balance with another payment method.
In essence, IIAS is specific functional behavior at checkout: product/service level eligibility + eligible-only approval + split-tender for mixed carts + audit-ready records.
Who needs an IIAS?
Shortly after the release of Notice 2006-69, the IRS published another Notice 2007-2, establishing a path for merchants that are not traditional healthcare providers to accept HSA/FSA debit card payments.
Non-healthcare MCC merchants
All merchants have what is called a merchant category code or MCC which is assigned to them by their acquiring bank or payment processor. After December 31st, 2007, FSA/HSA and HRA cards could no longer be used at stores without healthcare-related merchant category codes unless the merchant implemented an IIAS.
Drug Stores & Pharmacies MCC (and the “90% rule”)
Even at drug stores and pharmacies, the IRS recognized that many locations sell substantial non-medical inventory. The IRS guidance provides that (after the applicable effective date) FSA/HSA/HRA cards may not be used at Drug Stores & Pharmacies MCC locations unless:
the store participates in IIAS, or
the store meets the “90% rule” (90% of gross receipts are from §213(d) medical items, measured location-by-location).
It’s also important that the 90% rule doesn’t magically eliminate substantiation work. IRS guidance indicates that many charges at 90%-rule stores must still be treated as conditional pending additional third-party information—i.e., the “pay-and-chase” model—except for specific auto-substantiation categories (copay matches, recurring, real-time substantiation).
For large ecommerce merchants, IIAS is typically the scalable path because it enables real-time, item-level gating, and avoids turning your customer experience into a manual substantiation workflow.
When consumers use tax-advantaged accounts like FSAs and HRAs, these employer-sponsored plans must be able to show that reimbursed amounts were for qualified medical care expenses. The same is true for HSAs, though these accounts are owned by the individual.
The IRS first issued guidance on card-based payments with Revenue Ruling 2003-43 which outlines the core framework that certain transactions can be auto-substantiated at the point of sale, while others require follow-up verification and correction procedures (often called “pay and chase”).
This revenue ruling originally positions the burden of substantiation on Employers to substantiate purchases and/or impose limitations to where cards could be used. It also mandates that Employees retain sufficient documentation for any expense paid including invoices and receipts.
What does the IRS mean by “IIAS”?
Several years later, the IRS issued Notice 2006-69 to provide further guidance to clarify substantiation methods and requirements and formally introduced IIAS (Inventory Information Approval System).
IIAS exists because the IRS recognized that general retail environments sell a mix of eligible and ineligible items—and card-based payments must prevent ineligible spend from being treated as tax-free medical reimbursement.
The IRS definition of IIAS in Notice 2006-69 is straightforward: IIAS is a system provided by the payment card processor for approving and rejecting card transactions using inventory control information (SKUs, UPCs, GTINs, etc.) with merchants who aren’t exclusively health care providers.
At checkout, an IIAS-enabled flow does three key things:
Collect item-level inventory data (e.g. SKU) for what’s being purchased
Compare those SKUs to a list of items that qualify as medical care expenses under IRC §213(d)
Total the qualified eligible expenses and approve the card only for the eligible subtotal
If the cart contains a non-eligible expense subtotal, the system must support a split-tender transaction where the customer pays the remaining (non-eligible) balance with another payment method.
In essence, IIAS is specific functional behavior at checkout: product/service level eligibility + eligible-only approval + split-tender for mixed carts + audit-ready records.
Who needs an IIAS?
Shortly after the release of Notice 2006-69, the IRS published another Notice 2007-2, establishing a path for merchants that are not traditional healthcare providers to accept HSA/FSA debit card payments.
Non-healthcare MCC merchants
All merchants have what is called a merchant category code or MCC which is assigned to them by their acquiring bank or payment processor. After December 31st, 2007, FSA/HSA and HRA cards could no longer be used at stores without healthcare-related merchant category codes unless the merchant implemented an IIAS.
Drug Stores & Pharmacies MCC (and the “90% rule”)
Even at drug stores and pharmacies, the IRS recognized that many locations sell substantial non-medical inventory. The IRS guidance provides that (after the applicable effective date) FSA/HSA/HRA cards may not be used at Drug Stores & Pharmacies MCC locations unless:
the store participates in IIAS, or
the store meets the “90% rule” (90% of gross receipts are from §213(d) medical items, measured location-by-location).
It’s also important that the 90% rule doesn’t magically eliminate substantiation work. IRS guidance indicates that many charges at 90%-rule stores must still be treated as conditional pending additional third-party information—i.e., the “pay-and-chase” model—except for specific auto-substantiation categories (copay matches, recurring, real-time substantiation).
For large ecommerce merchants, IIAS is typically the scalable path because it enables real-time, item-level gating, and avoids turning your customer experience into a manual substantiation workflow.
When consumers use tax-advantaged accounts like FSAs and HRAs, these employer-sponsored plans must be able to show that reimbursed amounts were for qualified medical care expenses. The same is true for HSAs, though these accounts are owned by the individual.
The IRS first issued guidance on card-based payments with Revenue Ruling 2003-43 which outlines the core framework that certain transactions can be auto-substantiated at the point of sale, while others require follow-up verification and correction procedures (often called “pay and chase”).
This revenue ruling originally positions the burden of substantiation on Employers to substantiate purchases and/or impose limitations to where cards could be used. It also mandates that Employees retain sufficient documentation for any expense paid including invoices and receipts.
What does the IRS mean by “IIAS”?
Several years later, the IRS issued Notice 2006-69 to provide further guidance to clarify substantiation methods and requirements and formally introduced IIAS (Inventory Information Approval System).
IIAS exists because the IRS recognized that general retail environments sell a mix of eligible and ineligible items—and card-based payments must prevent ineligible spend from being treated as tax-free medical reimbursement.
The IRS definition of IIAS in Notice 2006-69 is straightforward: IIAS is a system provided by the payment card processor for approving and rejecting card transactions using inventory control information (SKUs, UPCs, GTINs, etc.) with merchants who aren’t exclusively health care providers.
At checkout, an IIAS-enabled flow does three key things:
Collect item-level inventory data (e.g. SKU) for what’s being purchased
Compare those SKUs to a list of items that qualify as medical care expenses under IRC §213(d)
Total the qualified eligible expenses and approve the card only for the eligible subtotal
If the cart contains a non-eligible expense subtotal, the system must support a split-tender transaction where the customer pays the remaining (non-eligible) balance with another payment method.
In essence, IIAS is specific functional behavior at checkout: product/service level eligibility + eligible-only approval + split-tender for mixed carts + audit-ready records.
Who needs an IIAS?
Shortly after the release of Notice 2006-69, the IRS published another Notice 2007-2, establishing a path for merchants that are not traditional healthcare providers to accept HSA/FSA debit card payments.
Non-healthcare MCC merchants
All merchants have what is called a merchant category code or MCC which is assigned to them by their acquiring bank or payment processor. After December 31st, 2007, FSA/HSA and HRA cards could no longer be used at stores without healthcare-related merchant category codes unless the merchant implemented an IIAS.
Drug Stores & Pharmacies MCC (and the “90% rule”)
Even at drug stores and pharmacies, the IRS recognized that many locations sell substantial non-medical inventory. The IRS guidance provides that (after the applicable effective date) FSA/HSA/HRA cards may not be used at Drug Stores & Pharmacies MCC locations unless:
the store participates in IIAS, or
the store meets the “90% rule” (90% of gross receipts are from §213(d) medical items, measured location-by-location).
It’s also important that the 90% rule doesn’t magically eliminate substantiation work. IRS guidance indicates that many charges at 90%-rule stores must still be treated as conditional pending additional third-party information—i.e., the “pay-and-chase” model—except for specific auto-substantiation categories (copay matches, recurring, real-time substantiation).
For large ecommerce merchants, IIAS is typically the scalable path because it enables real-time, item-level gating, and avoids turning your customer experience into a manual substantiation workflow.
The reality: IIAS is easy to describe and hard to run
For enterprise merchants seeking to accept HSA/FSA payments directly, there isn’t a clear cut playbook to establishing an IRS-compliant IIAS. Even the ones that can figure it out, will still need to overcome the operational complexity associated with building one out. Some of the biggest challenges merchants can face when setting up and maintaining an IRS-compliant IIAS include:
SKU governance at scale: new products, discontinued SKUs, and variant proliferation
Bundles and kits: mixed eligibility inside a single “product” page
Substitutions: what ships vs what was ordered
Returns and partial refunds: keeping the substantiation trail consistent
Mixed baskets: ensuring split-tender is seamless and conversion-friendly
Evidence and retention: being able to produce an audit-ready record of what happened
The IRS also notes that employers using an IIAS are still responsible for complying with applicable requirements, including recordkeeping, and points to IRS electronic record guidance for systems that maintain records in automatic data processing environments.
This is where many enterprise teams decide: either build and maintain a substantiation-grade eligibility engine internally—or partner with a provider built for it. That’s where Flex can help.
For enterprise merchants seeking to accept HSA/FSA payments directly, there isn’t a clear cut playbook to establishing an IRS-compliant IIAS. Even the ones that can figure it out, will still need to overcome the operational complexity associated with building one out. Some of the biggest challenges merchants can face when setting up and maintaining an IRS-compliant IIAS include:
SKU governance at scale: new products, discontinued SKUs, and variant proliferation
Bundles and kits: mixed eligibility inside a single “product” page
Substitutions: what ships vs what was ordered
Returns and partial refunds: keeping the substantiation trail consistent
Mixed baskets: ensuring split-tender is seamless and conversion-friendly
Evidence and retention: being able to produce an audit-ready record of what happened
The IRS also notes that employers using an IIAS are still responsible for complying with applicable requirements, including recordkeeping, and points to IRS electronic record guidance for systems that maintain records in automatic data processing environments.
This is where many enterprise teams decide: either build and maintain a substantiation-grade eligibility engine internally—or partner with a provider built for it. That’s where Flex can help.
For enterprise merchants seeking to accept HSA/FSA payments directly, there isn’t a clear cut playbook to establishing an IRS-compliant IIAS. Even the ones that can figure it out, will still need to overcome the operational complexity associated with building one out. Some of the biggest challenges merchants can face when setting up and maintaining an IRS-compliant IIAS include:
SKU governance at scale: new products, discontinued SKUs, and variant proliferation
Bundles and kits: mixed eligibility inside a single “product” page
Substitutions: what ships vs what was ordered
Returns and partial refunds: keeping the substantiation trail consistent
Mixed baskets: ensuring split-tender is seamless and conversion-friendly
Evidence and retention: being able to produce an audit-ready record of what happened
The IRS also notes that employers using an IIAS are still responsible for complying with applicable requirements, including recordkeeping, and points to IRS electronic record guidance for systems that maintain records in automatic data processing environments.
This is where many enterprise teams decide: either build and maintain a substantiation-grade eligibility engine internally—or partner with a provider built for it. That’s where Flex can help.
How Flex meets IIAS requirements on behalf of enterprise merchants
Flex’s payment processor was designed to operationalize the IRS’s IIAS requirements within modern ecommerce checkout—without forcing merchants to develop SKU-level substantiation infrastructure.
Here’s how Flex’s payment processor maps to the IRS functional requirements:
1) SKU-level eligibility decisioning aligned to §213(d)
IIAS requires collecting inventory control information (SKUs) and comparing them to a qualifying list under §213(d).
Flex does this by making eligibility determinations for all of our merchants products/services according to §213(d) and assigning that eligibility down to the product level using both a unique Flex ID as well as the products UPCs and/or GTIN to ensure consistency in eligibility across merchants.
This logic powers our merchants’ checkout to determine, at the point of sale, what portion of the cart is eligible according to §213(d).
2) Eligible-only approval
The IRS requirement is to approve the card only for the amount of §213(d) medical expenses. Flex authorizes HSA/FSA payment only for the eligible subtotal, preventing over-approval.
3) Split-tender support for mixed carts
When only part of the transaction is eligible, the customer must tender the remainder separately (split-tender).
Flex enables a single checkout flow where customers are prompted to enter their HSA/FSA card for eligible amounts and a credit/debit cart for non-eligible eligible amounts all without forcing two separate orders.
4) Audit-ready records and data retention
IRS guidance emphasizes that required information may need to be retained and that electronic recordkeeping principles apply. Flex maintains the Flex Eligible Catalogue, which contains all eligible and non-eligible products/services across all merchants in our system.
Our eligibility determinations are always mapped back to IRC §213(d). We also maintain all transaction decisioning evidence as well as documentation to support both Merchants, Customers, and HSA/FSA Administrators in audits and operational reviews.
Flex’s payment processor was designed to operationalize the IRS’s IIAS requirements within modern ecommerce checkout—without forcing merchants to develop SKU-level substantiation infrastructure.
Here’s how Flex’s payment processor maps to the IRS functional requirements:
1) SKU-level eligibility decisioning aligned to §213(d)
IIAS requires collecting inventory control information (SKUs) and comparing them to a qualifying list under §213(d).
Flex does this by making eligibility determinations for all of our merchants products/services according to §213(d) and assigning that eligibility down to the product level using both a unique Flex ID as well as the products UPCs and/or GTIN to ensure consistency in eligibility across merchants.
This logic powers our merchants’ checkout to determine, at the point of sale, what portion of the cart is eligible according to §213(d).
2) Eligible-only approval
The IRS requirement is to approve the card only for the amount of §213(d) medical expenses. Flex authorizes HSA/FSA payment only for the eligible subtotal, preventing over-approval.
3) Split-tender support for mixed carts
When only part of the transaction is eligible, the customer must tender the remainder separately (split-tender).
Flex enables a single checkout flow where customers are prompted to enter their HSA/FSA card for eligible amounts and a credit/debit cart for non-eligible eligible amounts all without forcing two separate orders.
4) Audit-ready records and data retention
IRS guidance emphasizes that required information may need to be retained and that electronic recordkeeping principles apply. Flex maintains the Flex Eligible Catalogue, which contains all eligible and non-eligible products/services across all merchants in our system.
Our eligibility determinations are always mapped back to IRC §213(d). We also maintain all transaction decisioning evidence as well as documentation to support both Merchants, Customers, and HSA/FSA Administrators in audits and operational reviews.
Flex’s payment processor was designed to operationalize the IRS’s IIAS requirements within modern ecommerce checkout—without forcing merchants to develop SKU-level substantiation infrastructure.
Here’s how Flex’s payment processor maps to the IRS functional requirements:
1) SKU-level eligibility decisioning aligned to §213(d)
IIAS requires collecting inventory control information (SKUs) and comparing them to a qualifying list under §213(d).
Flex does this by making eligibility determinations for all of our merchants products/services according to §213(d) and assigning that eligibility down to the product level using both a unique Flex ID as well as the products UPCs and/or GTIN to ensure consistency in eligibility across merchants.
This logic powers our merchants’ checkout to determine, at the point of sale, what portion of the cart is eligible according to §213(d).
2) Eligible-only approval
The IRS requirement is to approve the card only for the amount of §213(d) medical expenses. Flex authorizes HSA/FSA payment only for the eligible subtotal, preventing over-approval.
3) Split-tender support for mixed carts
When only part of the transaction is eligible, the customer must tender the remainder separately (split-tender).
Flex enables a single checkout flow where customers are prompted to enter their HSA/FSA card for eligible amounts and a credit/debit cart for non-eligible eligible amounts all without forcing two separate orders.
4) Audit-ready records and data retention
IRS guidance emphasizes that required information may need to be retained and that electronic recordkeeping principles apply. Flex maintains the Flex Eligible Catalogue, which contains all eligible and non-eligible products/services across all merchants in our system.
Our eligibility determinations are always mapped back to IRC §213(d). We also maintain all transaction decisioning evidence as well as documentation to support both Merchants, Customers, and HSA/FSA Administrators in audits and operational reviews.
Conclusion: Monetize HSA/FSA demand without the substantiation risk
IIAS is not optional for merchants wanting to accept HSA/FSA payments. The IRS expectation is clear: use inventory information to approve only eligible medical expenses under §213(d), support split-tender for mixed baskets, and maintain audit-ready records.
Flex exists to do that work for you, so your teams can focus on assortment, conversion, and customer experience, all while meeting IRS substantiation expectations with an enterprise-grade implementation! The first step is contacting us, and the experts at Flex can help guide you through IIAS substantiation for your business so you can start accepting HSA/FSA payments.
IIAS is not optional for merchants wanting to accept HSA/FSA payments. The IRS expectation is clear: use inventory information to approve only eligible medical expenses under §213(d), support split-tender for mixed baskets, and maintain audit-ready records.
Flex exists to do that work for you, so your teams can focus on assortment, conversion, and customer experience, all while meeting IRS substantiation expectations with an enterprise-grade implementation! The first step is contacting us, and the experts at Flex can help guide you through IIAS substantiation for your business so you can start accepting HSA/FSA payments.
IIAS is not optional for merchants wanting to accept HSA/FSA payments. The IRS expectation is clear: use inventory information to approve only eligible medical expenses under §213(d), support split-tender for mixed baskets, and maintain audit-ready records.
Flex exists to do that work for you, so your teams can focus on assortment, conversion, and customer experience, all while meeting IRS substantiation expectations with an enterprise-grade implementation! The first step is contacting us, and the experts at Flex can help guide you through IIAS substantiation for your business so you can start accepting HSA/FSA payments.
Related content from Flex
More content from Flex
SPEAK WITH A FLEX EXPERT TO
Start accepting HSA/FSA
payments to drive more revenue
Identify if you need payments or reimbursements
See how Flex looks in your checkout flow
Easily integrate Flex with no changes to your stack
Book a Demo
Book a Demo
Book a Demo