AUD amount modelling
A money calculation should reconcile to the cent
Acceptance starts with invariants and explainable differences. An average error close to zero can hide offsetting mistakes across individual transactions.
In this article
Define what must always remain true
For each supported operation, write the relevant invariant. Allocations must sum to their source amount. A recorded reversal must refer to the original transaction. Amounts of different currencies cannot be summed without an explicit conversion process.
Apply those rules to individual records before aggregating results. One customer overcharged by a cent and another undercharged by a cent produce zero net error but two incorrect outcomes.
Use exact representations for the comparisons. A tolerance intended for scientific floating-point calculations should not silently permit unexplained cent differences in a settled amount.
Classify differences instead of hiding them
Reconciliation may legitimately include provider fees, foreign-currency conversion, partial settlement or timing differences. Keep those categories separate from calculation defects and unknown discrepancies.
An illustrative report compares a requested AUD 100.00 payment with AUD 97.00 received after a separately recorded AUD 3.00 fee. The fee explains the difference only if the provider evidence and accounting treatment support that classification.
Do not create a general Rounding adjustment bucket that absorbs any mismatch. Each adjustment needs a rule, bounded scope and evidence sufficient for the responsible reviewer.
Measure boundary coverage
Track whether the approved fixture set covers positive and negative ties, high-precision rates, maximum values, allocation residuals and provider scale conversion. Passing many random examples does not replace those deliberate boundaries.
Include round-trip tests through exports and imports. A report that looks correct but loses precision when downloaded can still break a downstream reconciliation.
Run historical examples when a calculation policy changes. Differences should be expected, reviewed and limited to the intended new scope.
Report operational consequences
Monitor rejected amount inputs, unresolved reconciliation items and manual correction frequency. Group them by adapter, policy version and error class rather than logging unnecessary customer financial details.
An acceptance report should identify any unexplained mismatch and its affected records. A high overall success percentage is insufficient if the remaining failures can create incorrect charges.
The useful evidence is reproducibility: a reviewer can take the recorded inputs and policy, obtain the same result and account for every difference between the business amount and external settlement.
Primary sources
PostgreSQL: numeric typesReferences checked 11 September 2026.