AUD amount modelling
Exact arithmetic is usually cheaper than unexplained corrections
Choose numeric precision around the workload, then measure it. Do not trade away reproducibility before confirming that amount calculation is a real performance bottleneck.
In this article
Separate arithmetic cost from system cost
Exact decimal operations can cost more than integer arithmetic. That fact alone does not establish a performance problem in an application whose request also performs database access, authorisation and external calls.
Profile the actual calculation path using representative quantities and precision. Record throughput and latency with the proposed decimal representation before choosing an approximation.
Use integer minor units where they fit the domain naturally. Keep higher-precision rates and intermediate values in an appropriate exact representation rather than forcing all calculations into cents prematurely.
Limit precision deliberately
An unconstrained input with thousands of digits can consume unnecessary parsing, storage and calculation resources. Define maximum magnitude and scale for each field based on supported business operations.
Reject values outside that contract before expensive processing. A rate field and a settled amount may need different limits, so one global two-decimal validator is rarely sufficient.
Test database behaviour when a value exceeds the declared scale or precision. A silent rounding step at storage can alter the result even when the application calculation was exact.
Benchmark the heavy path honestly
An illustrative batch of one million allocation lines may justify optimising integer-cent distribution and bulk persistence. Benchmark that path with residual allocation, audit evidence and reconciliation included.
Do not compare a complete exact implementation with a floating-point prototype that omits the required evidence. The comparison should preserve the same business guarantees.
Where calculations can be cached, key them by all relevant inputs and policy version. Reusing a total after a rate or discount rule changes is a correctness defect disguised as a cache hit.
Include the cost of correction
Manual reconciliation, customer support and linked adjustments consume staff time. Estimate those costs using observed incidents rather than assuming every numerical defect will be caught before an external effect.
A performance optimisation is worthwhile when it improves measured capacity while preserving approved outputs. Keep independent fixtures and exact reconciliation checks in the benchmark harness.
The result should be a documented choice: which values use integers, which use decimals, what bounds apply and what workload justified the implementation. “Floating point is faster” does not answer those questions.
Primary sources
PostgreSQL: numeric typesReferences checked 11 September 2026.