42 precedents, all written by hand before the system ran. Nothing has been deposited from operation yet — confirm or correct a case on the queue and the precedent it writes will appear here.
Seen before. Pressure to reduce the exception count on a reconciliation run where a handful of items have no counterpart at all.
Done then. The exception list is the honest output, not the failure. A reconciliation reporting complete coverage over a population that contains genuinely unmatchable items is misreporting. Keep the residue and state the reason code for each item; the count of unmatchable items is a measurement, not a defect to be optimised away.
Seen before. A bank credit that corresponds to no payment, no invoice, and no recognisable customer — the narration gives no usable reference.
Done then. Leave it unapplied and report it. An unidentified receipt is a real and common state; it belongs in a suspense account until the customer identifies it. Attributing it to the closest open invoice by amount alone is how a receipt ends up credited to the wrong customer.
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.
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.
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 duplicate payment where the second attempt was captured before the first, or where the capture timestamps are indistinguishable.
Done then. Where ordering cannot be established reliably, do not pick arbitrarily. Match whichever payment the settlement credit actually corresponds to if that can be determined from the settlement batch; otherwise escalate. The choice determines which payment gets refunded to a real customer, so a coin flip is not an acceptable resolution.
Seen before. More payments than there are open invoices or bank credits on an order, with the surplus payments equal in value to ones that have already matched.
Done then. Count the counterparts before matching. When payments outnumber the available credits and entries, the surplus is duplication rather than missing bank data. Never invent a counterpart to absorb an unmatched payment — an unmatched payment that should be refunded is a correct finding, not a reconciliation failure.
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. A partial refund against an order where the credit falls short of the expected settlement by less than the full payment value.
Done then. Reconstruct with the actual refunded amount rather than assuming a full reversal. Confirm the payment net of fee and tax, less the refunded amount, equals the credit to the paise. Note that the processor's fee on the original payment is generally not returned on a refund, so the fee stays deducted even where the payment is fully reversed.
Seen before. A refund raised a day or more after the payment settled, so it appears as its own debit rather than reducing a credit.
Done then. Timing determines the treatment. A refund inside the same settlement window is netted into the credit; a later one appears as a separate debit line and must be matched against the original payment as a reversal. Do not attempt to net a later refund into an earlier credit — the arithmetic will not close and the debit will remain unexplained.
Seen before. An unexplained gap between the expected settlement and the actual credit, where the gap does not correspond to any fee, tax rate or withholding rate.
Done then. Check the refund records for the same order and settlement window before treating the gap as a deduction. A refund netted into settlement produces an arbitrary-looking absolute gap with no proportional structure — which is exactly the signature that rules out fees and withholding and points at a refund.
Seen before. The settlement credit is smaller than the payment net of fees, and the missing amount corresponds to a refund issued against the same order on the same day.
Done then. The processor nets same-day refunds against the settlement rather than debiting them separately, so the credit reflects the payment minus its fee and tax minus the refund. Reconstruct the expected credit including the refund and match. The ledger entry, which was raised before the refund, still expects the original gross — close the difference against the refund, not as a shortfall.
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.
Seen before. A credit that sits between the value of one open invoice and the sum of two, and does not equal either.
Done then. This is not a split payment. A genuine split closes the constituent entries exactly. A credit that closes no exact subset is a part payment or carries an unexplained deduction, and forcing it across two invoices creates two wrong balances instead of one open item. Escalate with the shortfall stated.
Seen before. A payment covering several open invoices on the same order, where the invoices were raised on different dates and carry different payment terms.
Done then. Group by order reference first, then confirm the sum across the open entries equals the payment. Differing dates and terms across the entries do not prevent a single settlement — customers commonly pay a statement rather than an invoice. Allocate to the oldest entries first when the payment covers only some of them.
Seen before. One payment and one bank credit against an order that has two open ledger entries, each for part of the value. Neither entry matches the credit alone, but the two together equal the payment amount.
Done then. The customer settled two invoices with a single transfer. Match the one credit against both entries and close them together. Do not match the larger entry and leave the smaller open — a partly-closed order looks like an outstanding receivable and will be chased from a customer who has already paid in full.
Seen before. A customer who has withheld tax on every invoice for several periods sends another payment short by the same proportion.
Done then. A consistent per-customer withholding history raises confidence but does not remove the arithmetic check. Verify the reconstruction against this invoice every time. History justifies acting without human review; it never justifies skipping the computation.
Seen before. A shortfall consistent with withholding, where the gross reconstructed from the net does not land on a whole rupee.
Done then. Reconstruct with decimal arithmetic and half-up rounding to the paise, then allow a tolerance of about a rupee against the invoice. The customer computed the deduction on a rounded base, so a small residue is expected. A residue larger than a rupee means the rate or the base is wrong.
Seen before. A payment that appears short against the invoice, where both a withholding deduction by the customer and the processor's own fee are in play.
Done then. Separate the two deductions and apply them at the right level. Withholding reduces what the customer pays, so it applies to the payment amount against the invoice. The processor fee reduces what settles into the bank, so it applies to the bank credit against the payment. Conflating them double-counts one deduction and leaves the reconciliation open by exactly the fee.
Seen before. A shortfall that is proportional to the invoice but does not land on a familiar withholding rate, and the reconstructed gross does not equal the invoiced amount at any standard rate.
Done then. Do not force the nearest rate. A reconstruction that fails to reproduce the invoiced figure exactly means the hypothesis is wrong — the gap may be a discount, a disputed line, or withholding stacked on a partial payment. Escalate rather than matching at a gross figure that no document supports.
Seen before. A payment short of the invoice by close to ten percent, proportional to the invoice value, against a customer buying professional or technical services.
Done then. Withholding at the higher professional-services rate. Same treatment as the lower rate: reconstruct gross from net, verify against the invoice, match at gross, and carry the deduction as tax receivable. The rate differs by the nature of the supply, so the correct rate must be established from the invoice, not assumed from the observed gap.
Seen before. A payment falls short of the open invoice by very close to two percent of the invoice value. The shortfall is proportional, not fixed, and no refund or fee explains it.
Done then. The customer withheld tax at source before paying. Reconstruct the gross invoice by dividing the received amount by one minus the rate, confirm it equals the invoiced figure, and match at gross. Post the withheld amount to a tax-receivable account against which the customer's certificate will later be applied. The invoice is fully settled, not partly paid.
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.
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.
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. A direct bank credit where the narration fragment plausibly matches two different open customers, and both have an invoice outstanding.
Done then. Do not pick the closer string match. When a fuzzy name is ambiguous, the amount must disambiguate: if only one of the candidates has an invoice at exactly this amount, match that one. If both do, escalate. A misattributed customer receipt is corrected by a human in minutes and by an auditor in months.
Seen before. A credit whose narration is a truncated, uppercased fragment of a customer name concatenated with digits and a transfer keyword. The fragment is not a clean name and will not match the ledger's customer field on equality.
Done then. Match the narration fragment fuzzily against the customer names on open ledger entries, allowing for truncation to the first several characters, removal of spaces, and uppercasing. Require the amount to agree exactly as well — a fuzzy name alone is never sufficient evidence to match money.
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. Two settlement credits land on the same value date and multiple payments are open. Neither credit matches any single payment and it is unclear which payments belong to which credit.
Done then. Solve both groups together rather than greedily assigning the first credit. A greedy assignment can consume a payment the second credit needs, leaving both unreconciled. If more than one subset assignment closes exactly, do not guess — escalate, because a wrong grouping produces two false matches rather than one.
Seen before. A batched settlement credit where the group of payments has been identified, but the total is off by a few paise from the credit.
Done then. Rounding is applied per payment at the fee calculation, so a batch of many payments can accumulate several paise of rounding residue. Allow the tolerance band to scale with the size of the group rather than applying a flat single-payment tolerance, but require the residue to stay within a few paise per member. A larger gap means the group is wrong, not the rounding.
Seen before. A batch credit nearly closes against a candidate group of payments but is short by an amount matching one of the smaller payments in the window.
Done then. Test subsets rather than assuming every payment in the date range belongs to the batch. A payment captured just after the settlement cutoff rolls into the next batch. Confirm the chosen subset closes exactly, and leave the excluded payment open to match the following credit rather than forcing the current one.
Seen before. Several open ledger entries across different orders and different customers, and a single credit whose value date is one or two days after the latest of the corresponding captures.
Done then. The settlement window closes on a cutoff, so the credit's date tracks the latest payment in the batch, not the earliest. When searching for the group, look backward from the credit date across the full settlement window rather than anchoring on the first unmatched payment.
Seen before. A settlement credit that does not equal the sum of the gross payments captured in its window, but falls short of that sum by roughly two percent of the total.
Done then. Net each payment individually before summing. The processor deducts its fee and the tax on that fee per payment, not once on the batch, so summing gross and then applying one deduction leaves a residue that will not close. Compute the sum of individually-netted amounts and it will reconcile to the paise.
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.
Seen before. The bank credit precedes the ledger entry date, because the invoice was raised after the customer had already paid against a proforma or advance.
Done then. Do not require the credit to follow the ledger entry. Match on order reference and amount; the ordering of the two dates carries no reconciliation meaning when both refer to the same commercial event.
Seen before. A payment captured late on a Friday settles the following Tuesday or Wednesday. The reconciliation run flags it as unsettled because the credit fell outside the narrow window.
Done then. Recognise the weekend and holiday effect before treating a late credit as missing. Match on the wider window and record the timing as the reason. A payment is only genuinely missing once the wide window has also elapsed with no credit.
Seen before. Amount and order reference match exactly, but the bank credit is dated three to five days after capture rather than the usual one or two. Weekends, a bank holiday, or a settlement cycle change explain the delay.
Done then. Widen the date window and match. The identity evidence — exact order reference and exact net amount — is far stronger than the date evidence. Treat the date as corroborating, never as disqualifying, when amount and reference both agree exactly.
Seen before. Amounts reconcile to the paise, but rounding of the fee component means the settled figure is one paise off the computed expectation depending on which way the fee was rounded.
Done then. Apply half-up rounding at the point where a percentage meets an amount, once, and compare integers thereafter. A one-paise oscillation is a rounding-convention artefact, not a discrepancy. Never reintroduce floating point to explain it away.
Seen before. A small discrepancy of well under one rupee between what the ledger expected and what settled. Someone has flagged it as a short payment.
Done then. Distinguish an absolute delta from a proportional one before anything else. A fixed sub-rupee gap is rounding. A gap that is a clean percentage of the invoice is a deduction — usually withholding tax — and must be investigated as such even when the absolute figure is small on a small invoice. The test is proportionality, not magnitude.
Seen before. The ledger's expected amount and the payment differ by under a rupee — a few tens of paise in either direction — with no percentage relationship between the gap and the amount. The invoice was almost certainly rounded to whole rupees when it was raised.
Done then. Accept inside the rounding tolerance band of one rupee and match. Record the residual so it can be swept to a rounding-difference account at period end. Do not open an investigation: a sub-rupee gap with no proportional structure carries no information.
Seen before. Payment, ledger entry and bank credit all agree once processor fees are accounted for, and the settlement date falls inside the normal one-to-two working day settlement lag. Nothing about the case requires interpretation.
Done then. Match exactly on order reference and net amount. Close without escalation. Cases of this shape are the volume baseline; spending investigation budget on them starves the genuinely ambiguous ones.
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.