Why invoice matching needs an exception queue

What “matched” should mean before you automate it

Manual matching can depend on knowledge that is never written down. Someone looks at a bank credit, recognises the customer, finds the invoice in Tally and marks it received. That works because the person carries a lot of context in their head: which customer always pays in two parts, which one quotes the wrong invoice number, which one pays on behalf of a sister company.

An automated matcher has none of that context unless it is written down. So the first step is a matching rule set, agreed with the finance head, that says exactly when a bank line and an invoice belong together. A typical starting point:

1. Exact match: same customer, same amount, invoice number found in the bank narration. Auto-match.

2. Strong match: same customer, same amount, no invoice number, only one open invoice of that amount. Auto-match, but log the reason.

3. Everything else: goes to the exception queue.

This is deliberately conservative. You can widen the automatic rules later, once you have seen how the exceptions actually behave.

An illustrative example: a distributor reconciling in Tally

Consider a hypothetical FMCG distributor in Pune that records sales in Tally and receives most payments by NEFT and UPI into one current account. Each week someone downloads the bank statement and reconciles it against open invoices. In one illustrative week, three lines refuse to match cleanly.

Exception 1: a partial payment. A retailer has an open invoice of ₹1,18,000 and pays ₹70,000 with the narration “part pymt”. The amount matches nothing. A careless rule might mark the invoice paid or leave the receipt unallocated forever. The right outcome is a proposed part allocation against the oldest open invoice for that retailer, sent to the queue for a person to confirm, with the balance still showing as outstanding.

Exception 2: a duplicate reference. Two credits arrive on the same day from the same retailer, both quoting invoice INV-2219, each for ₹45,600. One may be a genuine duplicate payment; the second may be meant for INV-2231, which happens to be the same amount. Auto-matching the first and dropping the second into “unallocated” loses the question. Both go to the queue with the reason “reference used twice”, and someone calls the retailer.

Exception 3: a payment with no invoice. A credit of ₹32,500 arrives from a new name. It may be an advance, a payment from a parent company, or a sale billed late. There is no invoice to match. The queue records it as “no invoice found”, and the owner either links it to a customer account as an advance or raises it with sales.

None of these three should be resolved by the software alone. All three should be impossible to miss.

How to design the exception queue

The queue is the part of reconciliation automation that most projects skip, and it is the part that decides whether the books stay trustworthy. A workable design has five fields per item:

• Reason code: partial, duplicate reference, no invoice, amount mismatch, customer unknown.

• Proposed action: what the system suggests (for example, “allocate ₹70,000 to INV-1874”), never applied without approval.

• Owner: one named person, not “accounts”.

• Age: days since the bank line arrived.

• Threshold flag: whether this item needs a senior reviewer.

Thresholds are a business decision, not a technical one. A distributor might decide that any exception above ₹1,00,000, older than seven days, or involving a top-ten customer goes to the finance head. In the UAE the same thinking applies to VAT invoices: a mismatch between the tax invoice amount and the receipt should never be silently absorbed, because the VAT position depends on it.

A test before you trust the matcher

Before switching any matching rule from “suggest” to “apply”, run this test on a past month you have already reconciled by hand:

• Did the matcher auto-match anything that your team matched differently? If yes, the rule is too loose.

• Did every partial payment end up in the queue with the balance still outstanding?

• Did every duplicate reference go to the queue, not just the second occurrence?

• Did every credit with no invoice appear with a reason code?

• Can a reviewer see, for each auto-match, which rule made it?

• Is there a single place where the oldest unresolved item is visible?

If the answer to any of these is no, keep the matcher in suggestion mode. Widening automation on a rule set that fails a past month only produces faster mistakes.

What the dashboard should show

A dashboard that celebrates “matched lines” is reassuring and nearly useless. Watch the size of the exception queue, its oldest item, the value unallocated, and the split by reason code. If “customer unknown” keeps rising, that is a conversation with sales, not a software fix.

Where SolvTree fits

This sits in our automation layer and AI dashboards work: matching that runs alongside Tally, Excel or your accounting system, with an exception queue and a dashboard built around it. We usually start with one bank account and one matching rule set, then widen the rules once the queue behaves predictably.

Next step: If reconciliation takes more of your week than it should, book a free 30-minute operational audit and we will map one reconciliation step and its exception owner with you. The report is yours to keep.