Controls for invoice intake and posting

Prevent duplicate invoice records without rejecting legitimate work

A supplier resends an attachment. Two staff forward the same invoice. A slow posting request times out and the automation tries again. These are different routes to the same problem: the business cannot tell whether an obligation has already been recorded. Duplicate prevention needs a decision at intake and another control at the point a record is created.

This guide describes a proposed control design, including the difficult cases where two documents look alike but should not be treated as the same invoice. It does not assume your current accounting system supports a particular interface or duplicate protection feature.

Review your duplicate invoice controls (03) 9003 0111

Four questions before any invoice is posted

Identity

Which obligation does this document represent?

Separate the supplier, invoice reference and entity from the attachment filename.

History

Has that obligation already been handled?

Search pending work as well as posted records and preserve the result of earlier attempts.

Revision

Is this a replacement or another invoice?

A changed file is evidence to inspect, not permission to create another payable.

Commit

Can simultaneous workers create two records?

The final write needs a control that survives retries and concurrent processing.

The duplicate problem has several identities

Treat document identity, invoice identity and posting identity as related records with different jobs. Combining them into one field creates avoidable blind spots.

The file is not the invoice

A file fingerprint can identify the same bytes arriving twice. It cannot establish that a newly scanned copy represents a different obligation. Conversely, one attachment may contain several invoices, each needing its own decision. Store the attachment relationship without making it the only duplicate key. Preserve the original file so a reviewer can inspect what changed between deliveries.

The supplier name is not a reliable key

Names can be abbreviated, misspelt or reused across entities. A proposed matching process should resolve the sender and printed supplier information to an approved supplier record, then expose ambiguity. Do not merge suppliers automatically because the displayed names are similar. A correct duplicate decision for one entity can be wrong for another business in the same group.

A retry is not a new request

When a posting request fails to return a response, the outcome may be unknown. It does not automatically mean nothing was created. Preserve an operation reference before the attempt and reconcile the destination afterwards. If you cannot establish what happened, hold the work for investigation rather than starting a second independent creation attempt.

A match is a review decision

An exact match on the agreed business identity may justify stopping a resend. A close match on amount, date or description is usually a reason to inspect evidence. Record the strength and basis of the match. Staff should be able to see why an invoice was held and which existing record it resembles, instead of receiving a vague duplicate warning.

Build prevention across the whole lifecycle

The exact implementation depends on your systems. These six control points describe the behaviour to require and verify during scoping.

Traceable arrivals

Capture every arrival

Assign an intake identifier when the message or file enters the workflow. Retain the channel, received time, sender reference and attachment fingerprint. Link repeated arrivals to the existing intake rather than deleting their history. A resend may carry a useful supplier message even when the invoice itself is unchanged. Record the reason processing continued or stopped so staff can answer a later query.

An inspectable comparison key

Resolve the business identity

Use an approved supplier identifier, the receiving business entity and the invoice reference under a documented normalisation rule. Keep both the original printed reference and the comparison form. Be cautious about stripping punctuation or leading zeroes: those characters may distinguish real invoices. If identity cannot be established from the permitted evidence, create a specific review task instead of manufacturing a key.

A match with search coverage

Check all relevant states

Compare against invoices waiting for review, attempts currently being posted, confirmed destination records and records that were cancelled or replaced. A check against only the final ledger misses concurrent intake. A check against only the inbox misses an invoice entered manually. State which systems and time range were searched, and keep a missing search response separate from a clean no-match result.

A reasoned hold or continuation

Classify revisions and near matches

Present the original and incoming documents together when key fields match but amounts or content differ. Ask whether the new version replaces, supplements or corrects the previous obligation. Link credit notes explicitly under the business's approved process. Avoid a rule that simply selects the newest email, because receipt order is not reliable evidence of commercial authority.

A controlled write boundary

Protect the creation operation

Require a durable operation identifier and a mechanism that prevents two workers from committing the same approved request independently. Where the destination offers a suitable supported control, verify its exact behaviour. Otherwise design a controlled single-writer or reservation pattern and test failure recovery. A pre-check followed by an unprotected write still leaves a gap for another worker.

One recorded business outcome

Reconcile and explain the outcome

After posting, read the destination record and connect its identifier to the intake and operation records. If the response was lost, use that relationship to resolve the outcome before retrying. Show the result to staff in plain language: existing record found, revision held, posting confirmed or outcome unresolved. Make manual overrides attributable and require a reason.

Resends and lookalikes need different handling

Task	Traditional	Proposed control response	Notes
Identical attachment resent	Process every new message	Link the arrival to the existing document decision	Preserve the supplier's new message without creating another invoice record.
A scan of a previously emailed PDF	Different bytes suggest a new invoice	Compare the business identity and source evidence	The fingerprint is only one signal and cannot identify the underlying obligation alone.
Two workers start together	Both find no posted record	Reserve or serialise the approved creation request	Test the actual overlap, not two runs started several minutes apart.
A supplier repeats an invoice number	Reference alone is treated as unique	Inspect entity, supplier policy and supporting evidence	Your rule must reflect real numbering behaviour without silently accepting collisions.
Amount changes on a resend	Latest document wins	Hold as a potential revision	Show the difference and follow the business's approved correction procedure.
Posting times out	Submit another creation request	Reconcile the original operation first	Unknown outcome is a distinct state requiring investigation or a safe supported retry.
Staff entered the invoice manually	Inbox history is empty	Search the destination using the agreed identity	State the limits when the destination cannot support the required lookup reliably.
A credit note shares the reference	Reject it as a duplicate invoice	Preserve document type and relationship	A credit may be a separate authorised record rather than a repeated payable.

Failure modes to test before relying on the control

Normalisation merges legitimate references

Removing every symbol or leading zero can make two distinct supplier references look identical. Keep original values and document each transformation. Test examples that should match and examples that must remain separate, particularly across supplier and receiving-entity boundaries.

The lookup silently fails

An unavailable destination or incomplete search cannot prove there is no duplicate. Require the check to report completion, coverage and result separately. Route a failed lookup to a hold state with an owner, rather than using an empty result as permission to post.

The reservation never expires safely

A worker may stop after claiming an invoice. Recovery should inspect what happened before releasing that claim. An automatic timeout that simply frees it can enable a second post after the first succeeded. Make the recovery decision traceable to the original operation.

Reviewers bypass a noisy warning

If legitimate recurring invoices constantly trigger vague alerts, staff may dismiss the warning habitually. Show the fields that matched, the fields that differ and the related record. Track incorrect holds and improve the rule without removing the final creation protection.

An override becomes permanent permission

An authorised exception for one invoice should not disable checks for that supplier forever. Scope overrides to the specific decision and retain the evidence, reason and approver. If a supplier numbering pattern needs a policy change, review and version that policy separately.

Only the happy path is demonstrated

A normal resend test does not establish behaviour during overlap, timeout or restart. Use controlled failure cases in a safe environment and verify the destination state after each. The strongest evidence is the actual number and identity of records created, not a successful job log.

Worked example: two arrivals and one lost response

Imagine an accounts mailbox receives an invoice while a project manager forwards the same document to a second intake address. Both arrivals are valid messages and should remain in the history. The attachment fingerprints match, but the proposed system does not rely on that alone. It resolves the supplier and receiving entity, reads the invoice reference and links both arrivals to one candidate obligation. Only one processing operation should be authorised to create the destination record.

Now suppose the authorised worker sends the creation request and loses its connection before receiving a response. Its status must become outcome unresolved, not failed and ready to repeat. The second worker should see the existing operation state and refrain from creating a separate request. Staff need a specific recovery task that names the operation, the invoice and the destination being checked. A generic error email encourages someone to upload the file again.

The recovery routine searches for evidence of the original operation using the supported destination mechanism agreed during design. If it finds the created record and the relevant fields agree, it links that record and marks the operation confirmed. If it can establish that no write occurred, a controlled retry may be permitted. If neither conclusion is defensible, a person resolves the uncertainty. The absence of a response is not itself evidence for either conclusion.

Test this scenario by inducing response loss in a safe test environment, then inspect the actual destination independently. Verify both arrival records remain visible, only the authorised number of financial records exists, and the status shown to staff matches reality. Repeat with a restart between the creation attempt and reconciliation. A duplicate prevention design that works only while one process remains alive has not yet addressed this failure.

A review checklist for near matches

Begin with the receiving entity and approved supplier identity. Compare the original invoice references before applying the normalised key. Then inspect document type, date, amount, currency and line content. Ask whether the new document refers to the same work, a separate stage, a recurring service period or a correction. Similar amounts are evidence for inspection, not a sufficient reason to suppress a payable.

Check the state of the existing record. Pending review, posted, cancelled and replaced are different situations. Identify who can authorise the next action and which supporting record they need. Record a concise reason that a future reviewer can understand, such as same obligation resent unchanged or revised amount awaiting approval. Avoid an unexplained override checkbox that loses the business reasoning.

When reviewing control performance, count false holds and missed matches separately. Include how long held items waited and whether staff could resolve them from the information shown. A high number of stopped documents can indicate useful prevention, repeated supplier behaviour or an overly broad matching policy. Inspect examples from each group before claiming the control has reduced duplicate payments or improved efficiency.

Reviewing a control without overstating its benefit

A duplicate prevention report should distinguish an identical resend, a potential duplicate held for review, a confirmed duplicate obligation and an incorrect hold. Those are different observations. Stopping a message at intake is not evidence that a duplicate payment would otherwise have occurred. Staff may already have caught it downstream. Describe the actual control outcome and avoid turning every blocked attachment into a financial saving.

For each prevented creation, retain the incoming identity, matched record and reason the system stopped. Sample those decisions to check that legitimate invoices were not suppressed. Review false holds with the finance owner and look for a consistent cause, such as a supplier that reuses references across service periods. Amend the matching policy only after the business relationship is understood. Keep the final write protection even when the intake matching rule becomes more specific.

Review unknown posting outcomes separately. Record whether reconciliation found an existing record, established that nothing was created or required manual investigation. Include the time and evidence needed to resolve uncertainty. A system that avoids duplicate creation but regularly leaves staff unable to determine what happened still needs operational improvement. The next change may be better operation references or clearer destination visibility rather than a more elaborate similarity model.

Finally, trace manual overrides. An override should show the particular invoice, the evidence and the authorised reason for continuing. Check whether the eventual destination record matches that decision. Repeated overrides of the same kind suggest the policy or source data needs attention, but they do not automatically justify disabling the control. A reviewable history lets the business improve the rule while preserving accountability for each actual obligation.

How Yes AI can help design the control

Map the paths that create records

We can review automated intake alongside manual entry, imports and supplier portals. A proposed control should account for every relevant creation route. The outcome is a map of where duplicate checks operate, where they can be bypassed and which system holds the final record.

Define the matching policy

Working with your finance owner, we can specify exact matches, potential revisions and uncertain cases. The policy should explain when staff may continue and what evidence they need. This avoids leaving the matching decision entirely to an opaque similarity score.

Test failure recovery

A scoped implementation can include overlapping workers, lost responses and restarts. We can retain evidence of the destination records and recovery actions. Access and capabilities of the destination system need verification before a specific technical design is promised.

Keep the solution proportionate

A low-volume business with one controlled entry point may need a clearer review procedure rather than a custom service. If reliable destination lookups are unavailable, a review-first approach may be more appropriate. We can scope the smallest change that addresses the observed failure route.

Move from repeated invoices to a controlled decision

Begin with the actual duplicate pathways and prove the final record state. Avoid deploying a broad matching rule before reviewing legitimate exceptions.

Trace recent arrivals

Inspect approved examples of resends, revisions and manual entry. Identify which records demonstrate the same obligation and where staff currently make that judgement.

Agree identity and exceptions

Document the comparison key, normalisation rules and handling of credit notes, revised documents and repeated references. Keep uncertain cases visible in the policy.

Design the write boundary

Choose a supported method for preventing concurrent creation and resolving unknown outcomes. Confirm destination capabilities and define who owns failed reconciliation.

Exercise failure scenarios

Run safe tests for duplicate arrivals, simultaneous workers, response loss and restart. Inspect the destination records independently from the workflow's own success message.

Roll out with review evidence

Start with the agreed document group. Track prevented duplicates, incorrect holds and overrides, then refine the policy while preserving the underlying operation history.

Turn this guide into your next steps

Use these steps to prepare your own review. Tick a step once you have recorded its evidence. Ticks are temporary and are not saved or sent to us.

Bring one example of the process you want to improve. We can help define the scope, checks and next decision. Consultation options and any fee are shown before you book.

Review your duplicate invoice controls

FAQ

Is checking the invoice number enough?

It can be one part of an exact comparison, but it needs the supplier and receiving entity context. Different suppliers may use the same number, while one supplier may have multiple numbering series. Keep the printed reference and the comparison rule visible. Whether a particular combination is sufficiently unique must be established from your own process and examples.

Can AI identify duplicate invoices?

AI can be evaluated as an assistant for extracting identifiers or explaining similarities between documents. The final protection should not depend solely on a free-form opinion that two files look alike. Use explicit business identity rules and controlled posting behaviour, with review for uncertain matches. Test false holds as carefully as missed duplicates.

What happens when an invoice is resent as a new PDF?

The attachment fingerprint may change even when the business obligation is the same. Compare the extracted identity against relevant pending and posted records. If the contents differ, treat it as a potential revision and show the difference. Do not assume a new filename or export timestamp establishes a new payable.

How should corrected invoices be handled?

Follow the organisation's approved correction process, which may depend on the state of the existing record. The automation should present the original record, new document and material differences. It should not independently decide that the latest email replaces a posted invoice. Record the authorised decision and link the documents so future resends resolve consistently.

Why is a timed-out posting request dangerous?

A timeout describes what the caller observed, not necessarily what the destination did. The record may have been created before the response was lost. Reconcile the original attempt using a durable reference and a supported lookup. If the outcome remains uncertain, hold it rather than assuming another creation request is harmless.

Can the workflow delete a duplicate automatically?

Deletion is a separate business action and should not be inferred from a matching result. This guide focuses on preventing duplicate creation and referring uncertain cases. If a duplicate already exists, finance staff need to assess its state and the appropriate correction procedure. Preserve the evidence and obtain the required authorisation before changing financial records.

What evidence should a supplier query show?

Show the incoming invoice reference, the relevant existing record, the match basis and the current handling status. Include the history of resends and any authorised revision decision. Avoid exposing unrelated supplier or customer information. A clear explanation helps staff resolve the query without rerunning the invoice or accidentally creating another version.

Find the gap where duplicates can still enter

Bring a resend, a corrected invoice and an example of a failed posting attempt. Yes AI can scope the matching rules and the final creation control your workflow needs.