Duplicate supplier invoice control for restaurants: hold first, pay once

Duplicate prevention begins before a payment run. Accounts payable may receive an invoice through several channels, and an OCR system may represent the same field differently on each pass. A supplier can also issue a corrected document that should replace an earlier one, or issue a credit note that must reference the original rather than create a second payable claim. GOV.UK’s Procure to pay part 4 lists the single recording of an invoice among its control points. The European Commission’s invoicing material describes the sequential number and other core invoice information, but it also distinguishes EU-wide basics from national rules. Use those fields as evidence in a local workflow, not as a promise that one field alone can identify every duplicate.

Choose keys that survive real document variation

A useful candidate key combines more than the filename. Start with a controlled supplier identity, the invoice number as shown, issue date, gross amount, currency, and perhaps the transaction date or purchase-order reference. Keep a raw version and a normalized version. The normalized form can trim outer whitespace, compare case-insensitively, standardize punctuation, map known supplier aliases, and represent dates consistently. It must not silently rewrite a tax number, invoice number, amount, or supplier legal name. If a field is missing, say so and lower confidence rather than inventing it. A key creates a prompt for review; it does not establish fraud, invalidity, or a tax conclusion.

• Store the source filename, message or portal reference, upload time, and document hash when your system supports it.
• Keep supplier legal identity separate from a trading name or internal alias so two entities are not collapsed into one.
• Compare invoice number and date as fields, not as a single unexamined string; punctuation and leading zeroes can vary in exports.
• Include currency and gross or net basis in the comparison so equal-looking amounts are not mistaken for the same claim.
• Use purchase order, delivery, and credit-note references as corroborating evidence, not as replacements for invoice identity.

Normalize for matching while preserving the original

Normalization makes a comparison tolerant of presentation, not tolerant of unexplained commercial differences. Define the transformations your operation permits and version them. For example, a rule might remove spaces and punctuation from an invoice-number comparison while retaining the displayed value for a human. Another rule might map a known supplier alias to a controlled identity after someone approves that mapping. Do not normalize away a changed invoice number, a changed legal supplier, a changed currency, or a changed amount. When two candidates share a key, show the documents side by side and ask whether one is a retransmission, corrected invoice, credit note, or independent claim. The reviewer’s explanation belongs with the disposition.

Holds, release, and recurring exceptions

A candidate match should create a visible hold that blocks the payment action your local process considers unsafe, while leaving legitimate work possible. Give the hold a reason such as exact key match, close number with different amount, same document through two channels, missing credit-note link, or unresolved supplier identity. Name the person who must review it and the evidence required. Release is a decision, not the disappearance of an alert: record whether the candidate was duplicate, correction, credit, separate invoice, or false positive, and link the approved payment path. Review recurring exceptions by supplier and intake channel. A pattern may justify a process conversation or system adjustment, but it does not prove intent by itself.

Clearly labeled illustrative example: a candidate hold

A repeatable duplicate-invoice process

1. 1Capture the source. Store the original document, intake channel, supplier identity, displayed invoice fields, source reference, and receipt event before transforming anything.
2. 2Build the candidate key. Create raw and normalized values for supplier, invoice number, dates, amount, currency, and supporting references using a versioned local rule.
3. 3Classify the match. Compare candidates and label the reason for review: exact, near, retransmission, corrected invoice, credit note, separate claim, or false positive.
4. 4Place a controlled hold. Block the unsafe payment action, assign an owner and due point, and list the evidence needed to resolve the candidate without deleting either source.
5. 5Review and decide. Compare documents, delivery or PO support, legal supplier identity, tax fields, and correction references. Record the reviewer, reason, and disposition.
6. 6Release and learn. Release only the supported payable claim, preserve the audit trail, and route repeated channel or supplier patterns to a process review with local accounting guidance.