EDI testing confirms three things before you trade live documents with a partner: the connection works, the documents are built the way the partner's guide requires, and your own systems create the right records from what comes in. Retailers test the first two during certification. The third is your job, and it is the part that causes most post-launch problems because the retailer never sees it.

This guide walks through the testing phases in order, the scenarios to cover for each document, what a major retailer's certification looks like, and how to test integrations that use APIs between your ERP and the EDI layer.

The four layers of EDI testing

Keep the layers separate when something fails. An MDN proves the file arrived. A 997 proves it was structurally valid. Neither proves the partner could use it, and neither checks your ERP.

The EDI testing process, phase by phase

1. Prepare

Collect the partner's implementation guide and testing instructions, confirm the X12 version for each document, and build representative sample files before you contact the partner's EDI team. If your master data is not clean, fix it first; most test failures trace back to item numbers, ship-to codes, or prices that do not match. The EDI ERP integration readiness checklist covers what to have in place.

2. Test connectivity

Exchange AS2 certificates or SFTP credentials and send a test transmission each way. Walmart's supplier testing guide, for example, requires AS2 testing to be complete before EDI data testing begins. Our AS2 guide and ISA ID setup guide cover the settings that usually break here: certificates, MDN type, and sender and receiver IDs.

3. Unit test each map

Before anything goes to the partner, run each map against your sample files and check the output segment by segment against the guide. This is where you catch missing mandatory elements, wrong qualifiers, and date formats.

4. Partner document testing

Exchange test documents with the partner. Typically the partner sends test 850s, you return 997s, then you send 855s, 856s, and 810s built from those orders. Partners review the results and send back corrections. Walmart's guide says data testing usually lasts no more than two weeks and that suppliers who run past six weeks may be removed from testing, so respond to feedback quickly.

5. End-to-end and scenario testing

Run full order-to-invoice cycles through your actual systems, including the exceptions in the next section. This is the business-outcome layer, and it is where you confirm your ERP records match.

6. Pilot and cutover

Move to production with one partner or a small volume first, monitor every 997 and 824, and expand once you have several clean cycles. Write the go-live criteria down before you start, such as "five consecutive clean order cycles for each document."

Test scenarios to cover

Partners usually test the standard case. Your business runs on the exceptions, so test them yourself.

Purchase orders (850) and changes (860)

• Single-store order and a multi-store or cross-dock order shipped to one DC

• An item number or UPC your item master does not recognize

• A price on the PO that differs from your price list

• A ship-to location that is new or inactive

• A PO change that adds, cancels, or changes quantity on a line. See 855 vs 860.

• A duplicate PO number

Acknowledgments (855)

• Accept all lines, accept with changes, backorder a line, and reject a line

Ship notices (856)

• Single-carton and multi-pallet shipments, with SSCCs matching the printed GS1-128 labels

• A partial shipment, with the remaining quantity on a later ASN

• Mixed cartons containing several items

• Lot numbers and expiration dates, if the partner requires them

• The carrier SCAC and bill of lading number from the routing instructions. Our ASN accuracy guide covers common mistakes.

Invoices (810)

• An invoice matching the PO line by line

• An invoice for a partial shipment

• Allowances, charges, and tariff surcharges. See our guide to 810 changes for tariff charges.

Inventory (846) and warehouse documents (940, 945)

• Zero quantity, a full feed versus changes only, and multiple locations. See the 846 guide.

• A 940 that ships complete, ships short, and is cancelled before pick, with the matching 945 for each

Failures

• A rejected 997 and an 824 rejection: does your team get alerted, and can they fix and resend?

• A transmission that never gets acknowledged: does anything notice?

Walmart's guide asks for a 997 within 24 hours of receiving a document. Test that your system sends acknowledgments automatically, and that someone reviews the inbound 997s partners send back.

Testing API-based integrations

Many integrations now use APIs between the ERP and the EDI layer, with the EDI layer turning JSON into X12 for the partner. That adds a few checks:

• Contract tests: confirm each API request and response matches the documented fields and types, including optional fields left empty.

• Error handling: send malformed payloads and confirm each one returns a clear error that someone is alerted to.

• Retries and duplicates: resend the same order and confirm it is not created twice.

• Rate limits and timeouts: test the volume you expect at peak, such as a holiday week.

• Round trip: confirm the X12 document the partner receives contains exactly what the API sent.

For how the two connect, see EDI and API integration. Surpass also publishes a developer API for teams integrating directly.

Automating EDI tests

Manual testing gets you to go-live. Automated regression tests keep you there, because partners change their guides and someone eventually edits a map. A practical setup keeps a library of known-good input files for each partner and document, runs them through the maps after every change, and compares the output to a stored expected result. Any difference gets reviewed before the change goes to production.

How long EDI testing takes

Connectivity is often done in a day or two once both sides have credentials. Document testing with a single retailer commonly runs one to three weeks, depending on how quickly each side turns around feedback and whether the partner reviews submissions in a queue. Scenario testing in your own systems runs in parallel. The full project timeline is in the EDI ERP integration guide.

Frequently asked questions

What is EDI testing?

EDI testing verifies that documents can be exchanged with a trading partner correctly before live transactions begin. It covers connectivity, X12 syntax, the partner's specific rules, and the records your own systems create.

What is EDI certification?

Certification is the partner's formal approval after you pass its test cases. Retailers such as Walmart require it before they will send live purchase orders.

What should an EDI testing strategy include?

Separate tests for connectivity, syntax, partner rules, and business outcomes; a scenario list for every document type; written pass criteria; a pilot phase; and automated regression tests for future map changes.

What is the difference between a 997 and an 824?

A 997 confirms a document arrived and was structurally valid X12. An 824 reports whether the partner's application accepted the content, such as whether an ASN's items and quantities matched what it expected.

How long does EDI testing take?

Connectivity usually takes a few days. Document testing with one retailer commonly takes one to three weeks. Walmart's guide sets a six-week maximum for testing its basic documents.

Can EDI testing be automated?

Yes. Most teams automate regression testing by running stored sample files through each map after changes and comparing the output to an approved result.

Do I need to test if my EDI provider has a prebuilt connection?

Yes, though less. A prebuilt connection covers the partner side, but you still need to confirm your ERP data produces correct documents and that inbound documents create the right records.

Get through certification faster

Surpass runs partner testing and certification as part of every onboarding and keeps regression tests on every map we manage. See the retailers we already support or talk to our team.