Payment reconciliation
“Your payment is short” is not a number you can act on
A customer pays less than you invoiced. You open your file, they open theirs, and twelve thousand invoices sit in between. So the reconciliation gets postponed, then dropped, and the deduction is absorbed.
The deduction
The shortfall is easy to see. The reason is what takes two days.
Finance knows the total to the rupee within a minute of the credit landing. Which invoices it came out of is a different question — and it is the one that decides whether you can contest any of it.
Invoiced
₹1.42 Cr
Your sales register, one month
Received
₹1.38 Cr
One credit, one payment advice
Short
₹4.1 L
Known in a minute, explained in two days
So it is postponed to the month end, then to the quarter, and eventually the ₹4.1 L is absorbed as a commercial adjustment — not because anyone agreed to it, but because nobody had a day to spend on this one customer’s 1,240 invoices. Figures here are one illustrative month; your own two files replace them on day one.
What it does
Two files in. Four answers out.
Your sales data and their payment advice. Every line of both lands in exactly one of four buckets — and three of them are the conversation you have not been able to have.
Matched
Both sides agreeSame invoice, same amount, nothing to discuss. This is most of the file, and saying so is what makes the rest of it small enough to work through.
Value mismatch
Amounts differThe invoice exists on both sides for different money. The amount is recomputed from quantity, rate, discount and tax, so the answer is not just the gap but which part of the calculation produced it.
Only in ours
We billed it, their record has no traceInvoiced and unacknowledged. Either it never reached their books or it was rejected without anyone telling you — and both are worth knowing before the next payment run.
Only in theirs
They have it, we do notA debit note, a claim, or an invoice number that does not match ours. Separate money from the short payment, so it is flagged rather than quietly netted off.
The two middle buckets account for ₹4.1 L of the ₹4.1 L deducted — all of it, to the rupee. What only they have is separate money, so it is flagged for a decision instead of being quietly netted off. Thirty seconds, not two days.
The price check
The amount is recalculated, not read
Knowing an invoice is short by ₹11,328 is not yet useful. Every line is rebuilt from its own components — quantity, rate, discount, tax — so the gap comes back as a sentence rather than a number.
| Invoice 0090012345 | As billed | At the PO rate | Gap |
|---|---|---|---|
| Quantity × rate | 1,200 × ₹450 | 1,200 × ₹442 | ₹9,600 |
| GST @ 18% | ₹97,200 | ₹95,472 | ₹1,728 |
| Invoice value | ₹6,37,200 | ₹6,25,872 | ₹11,328 |
The answer on this one is a sentence: billed at ₹450 against ₹442 on PO 4500012345 — ₹9,600 of rate, and ₹1,728 of tax carried on top of it. That second figure is the one hand-checking always misses, because nobody recomputes GST on a rate difference.
- Check 1
Quantity × rate
The basic value is recomputed from the line, not read off the invoice total
Catches: Typed totals, stale extracts, a line edited after the value was set
- Check 2
Rate against the contract
The billed rate is compared with the rate on the PO or the price list in force on the invoice date
Catches: The single largest cause of short payment — and sometimes an under-billing in your favour
- Check 3
Quantity against the GRN
Billed quantity against the quantity actually received, where the portal publishes it
Catches: Short receipt, damage and rejection deducted without a debit note
- Check 4
Discount and scheme
Agreed discount, scheme and rebate applied once, at the agreed percentage
Catches: A scheme applied twice, or applied to a period it does not cover
- Check 5
Tax on the corrected value
Tax recomputed at the invoice rate on the corrected basic value, then rounding
Catches: A rate gap quietly multiplied by 1.18 before it reaches the payment
It cuts both ways, and that is deliberate. The same recalculation finds the lines where your own invoice was wrong — billed under the contract rate, or a scheme applied that had expired. Better to find those before the customer does.
The why
Four reasons, and how much each one is worth
Once every line is recalculated, the mismatch bucket stops being a list of invoices and becomes a short list of causes — which is what you take into the call.
| Reason | What the recalculation found | Invoices | Value |
|---|---|---|---|
| Rate difference | Billed rate above the PO rate | 14 | ₹1,34,000 |
| Short receipt | Billed quantity above the GRN quantity | 9 | ₹62,000 |
| Scheme not applied | Agreed discount missing on the invoice | 5 | ₹41,000 |
| Tax and rounding | Tax rate or rounding differs by paise per line | 3 | ₹23,000 |
| Value mismatch, total | 31 | ₹2,60,000 | |
That total is the Value mismatch bucket — the same 31 invoices and the same ₹2.6 L, split by cause. Rate difference alone is 52% of it, which is usually one price master that was never updated rather than 14 separate arguments.
Proof
Every rupee is traced, or the report is not produced
Reconciliation is easy to write and hard to trust, because the failure mode is silent: a few rows quietly fall out and the totals still look beautiful. These are the conditions on printing anything at all.
The tie-out, on the month above
Your file: 1186 + 31 + 18 = 1235. Their file: 1186 + 31 + 5 = 1222. Across the four buckets, 1240 distinct invoices — every line of both files, counted once and counted somewhere.
Both totals tie first
The four buckets must account for every line of your file and every line of theirs. If the counts or the values do not tie, the run stops and no report is produced — a reconciliation that is 99% right is just a different argument.
Blank rows are set aside and counted
A missing invoice number, an unreadable amount, a blank date — each one is quarantined, counted, and the count is printed next to the result. Nothing is silently dropped to make the totals agree.
Every figure opens into its invoices
No number appears without the rows behind it. A disputed total ends in a list of invoice numbers you can send back, which is the only form of this conversation that ever closes.
The match
Three passes, and then it stops guessing
Invoice numbers never agree across two systems. Yours carries leading zeros and a plant prefix; theirs was retyped by someone in accounts payable. So the match runs in passes — and the last one is the one that matters.
| Pass | Rule | Why |
|---|---|---|
| Exact | Invoice number, character for character | Most of the file clears here. |
| Normalised | Leading zeros, plant prefixes, slashes and spaces removed from both sides before the compare | SAP writes 0090012345, their AP system typed 90012345/24-25. |
| Amount and date | Same value on the same day, inside a tolerance you set | For the rows where the number is unusable on one side. |
| Unmatched | Reported as unmatched | A line that survives three passes is not forced into a pair to make the report look tidy. |
The tolerance and the normalisation rules are yours to set, because your invoice numbering is yours. What is not adjustable is the last row: an unmatched line stays unmatched, and is reported as one.
Their file
You already have the customer's data
What stops this being done today is never the software. It is the belief that half the data belongs to someone else. It does not — it arrives with the payment, and it sits in a portal your team is already logging into.
Payment advice
Arrives with every payment, invoice by invoice, out of the customer's own AP system. It is the file the deduction was calculated from.
Customer portal
GRN and inbound status against each invoice, downloadable. Most OEM and large-retail portals publish it, and your team is already logging in to check it one invoice at a time.
Debit notes
Rate difference, shortage, quality, late delivery. The reason code is on the note — which is how a value mismatch stops being a mystery and becomes a line you can accept or contest.
Nothing has to be requested from the customer and nothing has to be built on their side. It is the same reading pattern as everything else here — an API where there is one, a scheduled export where there is not.
Related
The same method, on the other half of the ledger
Different files, one idea: read both sides out, check them against rules, and show only what needs a decision. These pages follow it through purchasing.
Exception Management
Exceptions ranked critical to normal, each with the value sitting behind it.
Read moreSupplier Follow-up Automation
Follow-up drafts, an audit log, and a scorecard that builds itself.
Read morePO Confirmation Tracking
Confirmation received, pending and ageing — checked on every line, every day.
Read moreOr start from the beginning: the full platform, the time and ROI calculation or AI & business automation beyond procurement.
Bring one payment advice and one month of sales data
Two files is the entire setup. You will have the four buckets — and the invoice numbers behind the mismatch — before the call ends.
Book a demo