How do you stop Acumatica recalculating tax that Shopify already charged at checkout?

Because by default Acumatica treats itself as the source of truthThe source of truth is the system that gets to be right when two systems disagree. For price, stock and customer terms in an ERP-run business, that is almost always the ERP. for tax on a sales order, and it does not know that the number arriving from Shopify or BigCommerce is a number a customer has already been charged. It recalculates against your tax zones and categories, and now the order in the ERP and the receipt in the customer’s inbox disagree.

The disagreement is usually small and that is what makes it expensive. A few cents per order, thousands of orders, and someone in finance is reconciling by hand every month. It is common enough that Acumatica’s community has a dedicated thread with a title long enough to be a sentence, on preventing sales orders and invoices from recalculating taxes imported from external systems such as BigCommerce, Shopify and Amazon.

From Acumatica 2023 R1 onward the mechanism is a checkbox called Disable Automatic Tax Calculation on the Order Types form, SO201000. The community thread quotes the behaviour plainly: “When this checkbox is selected, the system will refrain from recalculating the taxes for the Sales Orders and Invoices.” The sales order form, SO301000, inherits the setting on its Financial tab, and on the store record you switch on Tax Synchronization so the imported figure comes across in the first place.

Now the part that gets skipped in the setup guides. Ticking that box also stops those invoices being sent to external tax providers such as Avalara or TaxJar. That is intentional, so you do not report the same sale twice, and it is a serious consequence if Avalara is where your returns are prepared. You have chosen to keep the storefront’s number and, in the same click, to take those transactions out of your automated filing.

Three exclusions are documented alongside it. The feature does not apply to inclusive taxes, it does not apply when Net or Gross Entry Mode is enabled and you are entering gross, and on partial invoices the taxes post to the first invoice only, with a proper fix noted as planned for 27R1. If you invoice partially, and distributors often do, that last one is not an edge case.

Because the requirement is contradictory and neither product models it well. A marketplace facilitator has already collected and remitted the tax, so you must not calculate it again, and you still want the sale visible to Avalara so your automated remittance and your nexus tracking are complete.

A user put exactly that in Acumatica community thread 28269: “We do not want our Marketplace orders to calculate tax in Acumatica but need our sales to report to Avalara for our automated remittances.” Three attempts are documented. Disable Automatic Tax Calculation stopped the sales reaching Avalara. Overriding the tax zone did the same. A tax exemption number worked on staging and, in production, was “randomly still calculating tax”. The answer from the Acumatica side was that it was already under discussion and “there is no solution yet”.

One thing has changed since that thread and it is worth checking before you build anything. Acumatica’s 2026 R1 release notes list marketplace tax reconciliation for the Shopify integration, describing handling of marketplace-remitted taxes with tax account mapping and payment and refund processing. Whether that closes the Avalara gap for your configuration is exactly the sort of claim we will not make on your behalf. Test it in a sandbox on your own release before you plan around it.

A user in Acumatica’s financials forum described it as “rounding errors of a few cents between what gets calculated on the front end in checkout vs. what gets calculated in the sales order in Acumatica”, regularly. The thread does not settle on a single cause, and the contributing factors named are decimal precision differences between the two systems and Acumatica recalculating tax that Shopify had already computed.

Four remedies come out of that thread, and they stack rather than compete. Stop the recalculation and carry the storefront’s figure across as the tax on the order. Set Price and Cost decimal places to two in the Acumatica Companies screen, since Shopify calculates tax to two decimals and matching the precision removes a class of difference. Point both Shopify and Acumatica at the same Avalara account so the two calculations at least start from the same rates. Then accept that a residue will remain and configure an automatic write-off with a defined limit per customer or per document, so a two-cent variance closes itself instead of reaching a person.

The last one is the one finance teams resist and the one that saves the most time. A reconciliation process that requires a human for two cents is a reconciliation process that will not be done by March.

One decision, made once, in writing, before anyone configures anything. Either the storefront calculates tax and Acumatica accepts the figure, or Acumatica calculates and the storefront is told what to charge. Splitting it by order type is possible and it doubles your reconciliation surface.

For a B2B seller the storefront-calculates path is often weaker than it looks, because exemption certificates, resale numbers and customer-level tax status live in the ERP and in Avalara rather than in the storefront. If a meaningful share of your customers are exempt, the ERP or the tax engine has the information and the storefront does not.

Where we do not have enough evidence to give you a rule is the mixed case: a seller with a direct storefront, a marketplace channel and exempt B2B accounts, all in one Acumatica tenant. That combination is where community thread 28269 ran out of answers, and it is a case to prototype rather than to assume.