Reader question: If a bank computer can calculate millions of numbers per second, why can adding, dividing or converting money still produce a one-cent discrepancy?
Because money is not merely a real number. A monetary amount carries a currency, decimal relationship, precision policy and rounding rule. Some decimal fractions such as 0.1 cannot be represented exactly in ordinary binary floating point. Some currencies have different minor-unit conventions. Division can create repeating decimals. Splitting one cent among three recipients has no exact answer in whole cents. And rounding each line item before summing can produce a different result from summing first and rounding once.
A banking money-arithmetic engine therefore needs explicit representation and invariants. It may use integers measured in minor units, arbitrary-precision decimal types, or a carefully designed combination. It keeps intermediate precision deliberately, rounds only at defined boundaries, records the rounding policy, checks overflow and scale, and reconciles totals so that value never disappears silently.
What this page owns — and what it does not
This page owns the numerical representation, decimal precision and rounding layer for monetary amounts. It does not replace transaction reconciliation, which checks records across systems; ISO 20022 message validation, which validates financial-message structure and semantics; or product-specific calculations such as floating-rate loan interest and bond accrued interest.
Those algorithms produce monetary quantities. This page explains how a system can carry those quantities without creating accidental fractions, hidden drift or inconsistent rounding.
First principle: amount and currency belong together
The value “100” is not enough information. It could mean:
- 100 dollars;
- 100 cents;
- 100 yen;
- 100 units of a currency with three decimal minor-unit digits;
- a model value that has not yet been rounded to a payment amount.
A useful money object therefore behaves conceptually like:
Money = (currency, amount, scale or unit convention).
ISO 4217 standardises currency codes and, for currencies with minor units, the decimal relationship between the unit and minor unit. It is explicitly designed for trade, commerce and banking, including automated systems.
The engineering consequence is simple: never infer decimal scale from a user interface or assume every currency has two decimal places.
Why binary floating point can surprise you
Computers commonly store ordinary floating-point numbers in binary. Many decimal fractions do not have finite binary expansions, just as 1/3 does not have a finite decimal expansion.
The decimal value 0.1 is one familiar example. A binary floating-point representation stores a nearby approximation rather than the exact rational value one-tenth.
For scientific computing this is often entirely appropriate: floating point offers enormous speed and a well-understood error model. The problem arises when an application silently treats an approximate representation as if it were exact currency arithmetic.
PostgreSQL’s current documentation makes the distinction explicit: its floating-point types are inexact, while the arbitrary-precision numeric type is recommended when exact storage and calculations are required, including for monetary amounts.
Representation 1: integer minor units
If a currency’s payable minor unit is fixed, one robust representation is an integer count of that unit.
For a two-decimal currency:
12.34 major units ↔ 1234 minor units.
Addition then becomes exact integer addition:
1234 + 567 = 1801
representing 18.01 major units.
This is often called fixed-point integer arithmetic. The decimal point is conceptually fixed by the currency metadata rather than stored as a floating binary fraction.
What integer minor units solve — and what they do not
Integers make addition, subtraction and equality straightforward. They are excellent for booked ledger amounts that are already quantised to a known smallest unit.
But interest, tax, allocation and foreign-exchange calculations often produce fractions smaller than the final payable unit. Suppose 100 cents earns interest at a rate that produces 0.37 cents for the day. An integer-cent engine cannot store that intermediate exactly unless it introduces a finer internal unit or carries a rational/decimal remainder.
So “store everything as cents” is safe only if the calculation policy defines what happens to sub-cent values.
Representation 2: arbitrary-precision decimal
Decimal arithmetic stores numbers as decimal digits with an explicit scale or exponent. Values such as 0.1, 0.01 and 19.99 can therefore be represented exactly in the decimal system.
Java’s BigDecimal, Python’s Decimal, database NUMERIC/DECIMAL types and implementations of the General Decimal Arithmetic model are examples of this approach.
Exact decimal storage does not mean every operation has an exact finite result. Division still creates problems:
1 ÷ 3 = 0.333333…
A decimal engine must then know the working precision and rounding policy. Java’s BigDecimal documentation, for example, notes that exact division can fail when a quotient has no terminating decimal expansion unless a rounding context is supplied.
Precision and scale are different
Precision is the total number of significant decimal digits.
Scale is the number of digits to the right of the decimal point in a common fixed-scale representation.
The value 23.5141 has precision 6 and scale 4.
This matters because a database column defined with scale 2 may round 23.5141 on storage, while an unrestricted internal decimal calculation may need all four or many more fractional digits until the contractual rounding point.
Do not round at every arithmetic step
Suppose three unrounded line items are:
- 0.004;
- 0.004;
- 0.004.
If each line is rounded independently to two decimals using a conventional nearest rule, each becomes 0.00 and the sum is 0.00.
If the exact lines are summed first:
0.004 + 0.004 + 0.004 = 0.012,
then the total rounded to two decimals can become 0.01.
Neither sequence is universally “the right one.” The correct answer depends on the governing calculation rule. The important engineering requirement is that the system knows where rounding is contractually required and does not insert extra rounding simply because a display has two decimal places.
Rounding is an algorithm, not formatting
Formatting decides how a number is shown. Rounding changes the numerical value.
Common policies include:
- round toward zero;
- round away from zero;
- round toward positive infinity;
- round toward negative infinity;
- round half up;
- round half down;
- round half to even.
Oracle’s current Java documentation defines these policies explicitly. Under HALF_EVEN, a tie goes to the even neighbouring digit: 2.5 rounded to an integer becomes 2, while 5.5 becomes 6. Java notes that this tends to reduce cumulative rounding bias when repeatedly applied.
But the phrase “banker’s rounding” should not be treated as a universal banking rule. A contract, law, tax rule, payment scheme or accounting policy may require a different convention.
Counterexample: 0.005 has more than one legitimate rounded result
To two decimal places:
- HALF_UP can map 0.005 to 0.01;
- HALF_EVEN can map 0.005 to 0.00 because the retained hundredths digit 0 is even.
Both are internally consistent algorithms.
If two systems use different tie rules, their individual transactions can differ by one minor unit even though all earlier arithmetic is identical. Reconciliation must therefore compare rounding policy as well as inputs.
Quantisation: make the output unit explicit
A useful operation is:
quantize(amount, target scale, rounding rule).
This says: convert the exact or high-precision internal result to the representable unit required at this boundary.
Examples of boundaries include:
- posting an amount to a ledger;
- creating a payment message;
- displaying a legally specified statement amount;
- allocating a fee across accounts;
- settling a cash flow.
The engine should record the pre-rounded amount, rounded amount, scale and rule where auditability matters.
The one-cent allocation problem
Suppose a total of 0.01 must be divided equally among three accounts.
The exact mathematical share is:
0.01 / 3 = 0.003333…
There is no way to assign each account a whole cent while preserving both perfect equality and total conservation.
Any payable allocation must break one of those ideals. A deterministic algorithm might assign:
- 0.01 to one account and 0.00 to the other two;
- rotate the residual across accounts over time;
- accumulate sub-cent remainders until they cross a cent;
- use a largest-remainder rule based on fractional entitlements.
The important invariant is:
Σ allocated posted amounts = original posted total.
A residual minor unit must not disappear merely because each ideal fraction rounded down.
Largest-remainder allocation
Suppose 10 cents is allocated across weights 50%, 30% and 20%. The ideal shares are exactly 5, 3 and 2 cents, so no problem occurs.
Now allocate 11 cents:
- ideal A = 5.5;
- ideal B = 3.3;
- ideal C = 2.2 cents.
If the first pass floors each allocation, we get 5 + 3 + 2 = 10 cents. One cent remains. The largest fractional remainder is A’s 0.5, so A receives the residual cent, producing 6, 3 and 2.
This is an example of converting continuous proportions into indivisible units while preserving total value. If two fractional remainders tie, the system also needs a deterministic tie-break rule.
Currency conversion requires two precision layers
Suppose a system converts amount A at exchange rate r:
B* = A × r.
The internal result B* may carry far more decimal places than the target currency’s payable unit. The algorithm should generally:
- represent the input amount exactly under its currency rules;
- use the defined FX rate with sufficient precision;
- multiply at controlled working precision;
- quantise only at the contractual or settlement boundary;
- record the rate, source, timestamp and rounding rule.
Rounding the FX rate prematurely and then rounding the converted amount again can create double-rounding error.
Double rounding: two harmless-looking steps can change the final cent
Suppose an internal result is 1.2451.
If first rounded to three decimals using HALF_UP, it becomes 1.245. Rounded again to two decimals, it becomes 1.25.
If rounded directly from 1.2451 to two decimals, it also becomes 1.25 in this example. But other values and rule combinations can produce different results. The broader point is that every intermediate quantisation discards information.
A robust engine avoids undocumented intermediate rounding and tests for double-rounding cases near half-unit boundaries.
Rates and money should not share the same scale blindly
An interest rate might need many decimal places even when the final cash payment has only two. A daily compounded benchmark can produce intermediate factors requiring substantial precision. The SOFR loan algorithm therefore should not store rates using the same two-decimal scale as a currency amount.
Likewise, bond accrued interest can require sub-cent precision until the market convention says when to round. Representation should follow the mathematical object, not one universal database scale.
Inputs and outputs
A monetary arithmetic engine can require:
- currency code;
- currency metadata and minor-unit relationship;
- exact input amount;
- working precision;
- target scale or quantum;
- rounding mode;
- operation type;
- allocation weights where relevant;
- FX or interest-rate precision where relevant;
- overflow and range limits.
Outputs should include the exact or high-precision intermediate result where needed, quantised posted amount, residual amount, rounding metadata, overflow/precision status and reconciliation totals.
Evidence polarity: what supports confidence?
Evidence for confidence includes exact agreement between independent decimal implementations, conservation of monetary totals, explicit currency metadata, stable results across serialisation and database round trips, no hidden float conversion, deterministic residual allocation and a documented rounding point for every quantisation.
Evidence against confidence includes unexplained one-cent breaks, values changing after database storage and retrieval, currency scale inferred from display formatting, inconsistent results across programming languages, a different total when line order changes, or repeated adjustments posted manually to force reconciliation.
Counterexample: two-decimal storage is not enough for every currency
A schema defined as “money = DECIMAL(…,2)” assumes every currency amount has two fractional digits. ISO 4217 exists partly because currency metadata differ.
Even where the final payable amount has two decimals, internal calculations may require more. One fixed scale for all stages therefore mixes currency representation with calculation precision.
Counterexample: exact decimal does not remove the need for rounding
An arbitrary-precision decimal can represent 0.1 exactly, but it cannot make 1/3 terminate in base 10. Division still needs a precision or rounding policy unless the application carries an exact rational representation.
So replacing binary floating point with decimal arithmetic solves one class of representation error, not the mathematical reality of indivisible units and non-terminating quotients.
Counterexample: rounding each account can break portfolio conservation
Suppose a fee of 0.05 is allocated equally across two accounts: each ideal share is 0.025.
If HALF_UP is applied independently to each, both can become 0.03 and the allocated total becomes 0.06 — one cent more than the original fee.
A conservation-aware allocation algorithm instead determines the total payable amount first and distributes the indivisible residual deterministically. The allocation problem is not solved by calling a rounding function on each line independently.
Overflow is a money error too
Integer minor-unit arithmetic is exact only inside its representable range. If a system uses a signed 64-bit integer, there is a maximum number of minor units it can store. Multiplying a large amount by a scaling factor, exchange rate numerator or allocation weight can overflow even when the final economic amount would have fit after division.
A safe implementation uses checked arithmetic, wider intermediate types, arbitrary-precision integers or a reordering of operations that preserves exactness without exceeding bounds.
Silent wraparound is unacceptable: a positive balance should never become negative because a machine integer overflowed.
Negative amounts and directional rounding
Rounding toward zero, floor and ceiling behave differently for negative numbers.
For example, rounding −1.6 to an integer:
- toward zero gives −1;
- floor gives −2;
- ceiling gives −1.
If fees, refunds, reversals and credits can be negative, tests must include both signs. A rule written only with positive examples can produce asymmetric financial results.
Database boundaries can silently quantise
A program may calculate with high-precision decimals and then insert the result into a database column with a smaller declared scale. The database can round or reject the value depending on its type and constraints.
That means the schema is part of the arithmetic algorithm. PostgreSQL documentation explicitly describes precision and scale for NUMERIC and notes that constrained scale can cause stored values to be coerced by rounding.
Application code and database schema should therefore share one documented amount contract rather than each choosing precision independently.
Serialisation boundaries can lose exactness too
A decimal amount can be exact in one process and then be serialised as a generic JSON number, parsed by a consumer into binary floating point, and returned slightly changed.
Safer patterns include a currency-aware structured representation, a decimal string with explicit validation, or integer minor units with currency metadata — depending on the interface standard.
The important diagnostic is round-trip identity: encode, transmit, decode and compare the exact monetary value.
Weak links in implementation
Implicit float conversion. Exact decimal becomes approximate inside a helper library.
Universal two-decimal assumption. Currency metadata are discarded.
Premature rounding. Intermediate values lose information before the contractual boundary.
Inconsistent tie rule. One service uses HALF_UP while another uses HALF_EVEN.
Residual leakage. Fractional allocations are rounded independently and the total no longer reconciles.
Unchecked integer overflow. Exact arithmetic becomes catastrophically wrong outside the type range.
Database scale mismatch. Storage silently changes an application-calculated value.
Locale parsing. “1,234.56” and “1.234,56” can be interpreted differently if text input is not normalised under an explicit format.
Currency conversion without provenance. Rate precision and rounding cannot be reconstructed later.
Diagnostics: how to test money arithmetic
- 0.1 test: verify that exact-decimal or integer representations round-trip 0.1 without binary drift.
- one-cent split: divide one minor unit among three recipients and require conservation.
- half-unit matrix: test positive and negative values exactly at tie boundaries under every supported rounding mode.
- sum-then-round versus round-then-sum: make the difference visible and confirm the contract selects one.
- currency-scale test: use currencies with different minor-unit relationships.
- database round-trip: calculate, store, read back and compare exact value and scale.
- serialisation round-trip: pass the amount through every API format used in production.
- overflow test: operate near integer maximums and require explicit failure or safe widening.
- residual tie test: create equal fractional remainders and verify deterministic allocation.
- reconciliation invariant: require debits, credits and allocated sub-totals to conserve the intended booked total.
What would falsify confidence?
Confidence should be withdrawn if booked totals depend on the order in which equivalent line items are processed; if a decimal value changes after database or API round-trip; if two services using the same documented rule disagree by one minor unit; if residuals disappear; if the currency scale is not traceable; if overflow is unchecked; or if reproducing a historical amount requires guessing which rounding rule was used.
Alternatives and trade-offs
Integer minor units offer excellent exactness and speed for booked amounts but need a policy for sub-minor-unit intermediates and range limits.
Arbitrary-precision decimal maps naturally to financial decimal notation and controlled rounding but is slower and still needs precision rules for non-terminating division.
Rational arithmetic can represent fractions such as 1/3 exactly but can grow large and eventually must be quantised for real-world payment units.
Binary floating point remains appropriate for many analytical and simulation tasks where small representation error is acceptable and controlled. The mistake is not using floating point; it is using approximate arithmetic in a workflow that requires exact monetary equality without defining tolerances and boundaries.
How this connects to the surrounding knowledge estate
Exact money arithmetic is an infrastructure layer beneath many existing pages. ISO 20022 validation carries currency and amount fields across systems. Reconciliation detects when two systems disagree. Loan-interest algorithms create high-precision intermediate accruals before payment. Bond accrued-interest algorithms translate fractional coupon entitlement into settlement amounts. A rounding defect below any one of these layers can appear later as a reconciliation exception.
Verification and update triggers
Preserve the currency-metadata version, amount representation, database precision/scale, rounding mode, quantisation points, residual-allocation rule, overflow limits and API serialisation format. Revalidate after ISO 4217 metadata changes, database migrations, programming-language or runtime upgrades, payment-message schema changes, new currencies, accounting-policy changes, FX-engine changes or repeated unexplained minor-unit reconciliation breaks.
Primary and high-quality references
- ISO, ISO 4217:2015 — Codes for the representation of currencies, specifying currency codes and the decimal relationship of minor units where applicable. ISO lists the edition as current after review.
- PostgreSQL, Numeric Types, distinguishing exact NUMERIC/DECIMAL arithmetic from inexact floating-point types and recommending NUMERIC for monetary amounts where exactness is required.
- Oracle Java SE 26, RoundingMode, defining directed and nearest-neighbour decimal rounding policies including HALF_EVEN.
- Oracle Java, BigDecimal, documenting decimal scale, precision, exact arithmetic and the need for rounding when division does not terminate.
- Python documentation, Decimal fixed-point and floating-point arithmetic, for decimal contexts, exact decimal representation, rounding modes, flags and quantisation.
Educational boundary: This article explains numerical representation and rounding in financial software. It does not calculate taxes, fees, exchange rates or account balances for a reader and does not provide personalized financial advice.