Electronic data interchange has an image problem. It sounds like an IT topic, it is described in numbers rather than words, and the people who understand it tend to explain it in a vocabulary borrowed from 1985. So it gets delegated, and then it quietly becomes the thing that decides whether a retail program makes money.
This guide is the version we would want a grower to read before signing a program: what the documents actually are, where the money leaks, and what to ask a software vendor about it.
What EDI actually is
Strip away the history and EDI is just a shared file format for business documents, plus an agreed way to deliver them. Instead of a purchase order arriving as a PDF attachment that someone retypes, it arrives as a structured file your system can read directly. Instead of you emailing an invoice, your system generates one in the format the retailer expects.
The reason it matters is not elegance. It is that large retailers process too many transactions to handle exceptions by hand, so they require the format — and they enforce it with deductions when you get it wrong.
The document numbers, in plain terms
Each document type has a number. You do not need all of them, and which ones you need depends on the program you are in rather than on your size:
- 850 — Purchase order. The retailer telling you what they want, where, and when.
- 855 — Purchase order acknowledgement. You confirming what you will actually ship, which matters when it is not everything they asked for.
- 856 — Advance ship notice, usually called an ASN. What is on the truck, often tied to pallet or rack labels so receiving can scan rather than count.
- 810 — Invoice. Your bill, in their format.
- 820 — Payment and remittance advice. What they paid, and which invoices they think they were paying.
- 812 — Credit and debit adjustments. Deductions. This is the one worth understanding properly.
- 997 — Functional acknowledgement. A receipt confirming a document arrived and parsed, which is the difference between "we sent it" and "they have it".
GrowerLive handles 850, 820 and 812 natively today — purchase orders inbound, remittance back, and adjustments — which is the set that carries pay-by-scan and vendor-managed programs. If a program you are entering requires something else, that is a normal conversation rather than a rebuild.
Where growers actually lose money
Almost never in the technology. The losses cluster in four places, and all four are operational.
Deductions nobody reconciles. An 812 arrives, it reduces a payment, and because it is a file rather than a phone call it goes unexamined. Over a season a percentage of those are wrong, and the ones you never look at are free money for somebody else. The fix is unglamorous: every adjustment has to land somewhere a person will see it, attached to the order it disputes.
Compliance chargebacks. Late ASN, wrong label, missing acknowledgement, quantity mismatch. Individually small, collectively a line item. These are the ones that come as a genuine surprise, because nothing was broken — the document simply arrived in the wrong shape or the wrong order.
Re-keying. If an 850 arrives and somebody types it into an order screen, you have paid for EDI and kept the error rate of manual entry. This is more common than vendors like to admit, and it usually means the EDI sits beside the operational system rather than inside it.
Invoicing the wrong number. On a pay-by-scan program you are billing for what sold, not what shipped. If invoicing runs off shipments because that is what the software can do, every invoice is wrong in the same direction and the reconciliation lands on somebody’s desk in a spreadsheet.
Native, or bolted on?
This is the architectural question, and it determines what your team’s week looks like.
In a bolt-on arrangement, translation happens outside your operational system and the files are handed over at the boundary. It works. It also means two vendors, two invoices, two support queues, and a gap in the middle where documents can sit unnoticed. When a retailer insists they sent a purchase order, you are asking someone else to check.
It is worth being precise about where the line actually falls, because this is easy to get wrong in a vendor conversation. Almost every platform uses a translation specialist somewhere in the chain — that is a sensible division of labour, and the firms who do it are very good at it. The question is not whether one exists. It is where the documents land and who owns the problem.
Ask it that way and the answer is concrete. Do documents arrive inside the system that already holds your orders and inventory, through an integration your software vendor builds and maintains? Is there one support queue when something breaks? Or are files dropped at a boundary you are responsible for bridging, with the two sides pointing at each other on the bad Friday?
When EDI is native, documents are parsed inbound and generated outbound by the system that already holds your orders and inventory. An 850 becomes an order without anyone typing. An 812 attaches to the order it disputes. And crucially, there is one place to look when something is wrong.
That last point is the one growers underrate until the first bad Friday. GrowerLive keeps full audit trails on EDI documents and logs every API call in a searchable transaction log, so "they say they sent it and we cannot find it" is settled by looking rather than by guessing. Correction handling exists for the times a partner sends something that needs fixing — because they do.
What to ask before you commit
- Which documents are handled natively, and which need a third party?
- If there is a translation partner in the chain, who maintains that integration — you, or me?
- When an 850 arrives, does it become an order without anyone retyping it?
- Where does an 812 end up, and will a human reliably see it?
- Can I search inbound and outbound documents myself, or do I raise a ticket?
- If a partner sends something malformed, what happens — does it fail loudly, or vanish quietly?
- For pay-by-scan: does invoicing run from scans or from shipments?
- Who does the onboarding and testing with the retailer, and how long does it take?
That last one is worth pressing on. Getting certified with a large retail partner is a process with their timetable, not yours, and a vendor who has done it before is worth a great deal more than one who is willing to learn on your program.
The honest summary
EDI is not hard. It is unforgiving, which is different. The format is documented, the documents are finite, and the technology has been stable for decades — but the penalties for small mistakes are automatic and the money leaves quietly.
So treat it as an operational capability rather than an integration project. The question is not whether a system can exchange the files. It is whether the right person sees the right document in time to do something about it.