What is EDI testing?
EDI testing is the work of proving that an EDI document is correct before a real trading partner relies on it. A purchase order, ship notice or invoice has to pass several checks in a row. The file has to be built correctly. It has to follow the X12 standard. It has to contain what this partner requires. It has to arrive over the connection the partner uses. And the partner's system has to acknowledge it.
Testing is not the same as certification. Testing is what you do. Certification is the partner confirming, in writing, that your documents meet its program. Most mandates need both, and the partner controls the second one.
If you are new to the documents themselves, start with the X12 EDI guide and the guides for the 850 purchase order, 856 advance ship notice and 810 invoice.
The five types of EDI testing
| Layer | What it checks | A typical failure |
|---|---|---|
| 1. Envelope (syntax) | ISA, GS, ST and the closing segments are present, in order, with matching control numbers and counts | Segment count in SE01 does not match the real number of segments; ISA is not the fixed 106 characters |
| 2. Standard (schema) | Required segments and elements exist, data types and code values are valid for the transaction set | Missing required element, a date in the wrong format, a code that is not in the code list |
| 3. Partner rules | Everything the partner's vendor guide adds on top of the standard | Required REF qualifier missing, wrong unit of measure, item number that does not match the partner's catalog |
| 4. Connectivity | The document reaches the partner's mailbox over AS2, SFTP or an API and a receipt comes back | Wrong ISA ID or mailbox, certificate or credential problem, file dropped in the wrong folder |
| 5. Acknowledgement and business flow | A 997 or 999 returns, the order-to-cash loop closes, and the document means the same thing to both systems | 997 comes back "rejected"; invoice total does not match the purchase order |
Layers 1 and 2 you can check alone, today, with a validator. Layers 3 to 5 depend on what your partner publishes and on its test mailbox, which is why partner testing windows matter.
A 9-step EDI testing plan
- Get the requirements in writing. Ask the partner for its EDI specification or vendor guide: document list, version, delimiters, required segments, and any test-mailbox details. Our trading partner library lists published requirements for many retailers and payers.
- Confirm identifiers and envelope settings. Agree the ISA and GS sender and receiver IDs, qualifiers, delimiters and how control numbers are assigned.
- Build synthetic test data. One clean example per document. Never paste real customer, patient or production partner data into a public tool.
- Run syntax and standards checks. Use a validator on every document before anything leaves your system.
- Apply the partner's rules. Walk the vendor guide line by line against your sample. Most real rejections live here, not in the standard.
- Test the connection. Send to the partner's test mailbox (or a simulator) over the transport the partner uses, and confirm receipt.
- Close the acknowledgement loop. Confirm a 997 or 999 comes back and shows accepted. Read any rejection; do not retry blindly.
- Run negative and edge cases. See the scenarios below.
- Get written sign-off, then plan go-live. Agree the cut-over date with the partner, watch the first live documents closely, and keep your test evidence.
Test scenarios worth running
Start with the happy path for each document you need, then break things on purpose.
| Scenario | What to confirm |
|---|---|
| Inbound 850 purchase order | Parses cleanly, maps to an order in your system, partner IDs resolve |
| Outbound 856 ship notice | Hierarchy (shipment, order, pack, item) is complete and the identifiers match the partner's labels |
| Outbound 810 invoice | Line totals, tax and the invoice total reconcile to the purchase order |
| Acknowledgements | A 997 or 999 is generated or received for each interchange and the status is read, not ignored |
| Missing required element | The error names the segment and element, and you can fix it without guessing |
| Wrong qualifier or code value | Rejected at your side before it reaches the partner |
| Duplicate control number | Detected, not processed twice |
| Large batch | A realistic day of documents processes without timing out |
| Special characters | Names and addresses with delimiters or accents do not break the envelope |
Test your file with free tools
You can run layers 1 and 2, and a simulated acknowledgement, without an account:
- Check with Signal (EDI validator). Paste an EDI file or start from a sample (837, 835, 850, 856, 810, 999 or 277). It shows parser output, schema-aware issues and ASN readiness, lets you download a report, and simulates a payer or retailer acknowledgement. Sandbox only.
- EDI test lab. Runs a synthetic file through SignalEDI's production validators and a partner simulator. Use synthetic samples only: the public lab is anonymous, rate-limited and does not store your file. A simulator pass is not partner certification.
- Document-specific checkers for the 856 and 810.
- API playground if you only need to parse or validate and work in JSON.
Testing through the API: Lab, then Certification
If you build against the SignalEDI API, testing follows the same layers in separate lanes, each with its own key:
- Lab (
sk_lab_keys). SignalEDI validates your payload and mapping in your account without contacting a partner, billing a transport or creating normal lifecycle webhooks. Use it for steps 3 to 5. - Certification (
sk_cert_keys). The same request runs against the real partner route. When the partner returns its functional acknowledgement, SignalEDI sends a signeddocument.acknowledgement_received.v1webhook. Use it for steps 6 and 7. - Production (
sk_live_keys). Used only after the partner has approved and the connection is promoted.
A key can address only its own lane, so test traffic cannot reach production by accident. The developer quickstart walks through the first request, and the go-live checklist and 997/999 guide cover the last steps.
What testing cannot do
No tool, SignalEDI's included, can approve you with a trading partner. Retailers, payers and clearinghouses control their own enrollment, testing and production approval, and each runs to its own calendar. What you control is the quality of your side: clean mappings, validated documents, and evidence that you passed each layer. That is what shortens the partner's review.
For how to keep a regression suite of test files running over time, read EDI test environments and conformance. The EDI onboarding guide shows where testing fits in a full setup, and the trading partner library has partner-specific requirements to test against.
Start testing today
Open the EDI validator with a sample file, or start a free trial (30 days, no credit card) to test against your own partners in a workspace.