Skip to main content

Duplicate EDI Transactions — Causes, Identification, and Resolution

Why am I receiving duplicate orders with the same PO number but different Orderful transaction IDs?

A
Written by Ashwath Kirthyvasan
Updated over a month ago

Audience: EDI developers, B2B integration teams, supply chain analysts

When you receive multiple EDI transactions with the same business reference numbers but different Orderful transaction IDs, you're dealing with duplicate transactions. This commonly happens with 850 Purchase Orders, 204 Load Tenders, and 810 Invoices, and can create operational issues if duplicates flow into your ERP or downstream systems.

Orderful processes every transmission as a separate transaction and assigns unique transaction IDs. The platform does not automatically detect or block duplicates — this is intentional to ensure no legitimate business data is lost. Identification and deduplication logic belong in your integration layer.

What Causes Duplicate Transactions

  • Trading partner system retries — Connectivity failures or missing acknowledgments cause the partner's EDI system to retransmit the same file

  • AS2 retransmissions — Network issues during AS2 delivery trigger automatic retries that result in duplicate arrivals

  • Partner business practices — Some trading partners send revised orders as new 850s instead of proper 860 Change Orders, creating functional duplicates with the same PO number

  • Multiple communication channels — Having both a direct EDI connection and a VAN connection configured for the same partner can result in the same transaction arriving via both channels

How to Identify Duplicates in Orderful

Orderful does not automatically flag duplicate transactions. You can identify them manually:

Step 1 — Filter by business reference number

In Orderful, go to Transactions and filter by the business reference number (PO number, invoice number, etc.). Duplicate transactions will have all the exact same metadata, especially the same business and control numbers. They will appear as separate rows with different transaction IDs and Orderful creation dates.

Step 2 — Compare transaction content

Open each transaction and view the raw X12 payload via the Content tab. True duplicates will have identical data. Revisions will show differences in quantities, dates, line items, or purpose codes.

Step 3 — Check transmission timestamps

Duplicates from system retries typically arrive within minutes of each other. Business revisions usually arrive hours or days later and often carry a different transaction set purpose code.

How to Resolve Duplicates

Pending transactions — self-service deletion

If a duplicate transaction is still in Pending status on the sender side and has not yet been sent to the partner org, you can delete it directly in Orderful:

  1. Go to Transactions in Orderful

  2. Filter to find the duplicate transactions

  3. Select the transactions to remove

  4. Click Actions > Delete Transactions

Once a transaction has been sent to the partner org, self-service deletion is no longer available.

Already sent to the partner org — contact Orderful Support

If duplicates have already been sent to the partner org, contact [email protected]. Orderful Support can perform backend deletion. When contacting support, include:

  • Specific transaction IDs from Orderful for all duplicates to be removed

  • Business reference numbers (PO numbers, invoice numbers, etc.)

  • Trading partner name and transaction type (850, 810, 204, etc.)

  • Whether duplicates have already reached your downstream systems and are causing operational impact

Prevention: Handle Deduplication in Your Integration

Orderful does not provide automated duplicate detection. Deduplication logic should be implemented in your connector or integration layer using business reference fields — not Orderful's transaction_id, which is unique per transmission and will differ across duplicates of the same business document.

For JSON API integrations, deduplicate on:

  • 850: purchase_order_number + transaction_set_purpose_code

  • 810: invoice_number + invoice_date

  • 204: shipment_identification_number + transaction_set_purpose_code

  • 856: shipment_identification_number + bill_of_lading_number

For X12 integrations, deduplicate on:

  • Original control numbers

  • 850: BEG02 (Purchase Order Number) + BEG05 (Transaction Set Purpose Code)

  • 810: BIG02 (Invoice Number) + BIG01 (Invoice Date)

  • 204: B2A01 (Shipment Identification Number)

  • 856: BSN02 (Shipment Identification)

Recommended integration logic:

  • If a transaction with the same business reference already exists and the new transaction has a later timestamp, treat it as a revision

  • If a transaction with the same business reference already exists with the same timestamp, flag it for manual review

What to Send Orderful Support

When contacting support about duplicates, include:

  • Specific transaction IDs from Orderful for all suspected duplicates

  • Business reference numbers (PO numbers, invoice numbers, etc.) that are duplicated

  • Trading partner name sending the duplicates

  • Transaction type (850, 810, 204, etc.)

  • Timeline — when did the duplicates start appearing?

  • Your preferred resolution — delete specific transactions, configure duplicate detection rules, or investigate the root cause

  • Impact description — are these going to your ERP system and creating operational issues?

For deletion requests, provide the exact list of transaction IDs or business reference numbers to be removed.

Frequently Asked Questions

My trading partner says they only sent the order once — why am I seeing duplicates in Orderful?

This usually indicates a connectivity or retry issue on their side. Their system may have retransmitted due to network timeouts, AS2 delivery failures, or missing acknowledgments. Ask them to check their EDI transmission logs for multiple send attempts.

Should I use Orderful's transaction_id for deduplication in my system?

No. Orderful's transaction_id is unique per transmission — legitimate duplicates will have different transaction IDs but identical business references. Always deduplicate on business reference fields like PO number or invoice number.

My trading partner sends revised orders as new 850s instead of 860 Change Orders. How should I handle this?

Configure your integration to treat a later 850 with the same PO number as a revision rather than a duplicate. Use the transaction set purpose code (BEG05) and arrival timestamp together to distinguish intentional revisions from accidental duplicates.

Can Orderful automatically prevent duplicates from reaching my systems?

No. Orderful processes all transmissions to ensure no legitimate data is lost. Duplicate detection and filtering logic should be implemented in your integration layer.

I'm seeing the same transaction arriving every few minutes. What's causing this?

This typically indicates a delivery loop where the sending system isn't receiving acknowledgment of successful delivery and keeps retrying. Contact [email protected] immediately with the transaction ID — this needs to be investigated and stopped at the source.

Did this answer your question?