Duplicate invoices in Accounts Payable: a resubmitted document or a new liability?

A supplier resends an email, an employee forwards its attachment to another team, and a scan of the paper copy arrives days later. Each file looks like a new case, although it may concern the same invoice. The risk is not simply a repeated document but an unnoticed second processing route.

Duplicate control in Accounts Payable should connect invoice data, earlier receipts and processing status. Comparing filenames is not enough, nor should every alert be treated as confirmed error. This guide proposes a practical workflow that does not depend on one particular ERP.

1. Separate the message, file and invoice

Give each receipt a case identifier, but do not treat that as evidence of a new liability. One invoice may have several emails and representations: PDF, scan or regenerated printout. Their relationship should be visible to the next person handling the document.

A different attachment name does not prove a different invoice. A file hash such as SHA-256 compares bytes, not the business identity of a document. A new scan of the same invoice can have different bytes. Do not replace invoice-data comparison with a file-only test.

2. Compare source data and agree similarity rules

Compare the relevant client legal entity, supplier, full invoice number, date, currency, amount and document type. Retain the original reference alongside any secondary search representation. Agree rules for letter case, spaces and separators; stripping every non-alphanumeric character can merge different references.

Oracle Financials 25D documents an additional check combining supplier, invoice type, amount, currency and date, which must be enabled. This is an example, not a universal rule for every system. Matching amounts alone are inconclusive: two legitimate invoices can have the same value.

3. Search before posting as well

The duplicate-number workflow warning described for Dynamics 365 Finance concerns an already posted invoice and depends on configuration. Establish separately how your process checks invoices just received, under review or waiting for transfer to the ERP.

Search the agreed intake-queue and ERP scope, including settled documents. Absence from an open-invoice list does not prove that an invoice was never handled. Define who can see receipts from other channels so parallel teams do not independently start processing the same case.

4. Treat an alert as a prompt to investigate

Check the source if OCR reads 0 instead of O or formats a reference differently from an earlier import. Also establish whether one supplier appears under two records. These are investigation clues, not authority to merge master records or change invoice references independently.

A recurring invoice for the next period, with its own number, is not a duplicate merely because its amount matches. A correcting document also needs separate identification and a link to its source document. Obtain a specific supplier explanation when unclear, instead of deleting a document because it looks similar.

5. Define the consequence and decision owner

Distinguish a suspected duplicate, a confirmed resubmission and an alert dismissed after explanation. Record the compared entries, reason, evidence and decision maker. A screen message does not establish that processing or payment is blocked; verify that consequence in the actual configuration.

An external team can collect data and prepare an explanation within the agreed scope. Accounting changes and payment decisions require appropriate client permissions. Never change an invoice number merely to bypass a check. Retain the link between the repeated receipt and original case under the agreed retention rules.

6. Test the control, not just its activation

Using test data, cover the same file arriving again, a new scan of the same invoice, a reference-format variant, a valid invoice for the next period and a separate correcting document. Define the expected result, detection stage and required action for each. Include a case where the first receipt is still queued.

Complement intake checks with a review of entries already created; Oracle Payables Invoice Audit Listing is one example of a supporting tool. BackOffice Outsourcing offers finance and accounting process support. Describe your invoice intake channels to the team to agree the scope of checks and exception handling. Comparing a supplier statement with records is a separate topic in our supplier reconciliation guide.

Sources and scope

• Microsoft Learn: Vendor invoices - duplicate-number workflow controls
• Oracle Financials 25D: Additional duplicate invoice check
• Oracle Financials 26D: Payables Invoice Audit Listing
• Microsoft Learn: Invoice capture - derivation and validation

Primary sources checked on 19 October 2026. Features concern the specified products and releases; they are not a claim of deployment at BackOffice Outsourcing. Scenarios and responsibilities are editorial proposals. This is not an instruction to post entries, make tax corrections or execute payments.