Onboarding a new supplier to EDI runs in six stages: intake, document mapping, connection, testing, go-live and support. Each stage ends with one question that must be a clear yes before the next one starts. Skip a gate and the problem shows up later as a rejected order, a bounced invoice or a missed shipment.
Who this is for: operations, IT and supply chain leads at distributors, wholesalers and suppliers who need to bring a new trading partner onto EDI. It is also for owners who just got an EDI requirement from a large customer and want to know what they are signing up for.
How we know: before he started FlowChainLabs, our founder, Alvin Chikaeze, ran supplier EDI onboarding as part of his project work at Southern Glazer's Wine & Spirits. That was his job there, not FlowChainLabs client work. The six stages below are the ones he took suppliers through. The gate questions are how we teach those stages today. The technical terms are standard across the EDI industry.
What does EDI supplier onboarding actually mean?
EDI stands for electronic data interchange. Two companies send business documents, like orders, ship notices and invoices, straight from one system to the other in a format both sides agreed on. No email, no PDF, no retyping.
Onboarding is everything between "we will trade with this supplier" and "orders flow every day and nobody has to watch each one." It is not a single setup. It is a set of agreements between two companies' systems: which documents, which version, which IDs, which connection, and who fixes what when a file fails.
Most onboarding delays come from one place. One side thought something was settled. The other side never agreed to it. The stages below exist to catch that early.
Which EDI terms should you know before you start?
| Term | What it means |
|---|---|
| EDI | Electronic data interchange. Business documents sent system to system in an agreed format. |
| Trading partner | Any company you exchange EDI documents with: a supplier, distributor, retailer or carrier. |
| X12 | The EDI standard most used in North America. Each document type has a three-digit number. |
| 850 | Purchase order. What the buyer wants, how many and at what price. |
| 855 | Purchase order acknowledgment. The supplier confirms or changes the order. |
| 856 | Advance ship notice, often called an ASN. What the supplier says is in the shipment. |
| 810 | Invoice. What the supplier is billing. |
| 997 | Functional acknowledgment. A receipt that says the file arrived and could be read. It does not mean the order was accepted. |
| Implementation guide | The partner's rulebook: which documents, which fields and what each field must look like. |
| Map | The rules that turn your system's data into the partner's format, and the partner's data into yours. |
| Sender and receiver IDs | The addresses each company uses so files reach the right system. |
| Go-live | The first day real documents flow between the two companies. |
What are the six stages, and what has to be true before each one ends?
Here is the full checklist on one page. Save it. Each row is a stage, and each stage has a gate question. If the answer is not a clear yes, the work stays in that stage.
| Stage | What happens | Gate question: must be a clear yes | Where an AI assistant helps | Where a person decides |
|---|---|---|---|---|
| 1. Intake | Collect the guide, contacts, documents, version, IDs, connection type and target date | Do both sides agree on the documents, version, IDs and date in one shared document? | Pulls requirements out of the partner's guide into a checklist | Which documents go live first, and the date |
| 2. Mapping | Match every required field to a source in your system, or to a rule | Does every required field have a source, a rule or a named answer? | Compares the guide to your field list and flags gaps | How to handle data your system does not hold |
| 3. Connection | Set up AS2, SFTP, VAN or API and exchange IDs and credentials | Has a test file gone both ways and been confirmed on each side? | Checks that IDs and settings match on both sides | Security approvals and who owns the credentials |
| 4. Testing | Send test documents, clean and messy, and compare results | Did every test case, messy ones included, match the expected result on both sides? | Drafts test cases from the guide and explains errors in plain words | Whether the results are good enough to go live |
| 5. Go-live | Switch to real documents and check the first ones closely | Did the first real documents match what both sides expected? | Compares early live documents against the expected result | When to call it live, and when to pause |
| 6. Support | Watch for failures and hand off to normal operations | Does everyone know who gets told, who fixes it and how fast? | Summarizes failures and drafts the fix note | Any change to maps, rules or partner terms |
Notice the last two columns. An AI assistant can do a lot of the reading, comparing and drafting. A person still makes every call that changes what the two companies agreed to.
What happens during intake?
Intake is where you collect everything before anyone builds anything. You need the partner's implementation guide, their EDI contact and a backup, the documents they expect, the X12 version they use, their sender and receiver IDs, how they want to connect and the date they are aiming for.
The goal of intake is one shared document both sides can point to. If the supplier thinks invoices start in month two and the distributor expects them on day one, you want to learn that now, not during testing.
A good intake ends with a short list: these documents, this version, these IDs, this connection, this target date, these contacts. Both sides confirm it.
What happens during document mapping?
Mapping is the translation work. Your system stores an order one way. The partner's guide says it must look another way. The map is the set of rules that turns one into the other, for every document going out and coming in.
Go field by field. For each required field in the partner's guide, find where that data lives in your system. Some fields map straight across. Some need a rule, like turning your item number into the partner's item number, or turning cases into single units. Some fields your system does not hold at all.
That last group is where onboarding slows down. Every field without a source needs a named answer: add the data, use a default the partner accepts, or ask the partner to drop the requirement. Write the answer down. Do not leave it for testing to discover.
How do you choose a connection: AS2, SFTP, VAN or API?
The connection is how the files move. Many partners tell you which one they require. When you have a choice, here is how the four common options compare.
| Connection | What it is | Choose it when | Watch out for |
|---|---|---|---|
| AS2 | A direct, encrypted connection over the internet. Each file gets a signed receipt back. | The partner requires it, or you trade directly with many large partners. | Certificates to exchange and renew, and a server that must stay up. |
| SFTP | A secure shared folder. One side drops files and the other picks them up. | The partner offers it and volume is modest. | No built-in delivery receipt, so someone has to watch the folders. |
| VAN | A value-added network. A third-party mailbox service that passes files between partners. | You trade with many partners and want one connection for all of them. | Fees that often grow with the number or size of documents. |
| API | A direct system-to-system connection, often in a newer format than X12. | The partner offers one and you want faster updates. | Not every partner offers it, and it may not cover every document. |
Whichever you use, the connection stage is not done when the settings are saved. It is done when a test file has gone both ways and each side has confirmed it arrived and could be read.
What should EDI testing cover before go-live?
Testing proves the maps and the connection work together on real-looking documents. The trap is testing only clean orders. Clean orders almost always work.
Test the messy cases your business actually sees:
- An order with an item the supplier does not carry.
- A partial shipment, where the ship notice covers fewer cases than the order.
- An invoice with a price that does not match the order.
- A unit of measure mismatch, like cases on the order and single units on the invoice.
- The same document sent twice.
- A file that fails, so you can see who gets told and how.
For each test, write the expected result before you send it. Then compare. A test counts only when both sides see the same result, not when the file simply goes through. Remember that a 997 only says the file was received and could be read. It does not say the order was accepted.
What happens at go-live and in the weeks after?
Go-live is the first day real documents flow. Treat the first real orders, ship notices and invoices as one more round of testing. Check each one against what both sides expected. Keep the people who built the maps close by.
Then comes support. The supplier is live, but the job is not finished until normal operations can run it. That means three things are clear: who gets told when a document fails, who fixes it, and how fast it needs to be fixed so an order or a payment does not slip. When those answers are written down and the early documents are clean, the supplier moves from onboarding to normal operations.
Where does an AI assistant help, and where does a person decide?
At Southern Glazer's, Alvin used a separate AI assistant for each onboarding stage. The assistants supported the people doing the work. They did not run the work on their own.
That split is the right shape for most teams. An assistant is good at the reading and comparing that eat up hours: pulling required fields out of a long implementation guide, checking a map against the spec, turning an error report into plain words, and comparing early live documents against what was expected.
A person stays in charge of anything that changes the agreement between the two companies. Which documents go live first. How to handle a field your system does not hold. Whether test results are good enough. When to call it live and when to pause. Those calls carry business risk, and they belong to someone with a name.
If you want your team to use AI this way inside your own process, that is what our team training covers.
What breaks most often in EDI supplier onboarding?
The same few problems show up again and again across the industry:
- ID mismatches. The sender or receiver ID, or its qualifier, does not match what the partner set up. Files get rejected before anyone reads them.
- Version mismatches. One side builds to one X12 version and the other side expects another.
- Missing required fields. The guide requires data your system does not hold, and nobody decided what to do about it during mapping.
- Unit of measure confusion. Cases on one document, single units on another, and the numbers stop matching.
- Treating a 997 as approval. The file arrived and was readable. That is all a 997 says.
- No owner for failures. A file fails at night and nobody is told until a payment is late.
Each of these is cheap to catch at its gate and expensive to catch after go-live.
Where should you start if a customer just asked you to get on EDI?
Start with the customer's implementation guide and one real order. Trace that order through your systems: where it lands, where the warehouse records what shipped and where the invoice gets made. That trace tells you what mapping and connection work is ahead.
FlowChainLabs builds and runs EDI connections for suppliers and distributors, inside the systems you already use. See how we approach it on our EDI modernization page, or read how we work across the business on our AI implementation page. If you have a partner deadline coming, schedule a strategy call and bring the onboarding packet.
