How do I reconcile Avalara-calculated tax against what a customer actually paid?

Compare the totalTax and grandTotal Avalara returned when the transaction was created against what was actually collected downstream — a Stripe charge, a bank deposit. A mismatch almost always means the transaction was adjusted or voided after creation without the downstream charge being updated to match, or it was never committed in the first place.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 14, 2026Last reviewed September 14, 2026Editorial policy

Part of the finance integrations guide.

Symptom	The amount a customer paid doesn't match Avalara's calculated grandTotal for that invoice
What Avalara returns at creation	totalTax (calculated tax) and grandTotal (totalAmount + totalTax)
Common cause #1	The transaction was adjusted or voided after the downstream charge was already set
Common cause #2	The transaction was never committed, so its numbers aren't the final reportable figure
Where to check	The transaction's commit status and its adjustment/void history, not just its original totals

What 'calculated tax' actually means here

When Avalara creates a transaction, it returns totalTax and grandTotal based on the line items, ship-to address, and any exemptions on file at that moment. That figure is a snapshot, not a permanent record — it reflects what tax should be as of the create call, not necessarily what the customer will end up paying if anything changes afterward.

Where mismatches actually come from

Two things account for most reconciliation gaps. First, an adjustment or void applied to the AvaTax transaction after the original grandTotal was already used to set a downstream charge — the tax figure changed on Avalara's side, but nothing propagated that change to whatever actually billed the customer. Second, an uncommitted transaction: its totals are real and usable for charging the customer, but because uncommitted transactions are excluded from reportable/compliance totals, comparing an uncommitted transaction's numbers against a committed filing figure will never tie out — they're not measuring the same thing.

How to reconcile

Pull the transaction by its document code and check two things before comparing totals: whether it's committed, and whether it has any adjustment or void history. If it's uncommitted, either commit it or treat it as provisional rather than comparing it against a final payment. If it's been adjusted, use the current (post-adjustment) totalTax and grandTotal, not the originally quoted figure — and check whether the downstream charge was updated to match.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Worked example

A $612.40 invoice with a $9.80 gap between calculated tax and collected tax

Avalara originally calculates $600.00 pre-tax plus $42.00 tax (7% rate) for a grandTotal of $642.00, and that figure is used to charge the customer's card. Two days later, before the transaction is committed, a line item is corrected — the customer's ship-to state changes because of an address correction — and the recalculated totalTax comes back at $32.20, for a new grandTotal of $632.20. The card was already charged $642.00. The $9.80 gap isn't a reconciliation bug: it's the adjustment that happened after the original charge, and it needs either a partial refund to the customer or a documented reason the original charge stands, not a search for a missing transaction.

Frequently Asked Questions

Yes — if a transaction has been adjusted, the current totalTax and grandTotal are the accurate figures. The originally quoted numbers only matter for understanding what a downstream charge was actually based on.

They're trustworthy for what they calculate, but not comparable to committed/reportable totals — an uncommitted transaction is excluded from compliance reporting until someone explicitly commits it.

Small rounding differences can come from how a downstream payment processor rounds versus how AvaTax rounds per line item — worth confirming the rounding method matches before assuming a data problem.

Sources

Topic

Integrations

Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch…

Diagnostic

Why is Avalara rejecting a sales invoice with a DocumentCodeConflict error?

A DocumentCodeConflict means the document code you sent already belongs to a committed transaction in AvaTax. The fix is not a fresh code — retrying with a new code every time is exactly what creates duplicate tax transactions on a real network retry. Keep the code stable, derived from the source invoice, and call the adjust or void endpoint if the original genuinely needs to change.

Diagnostic

Why doesn't an uncommitted Avalara transaction show up on my sales tax return?

AvaTax only reports committed transactions. Commit status is a flag that determines whether a transaction appears on your compliance reports and gets remitted — uncommitted transactions are treated as provisional and are excluded from liability calculations and filings until someone explicitly commits them.

How-to

How do I connect Avalara to calculate tax on AR invoices?

Loopfour's Avalara integration creates AvaTax transactions scoped to sales-side document types — SalesInvoice or SalesOrder — each requiring a unique document code and a customerCode identifying the buyer. Avalara calculates tax against the line items you send and returns totalTax and grandTotal, which downstream steps use to invoice or charge the customer.