Why your VAT amounts differ between e-commerce and ERP

In short

Your e-commerce platform and your ERP (or invoicing software) both calculate tax correctly, but with a different logic. The discrepancy you observe — often a few cents to a few euros per order — is not a bug. It's a fundamental translation problem between two systems designed for different purposes.

The solution isn't to move a figure from one system to the other. It's about aligning the logic behind that figure.

The core misunderstanding

Most integrations treat tax like a price or a product reference: a value that you move from one system to another.

But tax isn't a stored value, it's a calculated field. It depends on:

• The product category
• The customer type (B2B, B2C, exempt)
• The jurisdiction (country, region, state)
• The discount rules
• The tax applied to shipping costs
• The rounding method

When you "sync" a tax amount from e-commerce to the ERP, you push the result of system A's logic into system B, which then applies its own logic and gets a different answer.

This is the root cause of the discrepancy.

Why the two systems calculate differently

E-commerce platforms

Shopify, WooCommerce, Magento, Prestashop or BigCommerce are optimized for checkout speed. They use:

• Simple product tax classes ("taxable / non-taxable")
• Line-level rounding on each order line
• The platform's default discount logic
• Basic shipping tax rules

ERPs and invoicing software

Pennylane, Sellsy, Odoo, Axonaut, Evoliz, NetSuite, SAP B1 or Dynamics are optimized for compliance and audit trails. They use:

• Item tax groups and tax codes tied to the jurisdiction
• Order-level rounding (or mixed)
• Strict discount sequencing (before or after tax)
• Sometimes external tax engines (Avalara, Vertex) that recalculate on every order change

The result: two systems where each is technically correct, but neither matches the other exactly.

The six points of failure

1. Rounding method difference

Shopify rounds at the line level. Your ERP often rounds at the order level.

On a multi-item order with several tax rates, the cumulative difference can easily produce a discrepancy of €1 to €3. Finance teams call this the "penny shift". It's not a bug, it's a design difference.

2. Discount sequencing

• Shopify always applies discounts before tax.
• Magento and WooCommerce let you configure the order.
• ERPs may apply discount logic differently depending on the tax engine.

A 10% discount applied at different points in the calculation chain produces different taxable amounts — and therefore different VAT.

3. Shipping tax treatment

Shipping costs are taxable in some jurisdictions, not in others. Each system has its own logic.

If they are not explicitly aligned, you will have mismatches on every order that includes shipping costs.

4. Non-taxable items becoming taxable in the ERP

E-commerce makes it easy to manage exemptions: you just disable "charge tax".

ERPs, on the other hand, require explicit tax groups, tax codes, and sometimes exemption certificates. If the mapping isn't exact, the ERP will silently recalculate a "non-taxable" product as taxable.

5. The ERP doesn't trust your tax

Most ERPs are designed to recalculate tax on import. Any later modification — quantity change, discount update, item swap — triggers a full recalculation with the ERP-side rules.

Even if the figures matched at the time of the sync, they can drift later.

6. Two tax engines running in parallel

Shopify uses its native tax engine. Your ERP may use Avalara, Vertex, or its own engine.

Two separately certified engines can produce different results for the same order if the product classification or jurisdiction data isn't strictly identical on both sides.

The classic solutions (and their limits)

"Don't sync the tax"

Let the ERP recalculate tax independently. This works for internal accounting, but fails in B2B when the invoice tax has to match the checkout tax.

"Force the same tax engine everywhere"

Use Avalara or Vertex in both systems. This is the best approach, provided the product classification, customer exemptions and jurisdiction data are kept identical on both sides. If they drift, so do the figures.

"Manual adjustment"

Finance teams correct things by hand. This doesn't scale beyond a few hundred orders per month.

The clean long-term approach

The lasting solution is to align four elements in both systems, not just the final tax amount:

Then build a reconciliation layer that detects drift before it reaches your accounting books.

How Order Invoicer handles these discrepancies

Order Invoicer syncs e-commerce orders to your invoicing software while preserving the original logic as much as possible:

• The order lines are sent with their pre-tax, VAT and tax-inclusive amounts calculated by the source platform.
• The shipping costs are passed as a separate line with their own VAT rate.
• The discounts are applied at the same level as on the source platform to avoid taxable-base drift.
• The VAT codes on the ERP side are explicitly mapped to the e-commerce rates via the connector configuration.

The Adjustments feature

To absorb these rounding discrepancies without manual intervention, Order Invoicer includes an Adjustments feature available on all invoicing connectors: Pennylane, Sellsy, Odoo, Qonto.

How it works

After each invoice, credit note, quote or order is created on the ERP side, Order Invoicer compares the tax-inclusive total of the e-commerce order with the tax-inclusive total calculated by the ERP. If the two don't match exactly, a correction line is automatically added to the document with:

• A quantity of 1
• A unit amount equal exactly to the discrepancy (positive or negative)
• A VAT rate of 0% (an exempt line, so as not to introduce a new taxable base)
• The label of your choice (e.g. "Rounding adjustment", "VAT discrepancy")
• The accounting code of your choice (e.g. an adjustment or exceptional income account)

Result: the final tax-inclusive total of the invoice matches the e-commerce order's tax-inclusive total exactly, while keeping the ERP's tax calculation logic on the product lines.

Configuration

In your connector settings (Settings → Adjustments card), you configure:

When the adjustment applies

The automatic adjustment is triggered only if the absolute difference between the source tax-inclusive total and the ERP tax-inclusive total is less than or equal to the configured threshold (default: €0.01, with an additional technical tolerance of €0.01).

Robustness

• The adjustment is retried up to 3 times in case of a temporary ERP failure.
• If the adjustment fails despite the retries, an email notification is sent to the configured users, with the order reference.
• The adjustment applies to invoices, credit notes, quotes and purchase orders.

When the adjustment isn't enough

If you see discrepancies larger than the adjustment threshold, it's a sign of a configuration drift that should be fixed upstream:

1. Check that the VAT rates configured in the ERP match exactly those of the e-commerce platform
2. Check that the shipping tax treatment is identical on both sides
3. Check that the exempt products are correctly mapped to an exempt VAT code on the ERP side
4. Check that the intra-community B2B customers are correctly identified as such in both systems