Duplicate order prevention needs two controls: identify when several incoming documents represent the same customer instruction, and prevent a technical retry from creating a second ERP order. These are different problems. A purchase-order number alone can be insufficient; so can a document hash. The process must distinguish a resend, an amendment and a legitimate new release, then verify the downstream result.
For a distributor, duplicate prevention protects more than warehouse time. It reduces avoidable freight, credits, stock allocation conflicts and customer arguments over which order was authorized. This guide provides a proposed operating design and test matrix. Synthetic figures illustrate the economics, including the cost of holding legitimate orders for review.
Find the two places duplicates are created
Business duplicates arrive when the buyer emails a purchase order, uploads it to a portal and forwards it again to an account manager. Different filenames and timestamps conceal a single purchasing instruction. A buyer may also repeat last month's quantities deliberately, so similarity is only a reason to investigate.
Technical duplicates happen after the business instruction has already been understood. An order-creation request reaches the ERP, but the response times out. The automation tries again without knowing whether the first request succeeded. AWS describes this class of problem and the use of caller-provided request identifiers to make retries safer. AWS Builders' Library on idempotent APIs.
The business control needs document relationships and customer context. The technical control needs stable operation identity and reliable reconciliation with the destination. Improving only the first leaves duplicate writes possible. Improving only the second still permits two independently created operations for the same customer instruction.
Read the visual explanation
A confirmed repeat of the same instruction should not create another order.
Review an amendment against approvals and work already completed before applying it.
Confirm a separate new instruction; a different document number alone is not enough.
Illustrative teaching example. The steps above are repeated in readable text below; depicted records are not customer results.
Decide what counts as one order
Define the identity with the actual trading pattern in mind. For an ordinary account, customer legal entity plus customer PO number may be a useful starting key. For a blanket order, add release or call-off identity. Branch-specific numbering may require the buyer branch. Annual number reuse may require a period, but should never be assumed without evidence.
| Incoming situation | Why a simple duplicate rule fails | Proposed treatment |
|---|---|---|
| Same PO, same lines, new email | New message is not new intent | Link as a resend |
| Same PO, higher quantity | Could be a revision | Hold for amendment handling |
| Same blanket PO, new release | Same parent reference can be legitimate | Identify the release separately |
| Different PO, identical lines | Repeat purchases can be intentional | Review only if other signals conflict |
| Same PO number, different customer | Numbers are not globally unique | Keep customer scope |
| Old PO reused next year | Historical match can be misleading | Apply documented account policy |
| Cancellation followed by reinstatement | Existing order state matters | Confirm intended state before acting |
Keep business identity readable by staff. An opaque fingerprint can help software compare records, but an owner needs to see the buyer, PO, release, revision and related ERP order. That context makes a held case resolvable without a technical investigation.
Business identity
Customer, purchase-order reference and relevant scope.
Document meaning
Compare lines, quantities and revisions.
Execution identity
Track the action so a retry does not create another order.
Conceptual guide by Looqus Editorial. Read the surrounding analysis for assumptions, exceptions and primary sources.
Check what the ERP actually enforces
An external-reference field is not necessarily a uniqueness control. Microsoft explicitly documents that Business Central does not check external document numbers for uniqueness or duplicates. That is a product-specific limitation worth verifying in your configured version, extensions and workflows. Microsoft external document numbers.
Conversely, a warning may not be a block. An older Oracle Order Management implementation manual describes a configurable duplicate purchase-order warning. It is historical, product-specific documentation, not evidence about current Oracle Fusion behavior. The lesson for implementation is to test the exact installed system rather than relying on a vendor name. Oracle Order Management implementation manual.
Inspect whether checks happen during interactive entry, API import, batch processing or all three. Determine whether cancelled, archived and completed orders remain searchable. Check whether customer scope, company scope and reference normalization are consistent. A process tested only through the user interface may behave differently through its integration endpoint.
Compare content without destroying business meaning
Use exact file hashes to recognize exact attachment repeats, but do not expect them to identify every resend. Re-saving a PDF or adding a signature changes the file without necessarily changing the order. Conversely, identical product lines can belong to a valid recurring order.
A semantic comparison should preserve ordered item, quantity, unit, requested date, ship-to location, price and customer reference. Show differences at field level. If the quantity moved from 20 to 30, the reviewer should see that change directly rather than an overall similarity score.
Normalization rules need customer-specific care. Removing leading zeros may make distinct references collide. Ignoring a suffix might remove a release number. Test normalization on known valid and invalid examples before enabling it. Store both the original reference and normalized comparison value so an owner can explain the result.
Do not silently merge competing instructions. A specialist should establish whether the later document supersedes the earlier one, supplements it or repeats it. Until then, the system can preserve the evidence and hold the action that would allocate stock or create a second shipment.
Treat amendments as changes to a known instruction
GS1 separates purchase orders, purchase-order change requests and purchase-order responses in its EANCOM message family. The purchase-order response specification also explains how amendments can refer back to the original purchase order. That supports explicit relationships between documents rather than treating every attachment as a new sale. GS1 purchase order response.
The practical question is whether the original order has progressed. A quantity increase before allocation may be straightforward. A decrease after picking or dispatch needs a different resolution. Do not let an amendment overwrite evidence of goods already shipped.
Represent the requested change, current fulfillment state, permitted action and approver. If the customer has sent inconsistent instructions, ask for clarification through the authorized account process. An AI-generated interpretation cannot replace commercial acceptance. Closure means the correct amended state is verified, not that an email has been classified as “revision.”
Fictional USD example. Monetary assumptions in this guide are illustrative US-dollar amounts, not quoted prices, measured results or exchange-rate conversions. The currency does not imply a US tax or legal setting.
Synthetic example · monthly operating comparison
Nine duplicates at USD 300 each. Review is 80 legitimate orders ×4minutes at USD 60/hour. Setup cost USD 7,000 is excluded from monthly difference.
Make technical retries safe and observable
Assign a stable operation identifier before sending the first create request, and retain it across retries. A fresh identifier on every attempt defeats the purpose. Where the ERP supports idempotency, use its documented contract and confirm how long identifiers remain valid and how different payloads under the same key are handled.
Where it does not, a local ledger alone cannot guarantee exactly one remote order. The first request may succeed while the local success record fails. Reconcile against the ERP using a stored correlation reference before deciding what to do next. If the destination cannot be reliably queried, hold an ambiguous write for investigation rather than issuing an unbounded repeat.
AWS's operational guidance recommends verifying idempotency before enabling retries and controlling retry behavior. The proposed distributor application should also bound retries, record attempts and route exhaustion to an owner. AWS retry controls.
Concurrency matters too. Two workers can both search, find no matching order and create one at the same moment. Test simultaneous intake, not just sequential resends. The chosen integration must establish an appropriate locking or uniqueness strategy around operation identity; its effectiveness depends on the destination and failure model.
Same instruction
Link the repeat receipt to the existing case.
Amendment
Review changes against the known order and authority.
Uncertain
Hold the action for an owner; do not silently discard.
Conceptual guide by Looqus Editorial. Read the surrounding analysis for assumptions, exceptions and primary sources.
A test matrix that catches expensive failures
| Test | Expected outcome | Evidence to retain |
|---|---|---|
| Exact attachment resent | One business instruction | Both messages linked to one record |
| Portal upload and email arrive together | One approved create operation | Concurrent attempt log and ERP identity |
| Create succeeds but response times out | Existing order found or ambiguity held | Correlation query and final decision |
| Same key arrives with changed quantity | Conflict held; no silent overwrite | Payload difference and owner approval |
| New blanket-order release arrives | Valid separate release proceeds | Release identity and parent reference |
| Duplicate found after partial dispatch | Shipment preserved; balance investigated | Fulfillment state and resolution |
| Destination unavailable for an hour | Bounded retry, visible queue | Attempt count and next owned action |
Run these with representative customer patterns and controlled test data. A clean happy-path demonstration does not prove duplicate prevention. Verify the resulting ERP orders and warehouse consequences, not only the automation logs. If the test creates two orders but the second is automatically cancelled, report that accurately; prevention and remediation are different outcomes.
Worked example: value after false holds and operating cost
Imagine a synthetic distributor with 4,000 orders monthly and twelve confirmed duplicate orders that would otherwise reach fulfillment. The assumed incremental cost per duplicate is USD 140 delivery and return freight, USD 60 handling, and USD 100 unrecovered loss or adjustment: USD 300 total. That produces USD 3,600 of avoidable monthly cost. The sale value is excluded because returned inventory and cancelled invoices do not make gross revenue an appropriate loss measure.
A pilot prevents nine of those twelve duplicates, avoiding USD 2,700 under these assumptions. It also holds 80 legitimate orders for review, requiring four minutes each. That is 320 minutes, or 5.33 hours. At USD 60 per hour, false-hold review consumes USD 320 of capacity value.
With USD 1,800 recurring operating cost, the modeled monthly difference is USD 2,700 minus USD 320 minus USD 1,800: USD 580. An USD 7,000 setup cost gives a simple payback of approximately 12.1 months. This is a scenario calculation, not a forecast or cash-flow guarantee; staffing capacity is not automatically cash expenditure.
If only six duplicates are prevented, the avoided cost becomes USD 1,800 and the monthly difference becomes negative USD 320. That sensitivity is the reason to measure confirmed duplicate losses and false holds before buying a broad automation programme. A large number of detected resends may represent little incremental value if staff already catch them quickly.
Measure the outcome without rewarding indiscriminate blocking
Report confirmed duplicates reaching fulfillment per thousand orders, along with the denominator and period. Track false holds, their resolution time and any delays they caused. Report duplicates detected before creation separately from those cancelled after creation, since they have different operational costs.
Monitor unknown write outcomes as a distinct queue. A record stuck in “processing” may be more dangerous than an explicit failure because staff can repeat the action manually. Make the last attempt, correlation identifier, destination check and owner visible.
Begin with observation and labeling. Then enable high-certainty holds for exact repeats in a limited customer group. Add amendment handling and destination retries only when those paths have been verified. Preserve an accountable release path for legitimate orders; duplicate prevention should not turn every recurring purchase into an administrative negotiation.
Where Looqus can help define a starting scope
This approach suits distributors whose orders arrive through several channels and whose duplicate costs are measurable. A lower-volume business with one disciplined entry point may get more value from a simple reference check and staff procedure. Complex blanket orders, poor customer identity and an ERP without reliable lookup require more investigation before automatic writes make sense.
Looqus can help connect incoming documents to the right customer instruction, investigate ambiguous resends and verify the resulting order state. The engagement should define which actions may proceed automatically and who authorizes amendments or releases held orders. Specialists own the exceptions through to a recorded resolution. AI does the work. We own the outcome.
Sources
- AWS: making retries safe with idempotent APIs.
- Microsoft: external document numbers.
- Oracle: Order Management implementation manual, historical release.
- GS1: purchase order response.
- AWS: control and limit retry calls.
AI does the work.We own the outcome.
Keep resends, amendments and system retries from becoming separate orders, with clear checks and an owner for resolving uncertain submissions before fulfilment.
- Agree the result
- Connect the work
- Own the follow-through