Source: [AI-written money calculations: specify rounding before choosing decimals — Skills for Business](<https://skillsforbusiness.ai/blog/ai-written-money-calculations-rounding-policy/>)

[← All articles](https://skillsforbusiness.ai/blog/)

Development · Guide

# AI-written money calculations: specify rounding before choosing decimals

Decimal arithmetic cannot choose a billing rule. Define rounding stages, allocation and reversals before accepting AI-generated money calculations.

[Skills for Business](https://skillsforbusiness.ai/blog/editorial/)2 November 20267 min read

On this page

1.  [Separate representation from the rounding decision](https://skillsforbusiness.ai/blog/ai-written-money-calculations-rounding-policy/#separate-representation-from-the-rounding-decision)
2.  [A fictional three-line charge exposes the difference](https://skillsforbusiness.ai/blog/ai-written-money-calculations-rounding-policy/#a-fictional-three-line-charge-exposes-the-difference)
3.  [Specify allocation when the document needs line amounts](https://skillsforbusiness.ai/blog/ai-written-money-calculations-rounding-policy/#specify-allocation-when-the-document-needs-line-amounts)
4.  [Give the coding assistant a calculation contract](https://skillsforbusiness.ai/blog/ai-written-money-calculations-rounding-policy/#give-the-coding-assistant-a-calculation-contract)
5.  [Test the contract independently of the generated implementation](https://skillsforbusiness.ai/blog/ai-written-money-calculations-rounding-policy/#test-the-contract-independently-of-the-generated-implementation)
6.  [Preserve the rule after the code changes](https://skillsforbusiness.ai/blog/ai-written-money-calculations-rounding-policy/#preserve-the-rule-after-the-code-changes)
7.  [Sources](https://skillsforbusiness.ai/blog/ai-written-money-calculations-rounding-policy/#sources)

What to take away

-   Specify the rounding stage and tie rule separately from the numeric representation.
-   Keep allocated line amounts consistent with the approved document total.
-   Test reversals and saved results, not just a displayed total.

Before accepting AI-generated billing code, specify where rounding happens, which rounding rule applies and how any remainder is assigned. Choosing a decimal library addresses a representation problem. It does not decide whether a charge is calculated per line or across a document, or what a later reversal should undo.

This distinction matters when a developer asks an assistant to replace floating-point arithmetic, add a percentage charge or reconcile a preview with an export. Code can use decimals consistently and still implement the wrong business rule. A passing test copied from that implementation can preserve the mistake.

This guide proposes a small calculation contract and a fictional acceptance example. The amounts and fee rules below are invented to expose differences between implementations. They are not tax guidance, accounting requirements or observed customer results. We have not tested an AI coding product for this article.

## Separate representation from the rounding decision

The [Python 3.14 decimal documentation](https://docs.python.org/3.14/library/decimal.html) explains decimal representation, configurable precision and rounding modes. It also shows that constructing a decimal from a binary floating-point value preserves that value’s approximation. Converting to decimal after an earlier float conversion does not recover an intended decimal input automatically. Arithmetic still operates within a configured context, so decimal does not mean unlimited precision for every operation.

The underlying issue predates AI coding. David Goldberg’s [March 1991 numerical-computing tutorial](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html), available here as an edited reprint, explains finite representation and rounding error, including why decimal fractions such as 0.1 need not be exact in binary. It supplies numerical background, not evidence about current assistants or a preferred billing policy.

A second question remains after representation is settled: at which stage should an amount become payable at the chosen precision? Two programs can perform their intermediate decimal arithmetic exactly, then round at different stages and produce different totals. Neither program’s use of a decimal type settles which result the business intended.

For an existing application, locate the approved calculation rule and relevant stored examples before asking for a rewrite. If they disagree, make the disagreement a review item. Do not let the assistant choose a familiar convention and describe the resulting change as merely a technical cleanup.

## A fictional three-line charge exposes the difference

Imagine a fictional internal billing exercise with three lines, each priced at 0.05 units of a single currency. A 10% service fee applies. The exercise uses two decimal places and rounds nearest, with an exact halfway value rounded away from zero. All amounts here are positive.

The unrounded fee for each line is 0.005. Compare two possible policies:

| Calculation stage | Round each line’s fee | Round the combined fee |
| --- | --- | --- |
| Base amounts | 0.05, 0.05, 0.05 | Combined base 0.15 |
| Unrounded fee | 0.005 on each line | 0.015 on the document |
| Rounded fee | 0.01 on each line | 0.02 on the document |
| Total fee payable | 0.03 | 0.02 |

The difference is one smallest unit in this invented example. It comes from the rounding stage, even with exact intermediate values. Replacing the numeric type alone cannot choose between the policies.

For the rest of this exercise, suppose the responsible owner explicitly selects the combined-fee policy. That gives the developer an expected fee of 0.02 before any candidate code exists. It also creates the next requirement: if the document displays line-level fee amounts, how should those amounts add up to 0.02?

Microsoft’s [Dynamics 365 Finance documentation](https://learn.microsoft.com/en-us/dynamics365/finance/general-ledger/sales-tax-calculation-rounding) illustrates that real software distinguishes calculation bases, rounding parameters and allocation back to lines. That is vendor documentation for a particular tax system. It demonstrates the existence of separate configuration decisions; it does not prescribe a tax rule for this fictional service fee or establish that an assistant implements those settings correctly.

## Specify allocation when the document needs line amounts

The three exact fee shares are equal. Independently rounding each to 0.01 would produce 0.03 and contradict the selected document fee. Our fictional policy therefore allocates the two smallest units to the first two lines in an agreed, stable line-ID order. The posted line fees become 0.01, 0.01 and 0.00.

This is an illustrative allocation rule, not a universal recommendation. Other applications need proportional shares, different tie handling or different treatment of discounts. The owner must select the rule appropriate to the actual workflow.

Write down the properties the selected allocation must preserve. Here, every allocated amount uses the allowed precision, the sum equals the posted document fee, and reordering the display leaves the allocation attached to the same line IDs. A rule based on whichever rows happen to appear first on screen would fail the last condition.

Martin Fowler’s [Money pattern, published in March 2003](https://martinfowler.com/eaaCatalog/money.html), identifies currency handling and lost small amounts through rounding as design concerns. This is practitioner design guidance. Our application is to keep amount, currency and the approved calculation behavior together rather than scattering implicit rounding choices across screens and exports.

## Give the coding assistant a calculation contract

For this exercise, the request to the assistant should include the input representation, the single supported currency, the intermediate precision needed, the rounding stage, the explicit halfway rule and the stable allocation order. Include the expected document and line amounts from the worked example.

Separate a calculation from its display formatting. Showing two digits on screen should not silently alter the stored amount used by another calculation. Likewise, storing integer smallest units can be appropriate for posted amounts, but percentage calculations and allocation still require a deliberate intermediate representation and rounding decision.

Ask the assistant to identify any unresolved choices before editing. Missing currency, an invalid amount and a genuine zero should have specified handling. Do not treat an unsupported currency as though it merely uses the same number of decimal places. Define supported input ranges and precision limits for the actual application instead of relying on a library default.

Keep the change narrow. A request to fix representation should not also change fee eligibility, discount order or historical document values. If the intended policy itself changes, describe and review that as a behavior change with the responsible owner.

## Test the contract independently of the generated implementation

Use the fictional three-line document as one acceptance case, with expected values recorded before generation. Then vary the conditions that distinguish plausible implementations.

Test a single line, an exact smallest-unit result and a value exactly halfway between allowed amounts. Add a case just below and just above that halfway value. These check different decisions; a collection of whole-number examples will not expose the rounding boundary.

Reorder the three lines while retaining their IDs. Under this exercise’s stable-ID allocation, each line keeps its posted fee. Check both the document sum and the line allocations. Two incorrect line amounts can cancel out in the total.

Include a full reversal of the posted example. For this fictional workflow, reversing the stored fees means -0.01, -0.01 and 0.00, totaling -0.02. Recalculating three independent negative line fees under another policy would undo a different amount. Partial reversals need their own approved rule; the full-reversal example does not settle them.

Finally, save and reload the result, inspect the exported representation and compare the preview with the posted record. If a boundary converts an exact amount through binary floating point or applies a second rounding step, a correct calculation function alone will not protect the workflow. These are proposed acceptance checks, not tests performed on a real billing system here.

## Preserve the rule after the code changes

Keep the policy revision, expected examples and observed results with the change. Record the numeric library and runtime actually used, and inspect the saved values rather than only a screenshot of the total. A developer and the responsible process owner have different review responsibilities: implementation behavior and intended calculation policy both need an answer.

Our [guide to AI-generated tests](https://skillsforbusiness.ai/blog/ai-generated-tests-intended-regression/) explains why a green test can preserve the wrong expectation. For money calculations, the independent expectation is the approved calculation and allocation rule, expressed through inspectable examples.

Start with one calculation path. Confirm its rounding stage, allocation and reversal behavior, then check the generated implementation against that contract. A precise representation is useful infrastructure; the business rule still needs to be explicit.

## Sources & further reading

Sources checked for this article. Research findings and vendor claims are distinguished in the text.

1.  [decimal — Decimal fixed-point and floating-point arithmetic](https://docs.python.org/3.14/library/decimal.html)Python documentation · Accessed 2 November 2026
2.  [Sales tax calculation and rounding](https://learn.microsoft.com/en-us/dynamics365/finance/general-ledger/sales-tax-calculation-rounding)Microsoft Learn · Accessed 2 November 2026
3.  [Money](https://martinfowler.com/eaaCatalog/money.html)Martin Fowler · Accessed 2 November 2026
4.  [What Every Computer Scientist Should Know About Floating-Point Arithmetic](https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html)David Goldberg; ACM Computing Surveys, edited reprint hosted by Oracle · Accessed 2 November 2026

Produced with AI-assisted research and writing. Examples and recommendations are our editorial synthesis unless attributed. This article does not claim independent product testing or human expert review. [Read our editorial policy.](https://skillsforbusiness.ai/blog/editorial/)

## Keep reading

[AI-drafted postmortems: check the timeline before naming a cause](https://skillsforbusiness.ai/blog/ai-postmortems-timeline-cause-evidence/)[AI-added logging: define the event before copying the payload](https://skillsforbusiness.ai/blog/ai-added-logging-event-fields-review/)