Global Precision and how it could impact the financial calculations

When you're building anything that handles money, someone eventually asks:
"how many decimal places should we use?" The tempting answer is to pick a
number — 2, or maybe 5 to be safe — set it globally, and move on. It feels
like a reasonable call. It's not.

I've debugged precision bugs that traced back exactly to this decision.
Once you understand why a single global precision fails, you can't unsee it.

The core problem is that different parts of a financial system have genuinely
different precision requirements, and treating them the same introduces errors
at the boundaries.

Billing calculations that appear on invoices need 2 decimal places. That's
cent precision. That's what customers see, what they're charged, what appears
on the contract. Showing 4 decimal places here is wrong for a different reason —
you're creating a number that can't be represented in any real currency.

Analytics calculations — revenue attribution, cohort aggregations, lifetime
value — need more precision. When you're summing thousands of transactions
before producing a final figure, rounding to 2 places at each step accumulates
error that compounds in ways that matter at scale.

Internal calculations — intermediate values mid-computation — should use the
highest precision you can reasonably sustain, precisely because they feed into
further operations. Rounding early and then doing arithmetic on the rounded
value is one of the most common sources of financial calculation bugs I've
encountered.

If you apply a global setting, you're either truncating precision your
analytics pipeline actually needs, or you're putting 4-decimal numbers on
customer invoices. Neither is acceptable.

The model that works is precision as an explicit input to each domain calculator,
with sensible per-domain defaults:

type PrecisionConfig = {
  internalCalcPlaces: number;
  displayPlaces: number;
  storagePlaces: number;
};

const BILLING_PRECISION: PrecisionConfig = {
  internalCalcPlaces: 5,
  displayPlaces: 2,
  storagePlaces: 2
};

The engine computes everything at internal precision. It rounds to display
or storage precision only when producing output — at the domain boundary,
not in the middle of a calculation chain.

This brings us to what I think is the subtlest and most consequential mistake
in financial arithmetic: rounding order.

Consider a line item. Unit price $10.333..., quantity 3, 10% discount.

Round early: you get $10.33 × 3 = $30.99, apply discount, round to $27.89.

Round late — maintain full precision through the chain: $10.333... × 3 × 0.9 = $27.899...,
round only at output: $27.90.

One cent difference on one line item. Across a large pricing table with currency
conversion also in the chain, accumulated rounding error is real, customer-visible,
and extremely difficult to debug once it's in production — because the bug is
in the order of operations, not in any individual calculation.

Round at output boundaries. Never in the middle of a computation chain.

Currency conversion adds another layer to this. Rates are typically 4–6 decimal
places. If you convert and immediately round to 2 decimal places before doing
further arithmetic, you've thrown away precision you needed. Convert at full
internal precision, display-round last.

And never convert and re-convert. Round-trip currency conversion
(USD → EUR → USD) with intermediate rounding will not give you back the
original number. If any part of your system displays a converted value and
then uses that displayed value in further calculation, you have a latent
bug waiting for the right combination of exchange rate and amount to surface it.

The practical steps are straightforward: define precision per domain, make
it an explicit parameter rather than global configuration, add a lint rule
that forbids raw Number arithmetic in your calculation package, and treat
output boundaries as the one and only place where rounding is allowed.

It sounds like ceremony until you've spent a day debugging a $0.01 discrepancy
on a $50,000 contract that a customer has already signed and is asking why
the numbers don't match.

Precision bugs that involve accumulated rounding are the hardest to reproduce
consistently — they depend on exact input combinations and operation order.
Has anyone built regression suites specifically for these? Property-based
testing feels like the right tool but I'm curious what others have actually shipped.