Preventing duplicate invoice records requires a processing-state design, not just an extraction model. If the same file can reach a flow twice, define how the workflow recognizes a repeated submission and how it resumes a partially completed attempt.
This is a design guide for document intake using AI Builder and Power Automate. It does not claim to detect fraud or authorize payments. Use invented invoices and an isolated destination while validating the duplicate-handling rules with the process owner.
Separate a repeated event from a repeated business document
A storage trigger can fire more than once for one source object. Separately, the same invoice may arrive as two different files with different names. A rule that tracks only the storage identifier handles a different problem from one that checks a supplier's invoice identity.
Microsoft's document processing action guide describes the extraction inputs and outputs. It does not make the surrounding workflow a business duplicate-detection service. Treat the recognized values as proposed data that needs validation before they become a definitive record.
Define the intake identity
Choose an approved way to identify the source object and relevant revision. If replacement content can keep the same filename, filename alone is insufficient. Document whether a revised file should be rejected, reviewed or processed as a new version.
Define the business identity separately
An invoice number may not be globally unique across suppliers. Ask the owner which combination of validated values identifies the transaction. Do not automatically discard a record solely because one extracted string matches an earlier value.
Reserve a processing state before expensive work
Design an approved state store with outcomes such as received, processing, needs review, completed and failed. Record a reservation through a mechanism that handles simultaneous attempts safely. A separate “look up, then create” sequence can race if two runs both find nothing at the same time.
The document processing FAQ explains that processing consumes capacity and that business documents should be prepared appropriately. Duplicate prevention should therefore be considered before repeated extraction, not only after duplicate rows appear in the final register. Check current licensing separately; no fixed cost saving follows from this design alone.
| Situation | Required policy |
|---|---|
| Same event repeated | Recognize the existing intake attempt |
| Same invoice in another file | Review the validated business identity |
| Failure after extraction | Resume safely without repeating completed effects |
| Two simultaneous runs | Atomic reservation or equivalent supported coordination |
Mark completion after the required effects succeed
Do not set the document to completed before all required validated records are written. Equally, do not create a second record simply because the final status update failed after the write. Store enough correlation to recognize that the destination effect already exists.
Keep retryable and review states distinct
A temporary service error and an ambiguous invoice match need different responses. One may permit a controlled retry; the other may need a person to decide. An unlimited retry loop can turn a validation problem into repeated processing and notifications.
Preserve a source reference without broad disclosure
Retain an authorized link or internal reference for the reviewer. Avoid placing full extracted invoices in general logs. The state record should support diagnosis while following the organization's access and retention rules.
Test duplicates at deliberate failure points
Submit the same harmless input twice, then submit a renamed copy. Test two near-simultaneous attempts under an approved test setup. Also simulate a failure after the destination write but before the completion marker, without touching a live financial process.
The expected outcome is defined by the business policy: one accepted record, an explicit review or a safe continuation. Do not declare success merely because only one run happened to finish during a quiet manual test.
Our SharePoint metadata guide can help define source references and processing-state fields if SharePoint forms part of the design. It does not replace the need for a supported concurrency mechanism.
Assign an owner for clearing failed reservations. Otherwise a protective processing marker can leave a valid document permanently stranded after an interrupted run.
Keep a compact state-transition note and the sanitized acceptance cases. A reliable intake process should explain why an input was processed, skipped, resumed or reviewed, with no assumption that accurate text extraction alone prevents duplicate business records.
