How do I reconcile when my billing system and ERP disagree on invoice totals?

First check whether the gap is a real data mismatch or just a rounding convention difference — a common, benign cause. Some tax engines sum line amounts sharing a tax rate first, then round once; others round each line individually and sum the rounded results. The same invoice can legitimately total a cent differently under each method, which isn't a sync bug.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

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

Part of the finance integrations guide.

First check	Is this a real data mismatch, or a rounding-convention difference between the two systems?
Sum-then-round	Total line amounts sharing a tax rate first, then round the tax total once
Round-then-sum	Round each line's tax individually, then sum the already-rounded amounts
Typical gap size from rounding alone	The smallest currency unit (a cent, for USD) per affected tax group — small, but real
If the gap exceeds a rounding-sized difference	It's a real mismatch — a sync delay, a manual edit on one side, or a genuine calculation difference

Why a one-cent gap usually isn't a sync bug

Before treating a billing-vs-ERP total mismatch as a data integrity problem, check the size of the gap. A difference of exactly a cent or two, specifically on invoices with multiple taxed line items, is the signature of a rounding-convention difference, not a sync failure — two systems applying different, individually valid rounding rules to the same underlying line items can legitimately land on different final totals.

The two rounding conventions, concretely

Stripe's own tax documentation describes exactly this fork: for automatic tax calculation, amounts sharing the same applicable tax rate are summed first, and the tax total is rounded once — with a smallest-currency-unit adjustment applied to one line item so the line amounts still add up to the rounded total. Manual tax rates, by contrast, can round at the line-item level first, then sum the already-rounded line amounts into the total. Both are internally consistent; they just don't have to produce an identical final number for the same set of line items and tax rate.

Why this matters more with more line items, not fewer

A single-line invoice has nowhere for a rounding convention to create a gap — there's only one line to round. The risk grows with the number of taxed line items on an invoice, since each additional line is another point where sum-then-round and round-then-sum can diverge by a fraction of a cent that either compounds or partially cancels depending on the specific numbers involved. A high-line-count invoice showing a small total mismatch is more likely to be rounding-convention noise than one showing the same size mismatch on a two-line invoice.

What to actually check once rounding is ruled out

A gap too large to be rounding, or one that doesn't scale with line-item count, points somewhere else: a manual edit made in one system after the initial sync that never propagated to the other, a discount or credit applied on one side only, or the two systems genuinely calculating tax differently (a jurisdiction or exemption rule handled inconsistently between them). Isolating which specific line or field differs — not just the header total — is what actually identifies which of these it is.

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 3-line invoice, one cent apart, under two valid rounding rules

Line	Amount	Tax rate	Exact tax
Line 1	$10.10	7.25%	$0.7323
Line 2	$10.10	7.25%	$0.7323
Line 3	$10.10	7.25%	$0.7323

Round-then-sum: each line's exact tax ($0.7323) rounds individually to $0.73, and three lines sum to $2.19 total tax. Sum-then-round: the three exact tax amounts sum first (3 × $0.7323 = $2.1969), then round once to $2.20. Same three line items, same tax rate, two internally correct methods, a one-cent difference in the invoice total ($32.49 vs. $32.50) that has nothing to do with either system's data being wrong — it's the rounding convention itself producing a different, equally valid answer.

Frequently Asked Questions

Where both systems support choosing one, aligning them removes this specific source of small discrepancies entirely — but not every system exposes that choice, and some (like Stripe's automatic tax) always sum-then-round with no configuration option, so alignment isn't always achievable.

That's a materiality and process-design judgment — at small transaction volume the aggregate impact is negligible, but at high invoice volume the cumulative rounding difference across thousands of invoices can be a real, trackable variance worth reconciling systematically rather than dismissing individually.

Yes — the smallest currency unit varies (a cent for USD, but some currencies have no minor unit at all, or a different denomination), so the maximum plausible rounding-convention gap per affected tax group scales with the currency's own smallest unit, not a fixed universal amount.

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

How do I reconcile HubSpot quote amounts against booked revenue?

Compare each quote's line-item amount and recurringbillingfrequency against what the revenue schedule actually booked, line by line — not the quote total against the period's total revenue. A mismatch usually means a quote was edited after the schedule was generated, a line item's frequency was changed, or a quote was voided without the downstream schedule being updated to match.

How-to

How do I avoid duplicate Avalara tax transactions at period close?

Avalara's documentCode is reserved only once committed — reusing an uncommitted or voided code is allowed, but reusing a committed one returns DocumentCodeConflict. Generate codes deterministically from an invoice number, not a random value, and retry failed calls with that same code, so a network retry can't silently create a second committed transaction.