A client sends one NEFT for ₹30,000 with no reference, covering three invoices. Someone then spends an afternoon working out which three. Upload your open invoices with the statement and the arithmetic does it — including the combinations.
Your invoice list
Date and party are optional and are only ever echoed back — they take no part in matching.
Questions
How does it match a payment with no reference number?
By amount. An exact match is found first, then anything within a rupee of rounding, then combinations — if a deposit equals the sum of three open invoices, those three are proposed. Nothing is inferred from party names, because a name match is not evidence and an auditor will say so.
What happens when a client pays several invoices at once?
The engine searches for the set of open invoices whose total equals the deposit, preferring the smallest set that fits. Two invoices adding up is far likelier than five, so pairs are tested before larger combinations.
Will it slow down with hundreds of open invoices?
No. Finding a subset that sums to a target is an exponential problem, so the search is deliberately bounded — the nearest candidates, and combinations up to four invoices. A combination outside those bounds is reported as unmatched rather than found slowly. Being fast and honest beats being exhaustive and unusable.
Can one invoice be matched twice?
No. Each invoice is consumed by at most one deposit, and duplicate invoice numbers in your CSV are rejected on import — a duplicate would let one invoice settle a deposit that was never actually covered.
What format does the invoice list need?
A CSV with the invoice number and amount, optionally a date and party. Amounts can be written the way a spreadsheet exports them — 11800, "11,800.00" or "₹11,800.00" all read correctly.