invoice INV-2870 · seen 2026-09-06
| Payments captured, gross | 656.00 |
| processor fee | (15.26) |
| tax on the fee | (2.10) |
| Should have landed | 638.64 |
| Actually landed | 319.32 |
| Unexplained | 319.32 |
The credit is short by more than the fee explains.
| Ledger expects, gross | 328.00 |
| Customer paid, gross | 656.00 |
| Kept back | (328.00) |
The customer withheld part of the invoice.
Two comparisons, kept apart on purpose. The bank credit is net of the processor’s fee; the invoice is gross. A single “matches” line would hide which side is short.
Shown ahead of the proposal so you can judge whether these cases really are alike, before knowing what was concluded from them.
Seen before. Two captured payments of identical amount against the same order, minutes apart, with only one bank credit and one open ledger entry.
Done then. The customer submitted twice — a retry after an ambiguous confirmation screen. Match only the earlier payment against the credit and the ledger entry. Flag the later payment for refund. Matching both would close the invoice twice and produce a phantom receivable reduction; this is a false accept, the most expensive error in reconciliation.
Seen before. Two payments on one order of different amounts, together equalling the open invoice, with two corresponding credits.
Done then. This is instalment payment, not duplication. The distinguishing test is whether the payments sum to the invoice — duplicates are each equal to the full expected amount and their sum overshoots it. Match both against the single entry and close it. Treating instalments as duplicates would refund a customer money they legitimately owed.
Seen before. A direct transfer credit carries a reference the customer typed themselves — an invoice number or a partial order reference embedded among bank routing text.
Done then. Extract candidate references from the narration and test them against invoice numbers on open entries before falling back to name matching. A customer-supplied invoice reference, when it resolves to an open entry at the same amount, is stronger evidence than a fuzzy name match.
The agent proposed this at 0.78, under the 0.90 threshold set from measured outcomes, so it came here instead. The reasoning is complete; the confidence is what fell short.
duplicate payment
Confidence 0.78 · arithmetic checked
The payments settle to INR 638.64 once each one's own processor fee and tax are deducted, against INR 319.32 that reached the bank. The ledger expects INR 328.00 gross while the customer paid INR 656.00, leaving -INR 328.00 held back.
Confirming writes this into the corpus. It will be found and cited on future cases that look like this one, so a confirmation that is wrong does not cost one record — it becomes something the system reasons from. Decide on the figures and the precedents above, not on the verdict.