Tax rounding variance is one of those problems that is individually trivial and collectively persistent. A vendor calculates tax on the invoice total. The ERP calculates tax by summing tax on each line. The two methods can land a cent or two apart on the same invoice, not because either calculation is wrong, but because rounding at different points in the math produces slightly different results.
One invoice with a two cent variance is not worth anyone's attention. A thousand invoices a month with two cent variances is a recurring reconciliation task that someone on the accounting team ends up doing by hand, usually during close, usually under time pressure, usually the same week every month.
The fix is not a better rounding rule. Different rounding conventions are both defensible; the mismatch is inherent to the fact that vendor systems and buyer ERPs are not always calculating tax the same way. The fix is catching the variance before it becomes a GL entry that has to be unwound later.
Where the Mismatch Comes From
The rounding discrepancy is a byproduct of two legitimate but different calculation methods, not an error on either side.
Invoice total calculation
Many vendor billing systems calculate tax once, on the invoice subtotal, and round that single result. This is simple and produces a clean number on the vendor's invoice.
Line level calculation
Most ERPs, when they compute expected tax, calculate it line by line and sum the results. Each line rounds independently, and the sum of several independently rounded numbers does not always match a single calculation rounded once at the end.
Why both are correct and still mismatched
Neither method is wrong. They are just structurally different ways of arriving at a number that is supposed to be the same. On most invoices the difference is a cent or two. Across high invoice volume, the aggregate becomes a recurring reconciling item.
Where This Currently Gets Caught (or Doesn't)
In a manual process, rounding variance typically does not get caught at all until close, when accounting is trying to tie AP subledger totals back to the GL and finds small unexplained differences scattered across many vendor accounts. Tracking down the source of a two cent variance on an individual invoice is disproportionately time consuming relative to the size of the discrepancy, which is exactly why it tends to get bundled into a plug entry or written off as immaterial, invoice by invoice, month after month.
That approach is workable at low volume. It becomes a genuine drag on close as invoice volume grows, because the number of small variances grows with it, and each one still needs someone to look at it, even briefly, before it can be dismissed or corrected.
Catching Variance Before Posting
Finofo compares the tax extracted from the invoice against the expected line level treatment at the point of intake, before the bill is posted to the ERP. Where a rounding variance exists, it surfaces immediately, with the invoice and coding context still attached, rather than showing up as an unexplained gap between subledger and GL weeks later.
This does not eliminate rounding differences between vendor and ERP calculation methods. It moves the point of detection from the close, where the context has to be reconstructed, to intake, where the invoice is already open and the answer is immediately available.
What this means for the close checklist
Controllers who have dealt with recurring tax variance as a standing close task tend to describe it less as a hard problem and more as a persistent nuisance: never large, never urgent, always there. Removing it from the close entirely, because it was already resolved at intake, is a small change that has an outsized effect on how clean the close actually feels.
Start Here
If your month end close includes a recurring step to track down small unexplained tax differences across AP, that step exists because rounding variance is being caught after posting instead of before it.
Finofo surfaces tax and rounding variance at intake, before the bill reaches your ERP, so your team fixes it once instead of chasing it every close.
