EDI 850, 855, and 856 vs Email PO Workflows: What Data You Actually Get
🎧 Listen to this article (17 min)
Most procurement teams evaluating EDI alternatives start with the wrong question. They ask whether email based automation can replace EDI. The better question is what data each method actually puts into your ERP, and whether that data is complete enough to run planning against.
EDI transaction sets are precise. An 855 either arrives or it does not, and when it arrives the fields are typed and positional. Email is messy by comparison. But precision is not the same as coverage, and coverage is where most mid market manufacturers get hurt. If 70 percent of your supplier base will never trade an 855 with you, the precision of the 30 percent that do is not the number that matters.
This breaks down what the three core purchase order transaction sets carry, what the email equivalent of each one looks like in practice, and where the real data gaps show up.
The three transaction sets that matter for purchase orders
EDI covers hundreds of document types. For PO workflows in manufacturing and distribution, three do nearly all the work.
850 Purchase Order. This is the outbound document. Your ERP generates it, your EDI translator maps it, and it lands in the supplier's order entry system. It carries header level data such as PO number, ship to, bill to, terms, and requested delivery date, plus line level data including part number, quantity, unit price, and line level dates. The 850 is the easy one. It is outbound, you control the format, and nothing about it depends on supplier behavior.
855 Purchase Order Acknowledgment. This is where the value lives and where most implementations fall apart. The 855 is the supplier confirming, changing, or rejecting your order. Line level acknowledgment codes tell you whether each line was accepted as entered, accepted with date change, accepted with quantity change, backordered, or rejected. A well formed 855 gives you a confirmed ship date per line and a reason code when that date differs from what you asked for.
856 Advance Ship Notice. Sent when the shipment leaves the supplier. It carries pack structure, quantities shipped per line, carrier, tracking reference, and estimated arrival. Receiving teams use it to pre stage dock work and to validate against the PO at receipt.
Together these three give you a closed loop. You send a commitment request, you get a commitment back, and you get a departure confirmation. In theory your ERP always knows where every line stands.
What breaks in practice
The loop only closes for suppliers who are actually transacting all three documents with you. In most mid market supplier bases that is a small minority.
The common pattern looks like this. Your top 15 to 25 suppliers by spend are EDI enabled, usually because they are large enough to have an EDI department and because they mandated it rather than you. Those suppliers send clean 855s and 856s. The remaining few hundred suppliers, which collectively cover a large share of your line count and most of your expedite pain, send nothing structured at all. They reply to a PO email with a sentence. Sometimes they attach a PDF order confirmation. Sometimes they do not reply until a buyer chases them twice.
So your ERP has excellent data on the suppliers least likely to surprise you and almost no data on the ones most likely to. That inversion is the core problem, and no amount of EDI tuning fixes it, because the constraint is supplier willingness rather than your technical capability.
There is a second failure mode that catches teams who believe they are fully covered. A supplier is EDI enabled for the 850 and 855 but not the 856, or they send an 855 at order entry and then never send a change acknowledgment when the date moves three weeks later. The initial acknowledgment was accurate when it was sent. It has been stale ever since, and nothing in the ERP flags that. Supplier OTIF tracking suffers directly from this, because the promise date you measure against is the one that was never updated.
The email equivalent of each transaction set
Email based automation does not replicate EDI documents. It extracts the same fields from unstructured supplier replies and writes them to the same ERP tables.
Replacing the 850. Straightforward. The PO goes out as a PDF attached to an email, which is how most suppliers prefer to receive it anyway. No supplier onboarding required, no mapping, no trading partner agreement. This is already how most mid market manufacturers send POs to their long tail.
Replacing the 855. This is the real work. The supplier replies in free text or attaches a confirmation PDF. Automated parsing reads the reply, matches it to the open PO and the specific lines, extracts the confirmed ship date, quantity, and unit price, and compares each against the ordered values. A line that comes back with a different date is a date change exception. A line that comes back with a different price is a price variance exception. A line that is not mentioned at all is an unacknowledged line, which is itself a status worth tracking.
The important difference from EDI is that this works on the second and third reply too. When a supplier emails six weeks later to say a line slipped, that message gets parsed exactly like the first acknowledgment and the ERP date updates again. EDI implementations often treat acknowledgment as a one time event at order entry. Email traffic is continuous, so parsing it continuously produces a more current picture than a single 855 does.
Replacing the 856. Partial. Email shipping notifications carry carrier and tracking information often enough to be useful, but they rarely carry pack structure or carton level detail. If your receiving process depends on scanning license plate labels against an ASN, email will not replace that. If your receiving process is a person checking a packing slip against a PO line, which describes most mid market operations, the email derived ship confirmation covers what you need.
According to Gartner, 50% of purchase order lines undergo changes after issuance, making real-time supplier visibility a procurement priority. That statistic is the argument for continuous parsing over point in time acknowledgment. Half your lines will move, and the method that catches the second and third movement is worth more than the method that captures the first one precisely.
Data completeness, field by field
A useful way to evaluate the two approaches is to list the fields planning actually consumes and ask whether each method populates them across your whole supplier base rather than a subset.
Confirmed ship date per line. EDI gives it cleanly for enabled suppliers. Email parsing gives it for everyone who replies, which in practice is a far larger share of the base. Both miss suppliers who never respond at all, which is a supplier management problem rather than a data capture problem.
Date change history. EDI 855 change acknowledgments carry it if the supplier sends them, and many do not. Email parsing builds the history naturally because every message is a new data point and the system keeps the chain. This is the field that separates teams who can quantify supplier reliability from teams who cannot.
Quantity confirmation and partial ship splits. Both methods handle this. EDI is cleaner for complex splits across multiple shipment dates. Email handles the common case of a single split fine and gets ambiguous on multi line multi date splits.
Price variance at acknowledgment. EDI carries it in typed fields. Email parsing extracts it from confirmation PDFs reliably and from free text replies less reliably, since suppliers often omit price entirely when confirming. Treat an absent price as unconfirmed rather than as agreement.
Reason codes. EDI has standardized codes. Email has supplier prose, which is richer in content and worse in structure. A reply saying the delay is a raw material shortage at their mill tells a buyer more than a numeric code does, but it needs classification to be queryable. Exception classification is the step that makes this usable rather than just readable.
Aberdeen Group research shows that automated PO tracking reduces operational costs by up to 30% for mid-market manufacturers. The cost reduction is not primarily in the capture method. It is in removing the buyer hours spent chasing, retyping, and reconciling across the suppliers that structured integration never reached.
Where each approach actually fits
This is not an argument that EDI is obsolete. For high volume repetitive trade with a partner who already runs EDI, the 850 and 855 pair is efficient and reliable. If you ship to large retailers or buy from large distributors who mandate it, you will have EDI regardless.
The decision that matters is what you do about everything EDI does not cover. The usual answers are to keep chasing manually, to try to onboard more suppliers onto EDI or a portal, or to automate against the channel suppliers already use.
Manual chasing does not scale and produces no data. Onboarding campaigns have a long history of low completion rates, because the supplier bears the cost and gets little back. Parsing the existing email channel requires nothing from the supplier, which is why coverage tends to be high immediately rather than after a multi quarter rollout. We cover the onboarding economics in more depth in our breakdown of what to do when suppliers will not connect.
The practical architecture for most mid market manufacturers is both. Keep EDI where it exists and works. Run email parsing across the full supplier base including the EDI enabled ones, because EDI suppliers still send ad hoc emails when something changes between formal documents. The parsed email catches what falls between the transaction sets.
What this requires from your ERP
Whether your procurement team runs on SAP, Oracle NetSuite, Microsoft Dynamics 365, Epicor, or Infor, the integration requirement is similar. You need to read open PO lines, write confirmed dates and quantities back to those lines, and store a change history that the native schema usually does not provide.
That last part is the one that surprises people. Most ERP PO line tables hold a single promise date field. Writing a new date overwrites the old one. If you want to answer how many times a line moved and how much notice you got each time, you need a layer that keeps that history outside the single field. This is the same structural gap that makes native ERP modules weaker than they look, which we examine in our comparison of ERP agnostic automation against built in ERP modules.
For teams running Microsoft Dynamics 365, whether Business Central, Finance and Supply Chain, or Navision, Leverage AI integrates directly with your existing ERP environment to automate supplier PO confirmations, flag exceptions in real time, and surface OTIF data without custom development or ERP modification. The Dynamics 365 specific workflow is documented separately.
A Deloitte supply chain study found that 70% of supply chain disruptions originate before materials leave the supplier's facility. That is the window both EDI and email parsing are trying to illuminate. The method matters less than whether the window is covered for the suppliers who actually disrupt you.
Validation is the step teams skip
Parsed data going straight into the ERP without validation creates a different problem than having no data. A misread date that overwrites a good one is worse than a blank field, because planning will trust it.
The rule we apply is that high confidence extractions matching an open line on PO number and part number write back automatically, and anything ambiguous queues for buyer review with the source email attached. Buyers approve or correct in seconds rather than reading and retyping. Over a few weeks the confidence thresholds tune themselves against real supplier reply patterns. More detail on this sits in our write up on validating parsed supplier data before ERP writeback.
EDI has an equivalent discipline that most teams do have in place, which is trading partner testing before go live. The email equivalent is a supervised period where extractions are reviewed before they are trusted. Skipping it is the most common reason these projects produce bad data early and lose internal credibility.
How to evaluate this for your own supplier base
Pull three numbers before deciding anything.
First, the percentage of open PO lines currently covered by an EDI 855 from the supplier. Not the percentage of spend, the percentage of lines. Spend concentrates in large suppliers and will overstate your coverage significantly.
Second, the percentage of those 855 enabled lines where the confirmed date was updated at least once after initial acknowledgment. If that number is near zero, your 855 coverage is capturing order entry only and your date data is as stale as the email suppliers.
Third, the number of buyer hours per week spent on follow up email and retyping. That is the cost side of the business case and it is usually larger than anyone estimates before measuring it. Our PO tracking ROI model walks through how to build that number properly, and the platform overview covers what the automated path replaces.
According to McKinsey, companies with mature supply chain visibility capabilities outperform peers by 15-20% on OTIF metrics. Maturity in that research is about coverage and currency of data rather than the sophistication of the integration protocol.
Frequently Asked Questions
Can email based PO automation fully replace EDI?
For the acknowledgment and ship confirmation loop in most mid market environments, yes. For environments requiring carton level ASN data with license plate scanning at receipt, or where a trading partner mandates EDI, no. The common outcome is both running in parallel, with EDI covering the enabled minority and email parsing covering everyone including suppliers who send ad hoc updates between formal documents.
What is the difference between an 855 and a parsed email confirmation?
An 855 is a structured document with typed fields and standardized acknowledgment codes. A parsed email confirmation extracts the same core fields, confirmed date, quantity, and price per line, from unstructured supplier text or an attached PDF. The 855 is cleaner per document. Parsed email covers far more suppliers and captures subsequent changes that one time acknowledgments miss.
How accurate is automated parsing of supplier emails?
Accuracy depends on reply format and on whether validation gates writeback. Structured confirmation PDFs parse at high rates. Free text replies are lower and should route to buyer review when confidence is below threshold. The correct benchmark is not parsing accuracy in isolation but how much buyer time is removed while ERP data quality holds or improves.
Do suppliers need to do anything differently?
No, which is the central advantage. They reply to PO emails the way they already do. There is no portal login, no EDI mapping, and no onboarding project. This is why coverage tends to reach most of the supplier base quickly rather than climbing slowly through an onboarding funnel.
Which ERPs does this work with?
The approach is ERP agnostic. It reads open PO lines and writes confirmed dates and quantities back through supported integration paths for SAP, Oracle NetSuite, Microsoft Dynamics 365, Epicor, and Infor among others. The change history layer sits outside the ERP schema because most PO line tables hold only a single current promise date.
What should we measure to know it is working?
Track acknowledgment coverage as a percentage of open lines, post acknowledgment date change rate, variance between confirmed and actual ship dates, and notification lead time when a date moves. That last metric, how much warning you get before a date slips, is the clearest signal of whether visibility actually improved.
