Rule of the week: Invoice Number Reuse

You're reconciling payables for the month and you notice invoice INV-2041 sitting in the ledger twice. Same number, same amount pattern roughly, but one is from a electrical contractor and the other from a landscaping business. Your first instinct is that someone's fat-fingered a duplicate payment. But the vendors don't match, so it can't be the same invoice paid twice — it's two completely unrelated invoices that happen to share a number. Nobody did anything wrong, and that's exactly why it's easy to miss.

This is a quiet failure mode in accounts payable. Most duplicate-payment checks are built around "same invoice number, same vendor" or "same amount, same vendor, similar date" — sensible defaults, because that's how genuine double-payments happen. But invoice numbering isn't controlled by you. Two different suppliers can both run sequential numbering from their own accounting systems, both starting fresh at the start of a financial year, both landing on 1004 or INV-2041 purely by coincidence. Some suppliers use generic templates with low, short invoice numbers that collide constantly. On their own, these aren't duplicates. But when a vendor-matching rule is the only thing standing between you and a real error, a coincidental collision can mask an actual mis-keyed vendor code, or worse, hide a case where an invoice was recoded to a different supplier after the fact and nobody checked the number sequence still made sense.

A worked example

Say your ledger has:

• Invoice 4521 — Vendor: Ironbark Electrical Pty Ltd — $2,860.00 — dated 14 March
• Invoice 4521 — Vendor: Coastal Landscaping Co — $940.00 — dated 22 March

Different amounts, different dates, different vendors. Nothing here suggests a double payment. But now imagine a bookkeeper, working from a stack of PDFs, accidentally codes the Coastal Landscaping invoice to Ironbark's vendor card because the two entries are adjacent in the batch. The ledger now shows Ironbark with two invoices numbered 4521, both paid. A vendor-only duplicate check won't flag it, because from the system's point of view it's just "vendor X, invoice 4521" appearing once — the second one silently overwrote nothing, it's a separate coded entry, but the payment has gone to the wrong bank account. The invoice-number-reuse pattern is the tripwire that gets you looking at it before the vendor calls asking where their money is.

How to find it manually

You don't need software for this — you need a sorted list and patience.

1. Export your accounts payable transaction listing for the period you're checking (Xero: Business → Bills to pay, export all, including paid; QBO: Reports → Transaction List by Date, filtered to bills and expenses).
2. Sort by invoice number, not by vendor or date.
3. Scan for any invoice number that appears against more than one vendor name. Ignore repeats within the same vendor — that's a separate check (true duplicate payment), not this one.
4. For each collision, open both source documents and confirm they're genuinely unrelated invoices, not a miscoding.
5. If the numbers are short (under five digits) or generic-looking (1001, INV-1), expect more false collisions — plenty of small suppliers start numbering from scratch each year. Don't chase every one; prioritise collisions involving larger amounts or vendors you don't recognise well.

The honest cost: this is a full export-and-sort exercise, and on a ledger with a few thousand AP lines a year it takes real concentration to do properly — you're pattern-matching across a long alphanumeric column, and it's the kind of task where tiredness produces both missed collisions and false alarms. It's worth doing at year-end or before a significant payment run, not something to sustain weekly by eye.

FAQ

I found the same invoice number under two different suppliers — is that a duplicate payment? Not on its own. It means two invoices from different vendors happen to share a number, which is common with short or templated numbering systems. Check the amounts, dates, and source documents before assuming an error. It only becomes a real problem if you find evidence one invoice was coded to the wrong vendor.

Why would two genuine suppliers have the same invoice number? Because invoice numbering is set by each supplier's own system, not yours. Many small businesses start a new sequence each financial year or use software defaults like 1001, 1002. With enough vendors, collisions are expected, not suspicious by themselves.

How the rule does this

DUP-005 flags every same-number-different-vendor pair automatically, but it can't tell a coincidental collision from a genuine miscoding — that judgement call is still yours, and it will surface plenty of harmless matches from suppliers with generic sequential numbering, particularly low invoice numbers. What it does catch is the pattern itself, continuously, across every AP line as it's entered, so you're reviewing a short list of collisions rather than sorting the whole ledger by hand each time. Severity is rated medium, since most matches turn out to be benign.

Finanomaly is currently waitlisted.