Compare three numbers on one order
Take one order from one customer you believe is exempt. Write down the tax the storefront charged at checkout, the tax the ERP calculated when the order imported, and the tax on the invoice that went out. Those three figures are usually not the same, and the pattern tells you which system never heard about the exemption.
Do this on an order rather than on a customer record, because a customer record can show an exemption flag that nothing at checkout ever reads. The order is where the systems actually met.
One boundary before you start. This page is about where the exemption flag lives and which system is reading it, not about whether a given customer is exempt in a given jurisdiction. That is a question for your tax advisor and the answer changes by state, province and product category.
| Criterion | What you see | What it means | What to do |
|---|---|---|---|
| Storefront charged tax, ERP calculated zero, invoice zeroThis is the most common pattern and the one most often dismissed as cosmetic. It is not: the buyer abandoned a cart over it. | The customer was shown tax at checkout and the paperwork is correct. | The exemption lives downstream, in the ERP or the tax engine, and the storefront never saw it. Your accounting is right and your buyer experience is wrong. | Get the exempt status onto the storefront customer or company record, or put the tax engine in front of checkout so the calculation happens once. |
| Storefront charged zero, ERP calculated tax, invoice shows tax | The buyer was told no tax and then invoiced for it. | The ERP recalculated the tax the storefront had already decided. Acumatica does this on imported orders by default. | Decide which system owns the calculation and configure the other to accept it. There is a documented way to stop the recalculation, and it has consequences worth reading first. |
| Both charged tax | Nothing anywhere knows this customer is exempt. | Either the certificate was never recorded, or it was recorded somewhere the calculation does not read, such as a note field or a shared drive. | Go to the certificate audit below. This is a records problem more often than a software problem. |
| Both zero, but the customer says one order was taxed | It works most of the time and fails occasionally, usually for a particular ship-to or a particular date. | The certificate covers some jurisdictions and not others, or it expired, or the order went to a ship-to state the certificate does not cover. | Check expiry and jurisdiction coverage before you touch any configuration. This is the cause that survives every integration fix. |
Checked against: Acumatica community 12996: preventing tax recalculation on imported orders, Avalara knowledge base: exemption certificate management
Which system owns the certificate?
Three systems can hold an exemption and each holds a different amount of it. Knowing which one is authoritative in your setup is the whole answer, and in most companies nobody has written it down.
The failure this produces is specific: a certificate managed properly in one system, by a person who considers the job done, and a checkout that reads a different system entirely and knows nothing about it. Nobody is being careless. The two halves were configured by different people at different times.
| Criterion | What it holds | What it cannot see |
|---|---|---|
| The ERP customer record | A tax zone or tax category on the customer, and often a tax registration identifier. It governs what the sales order and the invoice calculate. | The checkout. Nothing in the ERP reaches the storefront’s tax decision unless something was built to carry it. |
| The tax engine | The certificate document itself, its expiry, the jurisdictions it covers and the exposure if it is missing. This is the only one of the three designed for the job. | Whatever is not calling it. A tax engine wired into the ERP but not into checkout will exempt the invoice and not the cart. |
| The storefront customer or company recordA storefront flag with no expiry is the setup most likely to be exempting somebody it should not. | A tax-exempt flag, and sometimes a certificate reference typed by a person. It governs what the buyer is shown at checkout. | Expiry and jurisdiction. A flag is a yes or no with no date and no coverage attached, which is why a flag alone is a liability. |
Checked against: Avalara CertCapture developer documentation, read 20 August 2026, Avalara knowledge base: exemption certificates
Run the certificate audit before you blame the integration
This takes an afternoon and it resolves a surprising share of these tickets without any software change. Pull the list of customers you treat as exempt and check four things on each.
The pattern to look for is that exemptions are usually correct at the moment they are set up and decay afterwards. Certificates expire, customers add ship-to locations in new jurisdictions, and product categories change. None of those raise an error anywhere.
Is there an actual certificate document, or only a flag someone set? A flag with no document behind it is an audit exposure, not an exemption.
Has it expired, and when does the next one expire? Sort by expiry date and look at the next 90 days.
Which jurisdictions does it cover, and do those match every ship-to address on the account? Multi-site customers are where this fails.
Does it cover the product categories they actually buy? A resale certificate does not automatically cover everything on your catalogue.
Why does it work for some orders and not others?
Four causes produce an intermittent pattern, and they are worth ruling out before you conclude the integration is unreliable.
The first one is the quiet killer. An exempt customer who checks out as a guest, or with an email address that does not match their account, is not that customer as far as your systems are concerned. They are a new record with no exemption, and everything behaved correctly.
The second is rounding rather than exemption. Shopify and Acumatica have been reported to disagree by a few cents on AvaTax calculations, which produces a difference too small to be an exemption fault and too persistent to ignore. If the amounts are cents rather than percentages, you are looking at a different problem.
The buyer checked out as a guest or under an unmatched email, so the order is not attached to the exempt account at all.
Rounding differences between the storefront tax calculation and the ERP, which look like small unexplained amounts rather than full tax lines.
A ship-to address in a jurisdiction the certificate does not cover, common when a customer opens a new site.
A product category outside the certificate’s scope, which is normal and correct and looks like a bug to whoever raised the ticket.
Checked against: Acumatica community 4296: Shopify and Acumatica AvaTax rounding difference
What is the durable fix, and what does it cost?
Decide one thing and write it down: which system calculates tax for web orders. Everything else follows from that sentence, and the absence of that sentence is why this problem recurs after each fix.
If the tax engine calculates, then checkout has to call it and the ERP has to accept its answer without recalculating. That is the cleanest architecture and it costs an integration plus a decision your controller has to sign.
If the ERP calculates, then the storefront should not display a tax amount it cannot stand behind. Showing tax calculated at checkout as an estimate, with the final amount confirmed on the invoice, is honest and legal in most contexts and is the cheapest correct answer. It is also unpopular with marketing, which is not a reason to reject it.
What you should not do is let both calculate independently and reconcile the differences by hand each month. That is where most companies actually are, and it is a manual process that scales with your growth.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Why does Acumatica charge tax on an order the storefront exempted?
- Because Acumatica recalculates tax on imported orders by default rather than trusting the amount that came from the external system. That behaviour is the subject of a well-known Acumatica community thread on preventing sales orders and invoices from recalculating taxes imported from BigCommerce, Shopify and marketplaces. There is a documented way to stop it, and it has consequences for how tax is reported, so read the thread and involve your controller before changing the setting.
- Should the exemption live in the ERP, the storefront or the tax engine?
- The certificate itself belongs in the tax engine, because it is the only one of the three that models expiry, jurisdiction coverage and product scope. The decision of which system calculates tax for web orders is separate and has to be made explicitly. What causes this problem is having the certificate in one place and the calculation in another, each configured correctly by different people at different times.
- Can we just flag the customer as tax exempt on the storefront?
- It works, and it is the fastest fix, and it carries an audit exposure you should accept knowingly rather than by accident. A storefront flag is a yes or no with no expiry date and no jurisdiction coverage attached, so it will keep exempting a customer after their certificate lapses and it will exempt a shipment to a state the certificate never covered. If you use a flag, put a recurring calendar task against the certificate expiry list and treat the flag as a mirror of the certificate rather than as the record.
- Our exempt customer was charged tax on one order only. Where do we look?
- Check three things in this order: whether that order was placed as a guest or under an email that did not match the account, whether the ship-to address was in a jurisdiction the certificate covers, and whether the certificate had expired on that date. Intermittent exemption failures are almost always identity or coverage rather than integration, and all three are answerable from the order record in a few minutes.
- Does Shopify or BigCommerce handle exemption certificates?
- Both can mark a customer as exempt, and neither is a certificate management system. They hold a flag rather than the document, the expiry and the jurisdictions, which is what a tax engine such as Avalara is for. Treat the platform flag as an output of your certificate process rather than as the place the exemption lives, and verify how your connector maps the flag from your ERP, because that mapping is frequently one-way or absent.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.