Precedent

Sunrise Bakery

invoice INV-2175 · seen 2026-09-12

Where the money went

At the bank

Payments captured, gross5,397.00
processor fee(125.50)
tax on the fee(17.30)
Should have landed5,254.20
Actually landed5,254.20
Unexplained0.00

The credit ties out.

Against the invoice

Ledger expects, gross5,397.00
Customer paid, gross5,397.00
Kept back0.00

The customer paid in full.

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. split payment written by hand at set-up · trusted at 0.88

    Seen before. Two ledger entries under one order reference, and a bank credit that equals their combined value net of the processor's fee on the single payment behind it.

    Done then. Net at the payment level, not per invoice. There was one payment, so there is one fee, and it must be deducted once from the combined invoice total. Deducting a fee against each invoice separately overstates the deduction and leaves a residue equal to one fee.

  2. netted settlement written by hand at set-up · trusted at 0.93

    Seen before. One bank credit is materially larger than any single open invoice and does not equal any of them. Several payments were captured across distinct orders in the day or two before the credit's value date, and no single one accounts for it.

    Done then. This is a batched settlement, so the task is grouping rather than joining. Sum each candidate payment net of its own fee and tax, then find the subset whose total equals the credit exactly. Match the whole group to the credit at once. Never match the credit to the largest single payment and leave the remainder unexplained.

  3. exact match written by hand at set-up · trusted at 0.97

    Seen before. A single captured card or UPI payment, one open ledger invoice for the same order, and one bank credit a day or two later. The credit is smaller than the invoice by a few hundred paise and the gap equals the payment processor's fee plus GST on that fee.

    Done then. This is a clean match, not a shortfall. Compare the bank credit against the payment amount net of fee and tax, and compare the ledger's expected amount against the payment gross. Both must hold. Do not compare the bank credit to the invoice directly — that comparison fails on every correctly settled payment.

What it proposes

netted settlement

Confidence 0.94 · arithmetic checked

The payments settle to INR 5,254.20 once each one's own processor fee and tax are deducted, against INR 5,254.20 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