AUD amount modelling
Two decimal places do not define a money model
Separate currency, calculation precision and the point where an amount becomes payable. Display formatting cannot repair an ambiguous rounding policy.
In this article
Distinguish a rate from a settled amount
An application may charge a fraction of a cent for each unit of usage and settle the final AUD amount in cents. Storing the rate with only two decimal places can erase it before multiplication. Storing every final charge with unlimited precision creates a different problem when the payment interface expects a whole number of minor units.
Give rates, quantities and payable amounts explicit types. Keep the currency with monetary values rather than inferring it from a dollar sign or the user's location. A Brisbane business can still receive a USD supplier charge.
Use exact decimal arithmetic where fractional decimal calculations are required, or integer minor units where the domain truly consists of whole cents. PostgreSQL provides exact numeric types, while floating-point types represent some decimal values approximately. The application runtime and API boundary need compatible choices as well.
Decide when rounding changes the result
Consider three illustrative line calculations of AUD 0.335 each. Rounding each line to cents using a chosen half-up rule gives AUD 0.34 three times, totalling AUD 1.02. Adding first gives AUD 1.005, which rounds to AUD 1.01 under that rule.
Neither sequence should happen accidentally because one service stores two decimals and another sums a higher-precision value. The responsible business owner must define which calculation applies to the document and any relevant accounting requirements.
Store the policy version or enough calculation evidence to reproduce the result. The article's examples describe software behaviour, not a universal accounting rule.
- InputsCurrency, quantity and exact rate
- CalculationApply discounts and other agreed rules in order
- Settlement boundaryRound once under the selected policy and record evidence
- Output adaptersFormat for people or convert to the provider's amount contract
Preserve the total when allocating cents
Splitting AUD 10.00 equally among three allocations cannot produce three identical cent amounts. A policy might assign AUD 3.34, AUD 3.33 and AUD 3.33 using a stable residual rule.
Record which allocation receives the extra cent and why. If the order changes on every retry, the total remains correct while individual customers or cost centres receive inconsistent amounts. Determinism matters as much as the rounding mode.
For a reversal, use the original recorded allocation where appropriate. Recalculating with a changed policy can leave a cent behind or reverse a different distribution.
Make conversions explicit at integration boundaries
Some payment APIs expect amounts in currency minor units. Other systems accept decimal strings or have field-specific precision rules. Create named adapters and test their contracts. Passing 100 where an interface expects dollars rather than cents is a scale error, not a floating-point problem.
Keep formatting separate. Locale-aware display is useful for grouping and currency labels, but a formatted string is not a reliable calculation input. Persist the authoritative value and derive the screen representation.
A sound money model lets an engineer reproduce an amount from its inputs, identify its currency and explain every rounding difference. Showing two neat decimal places is only the last step.
Primary sources
PostgreSQL: numeric typesStripe: currency and amount representationMDN: Intl.NumberFormatReferences checked 11 September 2026.