EDI Testing and Certification Acceptance Criteria for New Trading Partners

A new trading partner may accept your test connection but still reject a purchase order, shipment notice or invoice once business data starts moving. You need acceptance criteria that distinguish successful delivery from usable documents and written authorization for production. The same discipline makes a VAN switch low risk: Nexus VAN uses dual-VAN reconciliation during migration, keeping the old and new routes side by side while documents are accounted for before the old route is retired.

What certification must prove before you accept production risk

Electronic data interchange, or EDI, is the structured exchange of business documents between organizations. For a new trading partner, testing checks whether those documents move and behave as intended. Certification is the partner's approval process for putting the agreed document exchange into production. The partner's published EDI implementation guide, and any companion instructions it identifies, set the specific requirements.

There are several distinct kinds of success. A connection can deliver a file to the receiving endpoint. A parser can accept its structure. The receiving application can understand its item, location and order information. Finally, the business can act on it. An EDI coordinator should record evidence for each applicable level rather than treating a green delivery status as a complete pass.

For leadership, this distinction matters because a technically successful but unusable document can delay fulfillment or invoicing. It also matters during a provider change. If an existing partner is moved to a new VAN, the production decision should depend on matched documents and acknowledgments, not an assumption that a working connection means the entire workflow works.

Avoid rework by agreeing on the partner's requirements first

Start with the current version of the trading partner's implementation guide. Ask which transaction sets are in scope, which direction each document travels and what constitutes approval. An ANSI X12 transaction set is a numbered document type. For example, an 850 is a purchase order, an 855 is a purchase order acknowledgment, an 856 is an advance ship notice and an 810 is an invoice. That sequence is common enough to be a useful testing example, but your partner may require different documents or additional steps.

Build one partner profile before creating test cases. It should record:

• The current implementation guide and applicable version for each document.
• Sender and receiver identifiers, which tell the network and receiving system who exchanged the document.
• The required connection method and any partner-specified security or certificate information.
• Documents to send and receive, along with required business scenarios.
• Acknowledgment types, expected response windows and any separate business response.
• Partner testing contact, evidence submission method and production approval owner.
• Any timing rules for acknowledgments, shipment notices or invoices stated in the guide.

Check the guide again when a requirement seems familiar. A prior retailer's version, codes or timing rules are not a substitute for this partner's instructions. If the guide leaves an important requirement unclear, get a decision from the partner before marking the related test as passed. This avoids spending time repairing a map that was built against the wrong assumption.

Connection choices should follow the relationship, not a blanket rule. Nexus VAN supports AS2, SFTP and REST API and has interconnects to VANs globally. The acceptance test still needs to use the method and identifiers the partner has approved. A change in transport may also require a separate partner test, even when the EDI document itself stays the same.

Turn each test into a pass or fail decision with retained evidence

We recommend writing every acceptance criterion in four parts: the condition, expected result, evidence and approver. That format gives an EDI coordinator a practical test and gives a CIO or IT director a clear reason to authorize or delay production. It also prevents a verbal statement such as "the file looked fine" from becoming the only record of certification.

Test area	Acceptance criterion	Evidence and decision owner
Connection and routing	A test document travels through the approved connection and reaches the intended partner destination.	Retain the transaction status and partner confirmation. EDI and partner contacts confirm the route.
Identifiers and version	Sender and receiver IDs, document type and version match the current partner guide.	Retain the test document and validation result. The EDI owner checks against the guide.
Structure and syntax	The partner's required document structure passes applicable validation, including control information used to identify and pair messages.	Retain the validation result and acknowledgment. The EDI owner resolves rejections.
Business data	Applicable item, quantity, date, location, price and reference information agrees with the source business event and partner rules.	Retain source and outbound records with a comparison. The business owner confirms meaning.
Acknowledgments	The required response arrives and can be tied to the originating document; rejection receives a defined follow-up.	Retain the response, status and relevant control numbers. The EDI owner verifies the match.
End-to-end processing	The receiving business process produces the expected result or downstream document for each required case.	Retain application or partner confirmation. The business owner approves the outcome.
Production approval	All required cases have passed or have an explicitly accepted disposition, and the partner authorizes production.	Retain written approval and the final case record. The partner and internal owner sign off.

Use this as a framework, then adjust it to the guide. Some partners require additional tests for labels, shipments or application responses. Others prescribe their own test files or certification portal. A criterion only helps when the expected result reflects that partner's actual requirements.

Test the workflow that will affect orders, shipments and invoices

First, establish that a normal document moves correctly

Send a representative document through the approved test route. Check the intended destination, the document version and the identifiers. Compare the business values in the source record with what the receiver sees. If the partner returns an acknowledgment, match it to the original document before moving to the next case. This establishes a baseline, but it is not the end of certification.

For example, imagine a supplier testing an 850 purchase order received from a retailer. The supplier confirms the order enters the intended business process with the expected items, quantities and delivery location. If the partner requires an 855 purchase order acknowledgment, the supplier tests that response against the order and the partner's guide. If the relationship also requires an 856 advance ship notice and 810 invoice, those documents need their own tests. The specific response documents and rules remain partner-dependent.

Next, test variations that change the business result

A single clean order rarely covers the situations that create disputes after launch. Choose cases based on actual operations and the partner's required scenarios. Examples include an order with multiple lines, a partial shipment, a changed order or an invoice that must be matched to the original order. If the partner permits cancellations or split shipments, test the corresponding process and response.

For each case, compare the original business event, the document sent, the acknowledgment and the receiving application result. If an amount or location changes between systems, determine whether the problem is source data, translation, routing or the receiving business rule. Record the correction and rerun the affected case. A changed map can affect previously passing cases, so repeat those tests when the correction touches shared logic. Our guide to EDI mapping regression tests explains how to organize that check.

Then, prove the rejection path works

Agree with the partner on appropriate negative tests before sending deliberately invalid files. A rejection test could check how an invalid code, missing required information or duplicate document is reported, if the guide calls for that case. The acceptance criterion is not merely that something fails. It is that the failure can be identified, assigned to an owner, corrected and retested without confusion over which original document was involved.

Keep acknowledgment types separate. A transport receipt, where applicable, addresses delivery at the connection level. A 997 addresses the receiver's syntax check. A partner may use a different acknowledgment or a separate business response under its guide. Even when the syntax response is positive, check whether the business application accepted and processed the transaction. This distinction is central to managing EDI acknowledgments and application exceptions.

Finally, check timing against the partner's rules

Some exchanges depend on a document arriving before a business event, such as a shipment notice reaching the partner in time for receiving. Record the guide's timing rule for each applicable document and test whether the full workflow can meet it. Avoid applying one partner's deadline to another. If the expected response is late, determine whether the delay occurred before transmission, during delivery or inside a business process.

Control numbers, the identifiers used to trace EDI messages and acknowledgments, help you follow a test across those stages. Retain them alongside the test case and partner feedback. Nexus VAN's management portal provides visibility into transaction status, acknowledgments and control numbers, which supports a shared review of what happened when a case does not pass.

Keep evidence so production approval is a controlled decision

Certification should end with an evidence record that another person can follow. For each case, record the partner, guide version, document type, test scenario, expected result, actual result, relevant control numbers and final status. Link any failure to its correction and retest. Then retain the partner's authorization to move that relationship into production.

Separate three decisions that are easy to blur together. The technical owner confirms the route, structure and acknowledgment handling. The business owner confirms that orders, shipments and invoices have the intended meaning and processing result. The trading partner confirms its own certification requirements have been met. If any required decision is pending, keep the case open rather than calling the whole relationship certified.

Before production, verify that the intended production identifiers, connection details and document versions match the partner's instructions. Assign someone to check the first applicable production exchanges against the approved tests and follow up on a missing or rejected response. That is a team procedure, not a substitute for partner approval.

For an executive, the sign-off record should make the residual decision clear: which documents have passed, which exceptions remain and who approved proceeding. For the EDI coordinator, it should make the next action equally clear if a response arrives that does not match the expected result.

Reduce switching risk and challenge legacy VAN costs with the same evidence

Testing a new partner and changing an existing partner's VAN route are different decisions, but they rely on similar proof. The practical worry in a VAN migration is straightforward: a document could be routed incorrectly, missed during the handoff, acknowledged on an unexpected path or delivered twice. A test connection alone will not expose every discrepancy. Compare documents and responses at the partner level before deciding to retire a route.

During migration, Nexus VAN uses dual-VAN reconciliation: the existing VAN and Nexus VAN run side by side so documents can be accounted for before the old route is retired. Your team can use transaction status, acknowledgments and control numbers to investigate a mismatch while the old route remains available. Plan how the two routes will be compared without sending duplicate live business transactions to a partner unless that partner has approved the test. See our detailed dual-VAN reconciliation guide for the reconciliation decisions to make before cutover.

The cost review belongs in that same decision. Many legacy VANs use billing practices that can inflate costs, including rounding each document up in size, minimum charges per document, per-partner fees and archive-access fees. Nexus VAN prices by the kilo-character, and we never round up the size of your documents, so you are billed accurately for the exact data you transmit, and nothing more. Compare how your present bill treats document size and partner growth before you assume the existing contract is the safer choice.

The Spanx case study illustrates the commercial side of that decision: Spanx moved away from a legacy VAN with hidden fees, high per-message rates, per-partner charges and archive-access fees toward predictable, transparent pricing. The case does not replace your own certification tests. It shows why it is worth evaluating cost at the same time as route acceptance criteria.

Best practices for repeatable trading partner certification

• Write acceptance criteria before building maps. If the guide requires a business scenario, give that scenario an expected result and approver before testing starts.
• Keep technical and business passes separate. A successful transmission, positive syntax acknowledgment and correct order processing answer different questions.
• Test both directions where applicable. An inbound order and outbound acknowledgment can use different routing, maps and business processes.
• Retest after changes. When a rejected case leads to a mapping or configuration change, repeat affected cases rather than relying solely on the fixed example.
• Preserve the link between a document and its response. Record control numbers, statuses and partner feedback so a reviewer can reconstruct an exception.
• Get the production decision in writing. Keep the partner's approval with the relevant test results and assign internal responsibility for the first production exchanges.
• Apply the same scrutiny to a VAN change. Reconcile the old and new routes before retirement, and compare the billing terms while you have a clear inventory of partner traffic.

A useful final check is simple: can the business owner point to the approved scenario, and can the EDI owner point to the exact document and response that proved it? If either answer is no, the team still has a testing or evidence gap to close.

---

Frequently Asked Questions

---