Keep one payment distinct from the amounts allocated to invoices

A payment can be received correctly while the application presents the wrong outstanding balance. The problem may lie in how the receipt is allocated, rather than in the payment provider, currency formatting or bank transfer itself.

This fictional example uses one CZK receipt and two invoice references. Its allocation rule is an assumed, approved rule for the exercise. An actual organisation's finance owner and advisers determine accounting treatment, correction authority and the operations supported by its system.

Establish the receipt before changing balances

Receipt P-91 records CZK 5,000. The source identifies one received payment, not two. The customer has supplied two invoice references, I-31 and I-32, and the responsible finance reviewer has approved the following allocation:

The total allocation is exactly the receipt amount. There is no unallocated remainder in this example. No currency conversion, fee, credit note or refund is involved.

The application instead creates an allocation of CZK 5,000 for each invoice when both references are selected. Each invoice screen then shows a paid indicator. The interface has reused the full receipt amount twice, even though the external receipt still records only CZK 5,000.

Locate the incorrect operation

The investigator compares the source receipt, the selected invoice references, the allocation operation and the resulting records. P-91 is unchanged and unique. The error occurs when the multi-selection handler creates an allocation row for each selected invoice using the same full amount.

This is not a report that accidentally duplicates a correct row. The stored allocation instructions themselves total CZK 10,000. Fixing the display alone would leave the application with an inconsistent financial record.

The test remains in an isolated environment with invented invoice records. A developer should not experiment with production receipts to establish the cause.

Compare the available corrections

One option would be to restrict every payment to one invoice. That would prevent this particular duplicate allocation but discard the legitimate requirement demonstrated by P-91. Another would divide the amount equally between selected invoices. That would invent a rule the finance owner has not approved and produce CZK 2,500 against each reference.

The selected design lets the authorised reviewer allocate explicit amounts within the supported workflow. The application checks that the proposed total does not exceed the amount available from the receipt and that the invoice references are eligible for the operation. It also shows the remaining balance and any amount not yet allocated.

The reviewer decides the amounts; the software enforces the agreed constraints. It does not infer an allocation from the order in which invoice references were typed.

Make the form's meaning visible

The corrected screen displays P-91 once, with its currency and received amount. Each allocation line identifies an invoice and an amount. A summary shows CZK 3,500 plus CZK 1,500, leaving CZK 0 available from this receipt.

For Czech-facing presentation, the organisation can approve a form such as “5 000,00 CZK.” The stored and exchanged value must follow the inspected application's contract. A display string should not become an unexamined instruction to another system.

If a reviewer enters CZK 3,500 and CZK 2,600, the proposed CZK 6,100 total exceeds the available CZK 5,000. The interface identifies the excess and retains the entered lines for correction. The server enforces the same rule; disabling a button in one browser is not the complete control.

W3C's form-notification guidance supports understandable feedback about an error. It does not determine the financial rule or authorise a correction.

Correct the fictional records through the supported route

For this assumed application, the authorised reviewer uses its documented reversal-and-reallocation process in the test environment. The two erroneous allocation entries are marked reversed with their correction reason; they are not silently erased. New active allocations apply CZK 3,500 to I-31 and CZK 1,500 to I-32.

The resulting active allocations total CZK 5,000. I-31 shows nothing outstanding; I-32 shows CZK 1,100 outstanding. P-91 retains its original identity, currency, amount and received status. A second receipt, P-92, remains allocated to the unrelated invoice I-33 exactly as before.

That is the completed outcome in this fictional system. If a real provider does not support such a correction route, its authorised procedure must be established rather than copied from the example.

Check the boundaries before calling it complete

Repeat the allowed allocation and the over-allocation attempt with fresh fixtures. Confirm that a user without allocation authority cannot perform the operation. Inspect both invoice balances and the available amount on the receipt, rather than relying only on the paid badge.

Also ask what happens when the receipt has already been partly allocated. The permitted amount is the available remainder under the actual rules, not automatically the original payment total. Any credit, refund, dispute or cross-currency requirement needs its own defined behaviour and review.

Keep the receipt-to-allocation relationship, approved rule, correction method and tests in the handover. These materials help a future maintainer distinguish a provider-payment problem from an application-allocation problem without changing the wrong record.

Bring a fictional receipt and the balances it should affect to a software or integration discussion. Leave real financial records out of the ordinary project inquiry.