Support Desk

How duplicate invoices are caught

The same invoice arriving twice is how double payments happen. NoticeDesk flags it at upload, in a batch, and in History.

Last updated 9 October 2026 · 5 min read

Why this exists

Paying the same invoice twice is the classic accounts-payable mistake: a supplier re-sends a PDF, two people upload the same folder, a statement gets mixed in with invoices. NoticeDesk flags likely duplicates the moment they're extracted, everywhere they appear.

How a duplicate is spotted

A new extraction is compared against your workspace's history on a deliberately conservative key. The invoice number must always match, and so must the supplier, identified by either the supplier name or the supplier's VAT number (spacing and capitalisation are ignored on both). Matching on the VAT number as well as the name is what catches a supplier who bills you as "EDF" one month and "EDF Energy Ltd" the next: it's the same registration, so it's the same supplier. The flag is advisory, never blocking: the extraction still completes and saves, and you decide.

A few things it deliberately does not do: it doesn't treat invoice numbers as equal just because they look similar (INV-001 and INV-1 stay separate documents); it ignores placeholder VAT text like "N/A" or "pending" rather than treating it as a shared identity; and invoices and credit notes are compared separately; a credit note that quotes the same number as the invoice it corrects is never called a duplicate payment.

The check keeps up with your corrections. If an invoice number or supplier was misread and you fix it, saving the edit re-runs the comparison with the corrected values: a real duplicate hidden behind a misread number surfaces at that point, and a false flag caused by a misread clears itself. A record you have marked Not a duplicate stays that way through later edits: the comparison never flags it again against the document you dismissed it against (the record you dismissed it against, or, while the record's details still match it, any record in the same chain of copies), only against a different document. Correct the record so it no longer matches the one you dismissed, and it can be flagged against another record again. Whenever a save raises or clears the flag, the record's timeline says so. The same check also runs when you recover a document through manual review, so a hand-corrected invoice is compared against your history like any other.

The duplicate warning banner above the record: 'Possible duplicate invoice. You already processed invoice NB-100234 from Northbridge Office Supplies Ltd on 3 Jun 2026. Processing it again could lead to a double payment' with a View original button.
The warning names the earlier invoice and when it was processed; View original → opens it read-only for comparison.

Where the flag follows the document

  • On Extract: the banner above, at the moment it matters most, and an entry in the AI Companion feed with Compare (a three-row table: invoice number, date and total, this file against the one in your history) and Not a duplicate. Until you resolve it the band at the top of the record starts with Possible duplicate before the check score, and the pending count includes it; Not a duplicate clears the flag on the record itself: the pill leaves History, the document counts in the VAT Invoice Check period again, and the record's timeline notes the choice ("Possible-duplicate flag cleared: marked as not a duplicate"). If the choice cannot be saved (you are offline, say) the feed says so and the record stays flagged in History.
  • In a batch: the row gets a ⚠ Duplicate pill and a quiet grey tint, and the batch insights count possible duplicates and leave them out of total spend, VAT extracted and spend by supplier.
  • In History: the row keeps the pill until an owner deletes the earlier record or someone marks it not a duplicate, so a duplicate spotted in July is still visible at VAT-return time.
A History row carrying the ⚠ Duplicate pill beside the supplier name.
The flag persists in History: it doesn't vanish once the upload moment has passed.

What to do with one

  1. Compare

    View original → opens the earlier extraction read-only. Same document twice? Or genuinely two invoices that happen to share a number?

  2. Keep or delete

    A true double: a workspace owner can open the copy from History and use Delete record in its detail view, so it can't reach an export (the deletion stays on the audit timeline). Not an owner? The ⚠ Duplicate pill keeps the copy identifiable; ask an owner to remove it. A false alarm because a number or supplier was misread: correct the record and save, and the flag clears. Two genuine documents that happen to match (sister companies trading under one VAT registration, or a supplier that reuses its numbering): choose Not a duplicate in the AI Companion and both count, and a later save never flags either one against the other or against a copy of the other, even after the other is deleted or corrected and one of its copies counts in its place (that copy's timeline notes "Not-a-duplicate decision carried over"); if the flagged record is no longer open on Extract, upload its file again and the stored record comes back on screen with the same chips. While a document carries the pill, the VAT Invoice Check leaves it out of the period totals and the audit pack and says how many it left out. The Total at the top of History and a batch’s insights (total spend, VAT extracted and spend by supplier) leave it out the same way and say so (“1 duplicate left out”), so a rescanned invoice is never counted twice. Not a duplicate brings it back into all of them. Nothing else is blocked, and exports still include it. Delete the earlier record instead of the copy and the document still counts once: the oldest remaining copy takes its place, its pill clears (its timeline notes "Possible-duplicate flag cleared: the earlier record was deleted") and any other copies move their pill onto it ("Possible-duplicate flag moved: the earlier record was deleted"). Delete a copy that later copies were flagged against and they move to the record it was a copy of. Correct a record's number or supplier so its own copies no longer match it and they are handled the same way: they move to the record it was a copy of, or the oldest of them counts in its place. A credit note's View original → clears when the invoice it corrects is deleted.

Also handled quietly

Re-upload the identical file and NoticeDesk recognises it outright, reconnecting you to the existing record instead of storing a copy; the History stays clean without you doing anything. The check runs before any extraction, so a re-upload doesn't use a credit either.