invoice INV-8328 · seen 2026-09-02
| Payments captured, gross | 0.00 |
| processor fee | 0.00 |
| tax on the fee | 0.00 |
| Should have landed | 0.00 |
| Actually landed | 2,540.00 |
| Unexplained | (2,540.00) |
The credit is short by more than the fee explains.
| Ledger expects, gross | 2,540.00 |
| Customer paid, gross | 0.00 |
| Kept back | 2,540.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. 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.
Seen before. An unexplained credit is being investigated as a possible processor settlement failure because no payment record can be found for it.
Done then. Before concluding that data is missing, check whether the amount is gross rather than net. A credit that exactly equals an open invoice, with no fee deducted, was almost certainly not a gateway payment at all. Absence of a payment record is the expected state for a direct transfer, not evidence of a gap in ingestion.
Seen before. Bank transfers arriving under RTGS or IMPS rather than NEFT, with the same pattern: no processor record, gross amount, machine-generated narration.
Done then. Treat all direct transfer rails identically for reconciliation purposes. The rail affects timing and narration format, not the reconciliation logic — no processor fee is deducted on any of them, so the credit is always gross against the invoice.
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.
direct neft bypass
Confidence 0.78 · arithmetic checked
The payments settle to INR 0.00 once each one's own processor fee and tax are deducted, against INR 2,540.00 that reached the bank. The ledger expects INR 2,540.00 gross while the customer paid INR 0.00, leaving INR 2,540.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.