EDI Trading Partner Onboarding: Test Plan and Go-Live Checklist

The new customer's EDI coordinator sends a forty-page implementation guide, one sample purchase order and a go-live date six weeks away. Your team maps the 850, sends back a test 855 and 856, gets a clean 997, and declares the partner ready. Three weeks after go-live the customer's receiving dock is unloading trucks with no usable ship notice, accounts payable is holding invoices, and nobody can say which field caused it.

Onboarding fails in the gap between "the file parsed" and "the business process works". A test plan built from your own awkward orders, with envelope checks, acknowledgment rules and priced defects, closes that gap before production. The result is a partner that goes live on a planned night, with a fallback, and a scorecard that shows within days whether the connection is healthy.

• What this guide covers: the partner guide and identifiers, sample files, three test cycles, acknowledgment reading, what each field error costs in the warehouse and in tax, cutover and the first ninety days.
• What you can reuse: an annotated test interchange with its 997, a worked defect cost in USD and INR, an incident trace from a cutover night and a go-live checklist.

Collect the partner's implementation guide before mapping anything

Start from the partner's implementation guide, not from the X12 standard. The standard says what a segment may contain; the guide says which segments this partner sends, which values it accepts and which elements it treats as mandatory.

Before mapping, gather one set of artefacts and agree who owns each. Choosing the partner is a separate decision; if you are still comparing 3PLs, our fulfilment partner evaluation runs a peak-day operating test. This article starts after the contract is signed, when the job is to connect the chosen partner's systems to yours without disrupting orders.

Envelope identifiers and control numbers that break first in testing

Most first-week test failures are envelope errors, not business errors. Agree the identifiers in writing and test the envelope with an empty or minimal transaction before you spend time on detailed maps.

A published retail guide gives a representative set of envelope rules. ISA12 carries 00401 for version 4010 and 00501 for 5010. ISA13, the interchange control number, is nine digits and must match IEA02. ISA14 is 0 for no acknowledgment and 1 to request one. ISA15 is T for test and P for production. GS06 must match GE02, ST02 must match SE02, and SE01 counts every segment from ST to SE inclusive.

Test interchange (abbreviated 856 with one order and one item; values illustrative)
ISA*00*          *00*          *ZZ*SUPPLIERID     *ZZ*PARTNERID      *261110*0915*U*00401*000000341*1*T*>~
GS*SH*SUPPLIERID*PARTNERID*20261110*0915*341*X*004010~
ST*856*0001~
BSN*00*ASN778120*20261110*0915~
HL*1**S~
TD1*CTN25*12****G*186*LB~
REF*BM*BOL4471902~
HL*2*1*O~
PRF*PO4500918832~
HL*3*2*I~
LIN**UP*012345678905~
SN1**12*EA~
CTT*3~
SE*12*0001~
GE*1*341~
IEA*1*000000341~

Partner's 997 in reply
ISA*00*          *00*          *ZZ*PARTNERID      *ZZ*SUPPLIERID     *261110*0917*U*00401*000005120*0*T*>~
GS*FA*PARTNERID*SUPPLIERID*20261110*0917*5120*X*004010~
ST*997*0001~
AK1*SH*341~
AK2*856*0001~
AK5*A~
AK9*A*1*1*1~
SE*6*0001~
GE*1*5120~
IEA*1*000005120~

Checks:  ISA13 = IEA02 (000000341)   GS06 = GE02 (341)   ST02 = SE02 (0001)
         SE01 = 12 segments, ST to SE   ISA15 = T in both directions
         AK1 points to group 341, AK2 to set 0001, AK9 = A (accepted)

EDI trading partner onboarding tests the X12 envelope first: a partner implementation guide typically requires ISA13 as nine digits matching IEA02, GS06 matching GE02, ST02 matching SE02 and ISA15 set to T, and every test interchange should return a 997 inside the response window written into that guide.

• Padded identifiers: ISA06 and ISA08 are fixed at fifteen characters. A trailing space trimmed by a mapping tool is a common cause of an envelope rejection.
• Control number ranges: keep separate ranges for test and production, and never reuse a number inside the partner's duplicate-check window.
• Separators: confirm the element, sub-element and segment terminators, because a product description containing an asterisk can break a file that used it as a separator.

Sample files built from last quarter's awkward orders

Test with real orders that caused trouble, not with the one clean sample in the guide. A map that handles a single-line order perfectly can still fail on the partial shipment that happens every day.

Pull at least twenty orders from the last quarter's history for each inbound transaction and choose them for their difficulty. Anonymise customer names if needed, keep the item codes and quantities, and record the expected output for each file before you run it. The list below is a starting set for a supplier exchanging orders, ship notices and invoices with a retail or distribution customer.

• Multi-line and multi-store orders: one PO with many lines and several ship-to locations, which exercises loops and the store cross-reference.
• Partial and split shipments: one order fulfilled across two trucks and two ship notices, with the invoice quantities following what actually shipped.
• Changes and cancellations: a line cancelled after acknowledgment and a quantity changed after picking started.
• Unit-of-measure conversion: ordered in cases, shipped and invoiced in eaches, with a pack size the item master must supply.
• Unknown or retired item codes: a GTIN not in your cross-reference, which must route to an exception queue rather than silently drop.
• Duplicate control numbers: the same interchange sent twice, to prove the translator rejects or flags it.
• Price and allowance mismatch: an invoice price that differs from the order price, to check how the partner's accounts payable responds.

Three test cycles with exit criteria: syntax, business rules, volume

Run testing as three cycles, each with a written exit criterion that both partners accept. Moving to the next cycle before the previous one is clean simply carries errors forward, where they cost more to find.

The first cycle proves that files parse and envelopes balance. The second proves that the business process works end to end: an order becomes a pick, a pick becomes a ship notice, a ship notice matches the truck, an invoice matches the receipt. The third proves throughput and timing at a realistic peak. Record elapsed days per cycle, because a partner that takes a week to return each 997 will be slow in production too.

• Cycle one, syntax: every sample file returns a 997 or 999 with the functional group accepted, envelopes balance, and no identifier or separator issues remain. Exit when two consecutive full runs are clean.
• Cycle two, business rules: each sample's expected business result is met, including quantities, units, store numbers, carrier and bill-of-lading references and invoice totals. Exit when every case passes and both process owners sign.
• Cycle three, volume and timing: a normal peak day's files are sent in one window. Exit when all acknowledgments return within the agreed time and no file waits in a queue beyond its service level.

Reading TA1, 997 and 999 responses during the test window

An acknowledgment tells you the file was received and whether its syntax passed; it does not tell you the business accepted the data. Read each one down to the transaction set and treat a partial acceptance as a failure.

A TA1 reports on the interchange envelope only. A 997 reports the syntax result for each transaction set and each functional group, and X12 describes the 999 as adding relational analysis against an implementation guide. In a 997, AK1 identifies the functional group, AK2 each transaction set, AK3 and AK4 the failing segment and element, AK5 the status of each set, and AK9 the status of the whole group.

EDI acknowledgment review during partner testing reads each X12 997 down to AK5 and AK9: A means accepted, R rejected, and P a partially accepted functional group in which some transaction sets failed; a test cycle should exit only when 100% of groups return A.

• AK9 of P: some sets in the group passed and others failed. The failing sets are not processed by the partner, so treat the cycle as failed.
• AK3 and AK4 detail: the segment position, the element position and the bad value. Keep these with the test case so the map fix can be traced.
• No acknowledgment at all: often an identifier or routing problem, or a file that reached the wrong environment. Escalate after the agreed window rather than resending blindly, which can create duplicates.
• Application-level responses: some partners also return business acknowledgments, such as an 824 application advice. Agree in advance which ones will come and what each code means.

Field errors priced: receiving, freight audit and GST invoices

Each field that a map gets wrong lands somewhere physical or financial. Pricing the likely defects before go-live justifies the extra test cycle that prevents them, and the comparison is rarely close.

In the US example, an illustrative supplier went live with a ship-notice map that put the wrong purchase-order reference in a share of ASNs. In the Indian example, an illustrative 3PL billed a shipper through an automated invoice feed, and a weekend batch failed IRN generation because the map sent an incorrect field the IRP rejected. Rates and contract terms are assumptions; replace them with your own.

The Indian case has a hard deadline as well as a cost. Under the GSTN advisory of 5 November 2024, from 1 April 2025 a taxpayer with annual aggregate turnover of ₹10 crore or more cannot report an e-invoice, credit note or debit note to the IRP more than 30 days after its date. E-invoicing itself applies above ₹5 crore of aggregate turnover from 1 August 2023 under Notification No. 10/2023-Central Tax.

Invoice feeds between an Indian 3PL and a shipper must produce an IRN from the Invoice Registration Portal before the invoice counts under CGST Rule 48(4) and 48(5); taxpayers with aggregate turnover of ₹10 crore or more lose the ability to report it 30 days after the invoice date.

For the ship-notice side, the structure of the 856 hierarchy and how it ties to warehouse 940 and 945 messages is covered in our supply chain EDI integration architecture. Where a partner offers an API instead of EDI for some flows, our comparison of EDI and API schema mapping and error handling sets out how to run both in one onboarding.

Mapping tools and AI assistants: drafts versus analyst sign-off

Envelope generation, control numbering, environment switching and tax-validity checks run as fixed rules. Tools that read guides, propose maps or explain errors save hours, but an analyst approves every map change before it moves to production.

Cutover night trace: production ASNs sent with ISA15 still on T

The riskiest settings at cutover are the ones that passed every test. The trace below, from an illustrative supplier going live with a retail distribution customer, shows how a single unchanged flag silently stopped ship notices.

1. Friday 21:00, cutover window opens: the partner switches its profile to production. Your team moves the production endpoint into the translator profile but leaves the usage indicator at T.
2. Saturday 06:40, first production 856: interchange 000000351 for ASN778431 leaves with ISA15 set to T. The partner's production gateway does not process test-flagged interchanges, and no 997 returns.
3. Saturday 06:40 to Monday 05:00: 37 further ship notices follow the same path. The translator shows "sent", so the operations dashboard stays green because it tracks transmission, not acknowledgment.
4. Monday 06:30, partner DC dock: four trucks arrive with no matching ASN. The partner receives by hand and opens compliance cases against the affected shipments.
5. Corrected cutover runbook: the first production file is checked by a second person for ISA15 set to P, an alert fires if no 997 returns within two hours, and the dashboard counts acknowledged files rather than sent files.

Cutover plan, rollback path and the first ninety days of scoring

Go live on a planned, low-volume window with a named fallback channel, then score the partner weekly for ninety days. A connection that is not measured after go-live drifts back into manual workarounds within a quarter.

Agree the scorecard before cutover so neither side is surprised. Keep it to a handful of measures drawn from translator logs, warehouse receipts and accounts payable, and share it with the partner weekly. Where the partner is a dropship vendor sending you ship notices and invoices, the matching logic in our dropship ASN and invoice reconciliation guide supplies the match-rate measures.

• Acknowledgment timeliness: share of interchanges acknowledged within the agreed window, target at least 99%.
• Rejection rate: transaction sets returned with AK5 of R, target under 0.5% after week four.
• ASN before arrival: share of trucks whose ship notice was received and accepted before the truck reached the dock.
• Invoice match rate: invoices matching order and receipt within tolerance on first pass.
• IRN timeliness for Indian invoices: invoices with an IRN generated well inside the 30-day reporting limit where it applies.

Hold a short review at day thirty, sixty and ninety, and close the onboarding only when every scorecard measure has met its target for four consecutive weeks. More integration and message-standard guides are in the logistics and supply chain library. If you are planning a partner onboarding programme and want a test plan or cutover runbook reviewed, send us the scope and we will respond with a proposal.