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 small mistakes in it start costing money without anyone noticing.
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. On some pay-by-scan programs the retailer also uses the 850 to report what sold in each store.
- 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.
- 852 — Product activity data. A store-by-store report of what sold and what is on hand. Some retailers send pay-by-scan sales this way instead of on the 850.
- 997 — Functional acknowledgement. A receipt confirming a document arrived and parsed, which is the difference between "we sent it" and "they have it".
GrowerLive takes in 850, 820 and 812 today: purchase orders, payment and remittance advice, and adjustments. On the pay-by-scan programs our growers run, store sales arrive on the 850, so that is where the scan data you get paid on comes from. If a program you are entering sends an 852 or requires something else, that is a normal conversation rather than a rebuild.
Where the paperwork costs you money
Shrink, freight and merchandising labor decide whether a program pays. The paperwork can still take a slice on top of that, and those losses tend to land in four places.
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 get paid 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.
Who translates, and where it lands
Almost every platform uses a translation specialist somewhere in the chain to receive documents from retailers and translate them, and GrowerLive does too. That is a sensible division of labor, 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 documents land in 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 a full audit trail of how each EDI document came in 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 does the system take in, and who receives and translates them?
- 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.