Account for the whole allowance before formatting the amounts
Three displayed amounts can each look reasonable and still fail to account for the total they are meant to distribute. When software allocates an order-level allowance to individual lines, rounding is part of the calculation policy. It cannot be left to whichever screen happens to format the values first.
This fictional example concerns an internal order preparation tool. No payment is taken, no refund is issued and no tax treatment is inferred. The business has already approved a EUR 1.00 allowance and the allocation rule described below. The investigation checks whether the software implements that rule and preserves its total.
Define eligibility before dividing anything
Order O-61 contains three eligible product lines at EUR 12.00 each, a EUR 4.00 service line excluded from this allowance, and a zero-value reference line. The approved policy splits the allowance equally among positive-value eligible product lines. It excludes the service and reference lines, and it must not reduce an eligible line below zero.
| Line | Starting amount | Eligible for this allocation? |
|---|---|---|
| L-10 | EUR 12.00 | Yes |
| L-20 | EUR 12.00 | Yes |
| L-30 | EUR 12.00 | Yes |
| L-40 | EUR 4.00 | No: excluded service |
| L-50 | EUR 0.00 | No: zero-value reference |
The starting order total is EUR 40.00. The approved allowance is EUR 1.00, so the resulting total must be EUR 39.00. Those are independent acceptance conditions, alongside the eligibility rules.
The policy also specifies how to distribute a remainder: give each eligible line its whole-cent base share, then assign remaining cents in ascending stable line-reference order. This rule is explicitly approved for the example. It is not presented as the universally correct accounting or commercial rule for every business.
Locate the missing cent
The original calculation divides one euro by three and independently rounds each displayed share to EUR 0.33. The saved allocation records contain 33 cents against each eligible line. Their sum is 99 cents.
The order header still records the approved allowance as 100 cents. Consequently, the lines after allocation total EUR 39.01 while the header expects EUR 39.00. The discrepancy is already in the saved allocations; it is not caused by an Estonian decimal separator or an incorrectly styled currency symbol.
The investigation checks the included line references and confirms that only L-10, L-20 and L-30 participated. The excluded service and zero-value line were not accidentally counted. That rules out the eligibility selection as the cause and focuses the correction on the undistributed remainder.
Apply the approved remainder rule
For this two-decimal euro calculation, the tool works with exact cent amounts. Dividing 100 cents among three eligible lines yields a base share of 33 cents and a remainder of one cent. The stable reference order assigns that remaining cent to L-10.
The corrected allocation is therefore 34 cents to L-10, 33 cents to L-20 and 33 cents to L-30. Their sum is exactly 100 cents. L-40 and L-50 retain zero allocation. The calculation does not depend on the current screen sort, the order in which a user selected rows or a translated product label.
| Line | Allocated allowance | Amount after allocation |
|---|---|---|
| L-10 | EUR 0.34 | EUR 11.66 |
| L-20 | EUR 0.33 | EUR 11.67 |
| L-30 | EUR 0.33 | EUR 11.67 |
| L-40 | EUR 0.00 | EUR 4.00 |
| L-50 | EUR 0.00 | EUR 0.00 |
| Total | EUR 1.00 | EUR 39.00 |
The correction recalculates the draft allocation from the approved amount and eligible lines. It does not add another allowance on top of the previous attempt. Applying the same calculation again to the unchanged draft produces the same allocation records and total.
Check the boundaries, not just the happy total
The fictional acceptance record confirms the line values above, the unchanged excluded service and the zero-value reference. Reversing the visible table sort does not move the extra cent away from L-10 because the policy uses stable reference order.
A zero-allowance control produces zero allocation on every line and preserves the EUR 40.00 starting total. A control with no eligible positive-value lines stops for review rather than dividing by zero or assigning the allowance to the excluded service. An excessive allowance that would breach the agreed nonnegative-line condition is rejected under this fixture’s policy; it is not silently clamped to another amount.
These checks establish the defined draft calculation. They do not establish tax correctness, invoice validity, a provider’s refund behaviour or how an already posted transaction should be corrected. Any such operation needs its own approved policy, supported interface and review.
Present the result without changing its meaning
The interface can use the agreed Estonian amount presentation while retaining the currency and numeric meaning. A displayed decimal comma must not become part of an ambiguous machine payload. Keep the calculation value, currency and human formatting distinct, and check the actual import or provider contract before transferring amounts.
Do not generalise this two-decimal example to every currency or every provider field. A provider may specify minor units, decimal strings or another representation. The implementation must follow that exact contract. If a payment journey is included, test with the provider’s supported sandbox and designated test data; this internal allocation fixture authorises no live charge.
The product and order service covers these record boundaries. Before commissioning a calculation, bring the approved total, eligibility definition, remainder rule and expected controls. Without those decisions, a developer can make the numbers add up while still implementing the wrong policy.