On this page
Quick Overview
Distinguish retransmissions, revisions, and separate releases before an emailed or EDI purchase order becomes duplicate demand.
An order arriving twice can look like healthy demand until the warehouse ships both copies. For a distributor receiving purchase orders through email, customer portals, and EDI, the difficult question is whether two messages describe one commitment or two separate releases. Matching the purchase-order number alone will not answer it.
A useful intake check compares business identity, line content, and revision history before a second sales order reaches release. The following procedure is a proposed operating method. Adapt its fields and hold permissions to your customer agreements and order system.
Decide what makes an order the same order
Start with the customer account, buying entity, purchase-order number, delivery location, and release identifier. Keep these fields separate. A customer may reuse a blanket purchase-order number for multiple authorized releases. Two branches may also use the same numbering sequence. Treating either situation as a duplicate could stop legitimate shipments.
Document how leading zeros, spaces, and punctuation are compared. Preserve the customer's original value alongside any normalized search value. Removing a hyphen for searching is different from rewriting the authoritative purchase-order reference. If the customer's format is meaningful, ask the account owner to define it before configuring a rule.
Compare the message with the existing commitment
Use a line comparison to examine customer item code, internal SKU, ordering unit, quantity, ship-to, requested delivery date, and price reference. The comparison should flag differences, not decide whether they are acceptable. Where an interface supplies a message identifier or revision indicator, retain it with the received timestamp and channel.
A line fingerprint can help locate likely matches, but it should not be the only evidence. A customer can resend the same quantities with a new delivery instruction. Conversely, two legitimate releases can contain identical products. A fingerprint is a search aid; the release reference and customer's intention establish the business meaning.
| Evidence | Why retain it | Question for review |
|---|---|---|
| Original message and channel | Shows what actually arrived | Was this a retry or separate request? |
| Customer and release identifiers | Separates similar order numbers | Which commitment does it belong to? |
| Line comparison | Exposes changed quantities or units | Is this a revision? |
| Existing sales-order status | Shows downstream activity | Has picking or shipment started? |
| Confirmation and owner | Supports the disposition | Who approved the next action? |
Work through an email and EDI collision
Consider an illustrative purchase order, PO 814, received through EDI at 09:10. An email copy arrives at 09:25 with the same customer, ship-to, and quantities, but its requested delivery date is one day later. The existing sales order is waiting for release.
The assistant records both messages against one review case and marks the date difference. The authorized order owner asks whether the email replaces the EDI instruction. Until that answer is recorded, the second message remains pending rather than becoming another releasable order. If the customer confirms a revision, the owner approves the date change on the existing order and retains the superseded instruction.
If the email instead names a distinct release that was omitted from the attachment, the team needs that release identity before treating it as new demand. This small distinction prevents a similarity check from becoming an unauthorized cancellation rule. The example's timing is illustrative; each business should define its own review coverage and cutoff.
Keep the hold narrower than the investigation
Use a documented intake or release hold that your system supports. Avoid deleting the incoming record merely because a match seems likely. Deletion can remove evidence needed to explain why an order was delayed, changed, or rejected. Record the hold reason, affected lines, owner, and next review time.
Check the existing order's physical status before proposing a correction. If picking has started, an order administrator should not assume a screen change will stop the warehouse. Route the request through the approved warehouse communication path and capture acknowledgment. If goods have shipped, the investigation now includes shipment and customer-service decisions that belong to authorized personnel.
Give each result a precise meaning
Use outcomes such as confirmed retransmission, approved revision, separate release, and unresolved identity. A confirmed retransmission should reference the surviving sales order. An approved revision should identify the changed fields and approval. A separate release should have its own business identifier. An unresolved case should stay visible with the next person responsible.
Do not mark the entire customer account as suspect because one message was repeated. The control concerns a specific transaction. Likewise, do not treat a transport acknowledgment as proof that the commercial instruction was accepted; check what that acknowledgment means in your own integration agreement.
The existing order management SOP can supply the broader intake and escalation structure. Keep this duplicate review as a specific gate within that process rather than building a competing order register.
Test the rule before relying on it
Build a small test set containing an exact resend, a changed quantity, a changed delivery date, two releases under one blanket order, and the same number from different customer accounts. Have an order owner classify the cases independently. Investigate disagreements before using the rule to interrupt live orders.
Measure confirmed duplicates separately from false matches and unresolved cases. A high number of holds does not by itself demonstrate a useful control. Review whether the held orders were actually duplicates and whether legitimate releases were delayed. Keep the comparison logic version with the review results so a later change can be evaluated against the same cases.
Product identity also matters: GS1's GTIN guidance (opens in a new tab) describes identification of trade items. Customer purchase-order identity still needs its own account and release context.
Frequently asked questions
Should an exact copy always be rejected automatically?
Only if an approved business rule establishes that the message is a retransmission and the permitted system action is clear. Identical line content can occur on separate releases. Where release identity is missing, route the case for confirmation rather than guessing.
What closes a duplicate-intake case?
The original messages, comparison, approved classification, surviving order reference, and downstream acknowledgment should agree. If a warehouse or customer notification is still outstanding, record that dependency instead of calling the case complete.
For order workflow support, bring examples from each intake channel and the decisions your order owner retains. Request a consultation to define a bounded review queue and the evidence required before release.