Payment Ledger Precision: Minor Units, Rounding and Residuals

Header image: conceptual illustration.

A payment amount looks correct in the interface but reaches the provider at one hundred times its intended value. Another reconciliation loses one minor unit each time an amount is split. Both problems can arise when money is treated as an ordinary floating-point number or every currency is assumed to have two decimals.

Payment precision needs explicit currency rules, exact arithmetic and a documented rounding point. This guide concerns ledger representation, not currency pricing or an offer of multi-currency services.

Separate money value from API representation

Keep the amount together with its currency. Define the ledger's exact representation and convert to the provider's documented request format at the boundary. An integer amount is not self-explanatory without knowing whether it means major or minor units.

Stripe's currency documentation describes minor-unit request amounts and exceptions, including zero-decimal currencies and special handling for certain charge or payout cases. It demonstrates why multiplying every amount by 100 is unsafe.

Do not assume that an API request and a CSV report encode amounts identically. Inspect each field's documented units. Also distinguish charge rules from payout rules where the provider treats them differently.

Use exact calculations for financial values

Use integer minor units where suitable or an exact decimal representation with explicit scale. Avoid relying on binary floating-point equality to compare payment amounts. Parse customer-facing decimal text according to the supported format rather than rounding an imprecise intermediate number silently.

Validate the expected amount before initiation and again against the verified final provider result. A display formatted to two decimals can conceal a mismatch in the underlying value. Crediting must match amount and currency and be idempotent; signature validity alone does not correct an arithmetic error.

Amounts in different currencies are not additive until an explicit conversion has been applied. The multi-currency overview explains presentment and settlement context, while this article keeps the precision boundary explicit.

Define where rounding happens

Document whether rounding is per item, per invoice, per allocation or at another approved accounting boundary. Choose the mode deliberately and preserve the rule version. Tax and financial accounting requirements may constrain that decision; this is not legal or accounting advice.

Keep extra calculation precision internally where needed, then round only at the defined boundary. Repeated rounding at several stages can create a systematic difference. Do not hide that difference inside an unexplained fee or change the original paid amount to make a report balance.

Allocating the final cent explicitly

Invented example: A BDT 100.00 total is allocated equally across three internal categories. An exact division produces a repeating decimal. If each category is independently rounded to BDT 33.33, the allocations total BDT 99.99.

Under a documented hypothetical allocation rule, two categories receive BDT 33.33 and one receives BDT 33.34, preserving BDT 100.00. The rule records which category receives the one-minor-unit residual. It does not claim that the provider charged a fee or that one unit vanished.

A refund allocation uses the same documented relationship to the original total rather than recomputing each category with unrelated rounding. Finance can reproduce the result from the rule and original values.

Handle FX as an explicit operation

Record source amount/currency, conversion evidence where applicable, settlement amount/currency and provider fees or adjustments. Retain the actual provider result for reconciliation. An indicative rate shown before payment may differ from the final booked settlement conversion under the actual agreement.

The currency-conversion fee guide discusses costs and questions to ask. Do not infer a specific rate, markup or supported currency from this precision example.

If the provider reports a residual, classify it according to the actual data. If the merchant's own calculation creates one, keep it separate from provider charges. That separation makes repeated discrepancies diagnosable.

Precision test checklist

• Two-decimal and zero-decimal examples use documented provider units.
• Charge and payout special cases are tested separately.
• Exact amount parsing rejects unsupported precision rather than hiding it.
• Splits add back to the original total after defined residual allocation.
• Partial refunds remain within the original currency/value constraints.
• CSV import/export preserves the documented scale and signs.
• FX amounts and fees remain linked but in distinct currencies.
• Repeating small differences are visible for review.

Precision questions for ledger reviewers

Is storing every value as an integer enough?

Only if its units and currency are explicit and conversions follow the provider's rules. The integer 100 can represent different economic values in different contexts.

Can we round away reconciliation differences?

Not without an approved rule and retained evidence. Rounding can explain a residual, but it should not conceal an unknown financial adjustment.