Precedent

unmatchable

seen 2026-09-07

Where the money went

At the bank

Payments captured, gross1,653.00
processor fee(38.44)
tax on the fee(5.30)
Should have landed1,609.26
Actually landed0.00
Unexplained1,609.26

The credit is short by more than the fee explains.

Against the invoice

Ledger expects, gross0.00
Customer paid, gross1,653.00
Kept back(1,653.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.

What the system had seen before

Shown ahead of the proposal so you can judge whether these cases really are alike, before knowing what was concluded from them.

  1. unmatchable no counterpart written by hand at set-up · trusted at 0.91

    Seen before. A captured payment with no open ledger entry for its order and no bank credit at or near its value in any settlement window.

    Done then. There is no valid counterpart, so there is no correct match. Report it as unmatchable with the evidence checked — which windows were searched, which entries were considered — rather than forcing a match to the nearest amount. A wrong match is strictly worse than an honest exception: the exception gets worked, the wrong match gets closed.

  2. direct neft bypass written by hand at set-up · trusted at 0.88

    Seen before. A bank credit exists with an open ledger invoice at exactly the same amount, but there is no payment record behind it anywhere in the processor's data. The narration is a compressed bank reference string rather than an order identifier.

    Done then. The customer paid by direct bank transfer and bypassed the payment gateway entirely, so no processor record will ever exist. Match the credit straight to the ledger entry. Note that the amount is gross, not net, because no processor fee was deducted — this is itself strong evidence of a direct transfer.

  3. unmatchable no counterpart written by hand at set-up · trusted at 0.90

    Seen before. An open ledger entry with no payment and no credit against it after the expected settlement window has fully elapsed.

    Done then. The invoice is simply unpaid, or was paid through a channel not yet ingested. Report it as unmatchable rather than searching progressively wider windows until something coincidentally fits. Widening a search until a match appears manufactures matches from noise.

What it proposes

Below the bar for resolving on its own

The agent proposed this at 0.88, under the 0.90 threshold set from measured outcomes, so it came here instead. The reasoning is complete; the confidence is what fell short.

unmatchable

Confidence 0.88 · arithmetic checked

The payments settle to INR 1,609.26 once each one's own processor fee and tax are deducted, against INR 0.00 that reached the bank.

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.

Correct it instead

A correction is worth more than a confirmation. It records a case the agent got wrong, which is the precedent most likely to stop the same mistake happening again.

Back to the queue