EDI 855: Purchase Order Acknowledgment
EDI 855 is the Electronic Data Interchange transaction set for a purchase order acknowledgment. Defined in the ANSI ASC X12 standard as transaction set 855 (sometimes written EDI855 or 855 EDI), it is the structured electronic message a seller sends back to a buyer in response to an inbound EDI 850 purchase order — also called a PO acknowledgment or PO acknowledgement. In plain terms, the EDI 855 definition is this: it is how a supplier says "we received your PO, and here is what we can actually do with it" — line by line, in a format the buyer's system can read without a human touching it.
- EDI 855 is the ANSI X12 Purchase Order Acknowledgment transaction — a structured electronic message a seller sends back to a buyer to confirm, reject, or propose changes to an incoming EDI 850 purchase order
- The 855 EDI document type tells the buyer three things per line: whether each item is accepted, backordered, rejected, or changed, and the price and delivery date the seller commits to
- Line-item status is carried in the ACK segment using codes like IA (accepted), IB (backordered), IC (accepted with changes), IR (rejected), and IQ (partially accepted)
- An EDI 855 is a functional business response, not a technical receipt — that is the job of the EDI 997 Functional Acknowledgment, which only confirms the 850 file arrived and parsed
- EDI 895 is a separate transaction (Delivery/Return Acknowledgment or Adjustment) sometimes confused with the 855; the 855 acknowledges a purchase order, not a delivery
- Most mid-market suppliers still send order acknowledgments as PDF or email rather than true EDI 855, which is why AI extraction that reads any acknowledgment format and posts it to the ERP has become the practical alternative to full EDI onboarding
When a buyer transmits an EDI 850 (the purchase order), the buyer's system has committed to an order but has no confirmation the seller can fulfill it. The 855 EDI document closes that gap. It tells the buyer, for every line on the PO, whether the item is accepted as ordered, accepted with a changed price or quantity, backordered, or rejected outright — and it states the price and delivery date the seller is committing to. This is what distinguishes a purchase order acknowledgment from a simple "got it" reply: an order acknowledgement is a commercial commitment, not a courtesy.
The EDI 855 is one half of a matched pair in B2B ordering. The buyer sends the 850, the seller returns the 855, and the two documents are reconciled against each other. Any discrepancy — a price the seller changed, a quantity the seller cut, a line the seller rejected — surfaces immediately, before goods ship and before an invoice is cut. That early visibility is the entire point of exchanging an EDI order acknowledgement rather than waiting for a shipment or an invoice to reveal that the order was not filled as placed.
In practice, the term covers both the strict technical artifact — the ANSI X12 855 transaction with its defined segments and codes — and the broader business object it represents. Many suppliers, especially in the mid-market, never send a true EDI 855 at all. They send a PDF order confirmation or an email that performs exactly the same function: acknowledging the order and stating what will be delivered, at what price, and when. Whether the acknowledgment arrives as EDI, PDF, or email, the buyer's operational need is identical — reconcile it against the original PO and get it into the ERP.
What Is EDI 855?
EDI 855 is the purchase order acknowledgment transaction in the ANSI ASC X12 standard. To answer the question directly — what is an EDI 855 — it is the seller-to-buyer response that confirms whether and how a purchase order will be fulfilled. It flows in the opposite direction from the EDI 850: the buyer sends the 850 PO downstream to the seller, and the seller sends the 855 acknowledgment back upstream to the buyer.
The reason the 855 exists is that a purchase order is a request, not a guarantee. When a buyer's procurement or replenishment system generates an EDI purchase order (an EDI PO) and transmits it, the buyer is assuming the seller has stock, honors the expected price, and can hit the requested date. The seller must then acknowledge order lines it can actually fill. Often one or more of those assumptions is wrong. The item is on backorder. The contract price changed. The requested delivery date is not feasible. Without an acknowledgment, the buyer only discovers the problem when the shipment arrives short, or when the invoice does not match the PO. The EDI 855 moves that discovery to the front of the process.
A proper order acknowledgment answers four questions for every line on the order:
Is the line accepted?
The seller confirms each ordered item as accepted, accepted with changes, backordered, or rejected. This is the core of any order acknowledgement — the buyer needs a definitive yes, no, or yes-but per line, not a blanket confirmation of the whole order.
At what price?
The seller states the unit price it will actually invoice. If it differs from the price on the 850, the buyer's system flags the variance immediately rather than at invoice-matching time weeks later.
In what quantity?
The seller confirms the quantity it can ship. A cut quantity (partial acceptance) is one of the most common reasons an acknowledgment order differs from the PO, and it drives whether the buyer needs to source the balance elsewhere.
By when?
The seller commits to a delivery or ship date. This becomes the buyer's planning input — for inbound scheduling, for downstream production, for promising dates to the buyer's own customers.
Because it answers these questions in a machine-readable structure, the 855 lets the buyer auto-reconcile the acknowledgment against the original order. Lines that come back accepted at the ordered price and quantity clear automatically. Lines that come back changed, short, or rejected route to a buyer for a decision. That automatic split — clean lines through, exceptions to a human — is what makes EDI order acknowledgement worth the setup cost for high-volume trading relationships.
The 855 EDI Document Type: Segments and Structure
The 855 EDI document type follows the ANSI X12 envelope and segment structure shared by all X12 transactions. Understanding the EDI 855 specification means understanding a handful of key segments and, above all, the line-item status codes that carry the actual business meaning.
An EDI 855 document is wrapped in the standard X12 interchange and functional group envelopes (ISA/IEA and GS/GE), and the transaction itself runs from an ST segment to an SE segment. Between them, the segments that matter most for a purchase order acknowledgment are these.
BAK — Beginning Segment for Purchase Order Acknowledgment
The BAK segment opens the transaction and sets the context for the whole acknowledgment. It carries the acknowledgment type (for example, whether the order is acknowledged with detail and change, acknowledged without detail, or rejected), the buyer's original PO number so the 855 can be matched to the 850, and the PO date. The BAK is where the buyer's system first learns the overall disposition of the order.
PO1 — Baseline Item Data
The PO1 segment repeats for every line and carries the item identifiers, quantity, unit of measure, and price the seller is acknowledging. It mirrors the line structure of the 850 so the two documents line up field for field.
ACK — Line Item Acknowledgment
The ACK segment is the heart of the 855. It sits with each line and carries the line-item status code — the single most important data point in the whole transaction, because it tells the buyer what the seller is actually doing with that line. Common ACK status codes include:
- IA — Item Accepted (the line is confirmed exactly as ordered)
- IB — Item Backordered (accepted, but not currently in stock; will ship later)
- IC — Item Accepted, Changes Made (accepted, but with a changed price, quantity, or date)
- IR — Item Rejected (the seller will not fulfill this line)
- IQ — Item Accepted, Quantity Changed / partial acceptance (a reduced quantity is confirmed)
- IP — Item Accepted, Price Changed (confirmed, but at a different price)
- ID — Item Deleted
- IS — Item Accepted, Schedule Date Changed
These codes are why the 855 is more useful than a plain confirmation email. A buyer's system can read the ACK code on each line and act automatically: IA lines close, IB lines update the expected date, IC and IQ lines route to a buyer to accept or re-source, IR lines trigger sourcing the item elsewhere.
DTM — Date/Time Reference
DTM segments carry the committed dates — the requested delivery date the seller is confirming, or the revised ship date on a backordered or rescheduled line.
REF, N1, CTT
Supporting segments carry reference numbers (REF), party identification such as ship-from location (N1 loop), and the transaction totals (CTT — the line-item count used as an integrity check).
The EDI 855 specification is published per trading relationship: while the base X12 standard defines the segments and codes, each buyer issues its own implementation guideline (often called an 855 spec or mapping guide) stating which segments are mandatory, which codes it accepts, and how it wants qualifiers populated. Two 855 documents that both conform to X12 can still look different because the buyers behind them require different subsets of the standard. This partner-by-partner variability is one of the practical costs of EDI, and it stands in contrast to the more flexible integration patterns covered in EDI vs API.
EDI 855 Example: A Line-by-Line Walk-Through
An EDI 855 example makes the structure concrete. Suppose a distributor sends a supplier an EDI 850 for three lines: 100 units of part A, 50 units of part B, and 25 units of part C. The supplier processes the order and returns an 855. Here is what an edi 855 purchase order acknowledgment communicates, line by line.
Header (BAK)
The BAK segment references the buyer's original PO number and signals that this is an acknowledgment with detail and change — meaning the buyer should expect line-level status, including changes, in the body. This tells the buyer's system to reconcile line by line rather than treating the order as blanket-confirmed.
Line 1 — part A, 100 units
The PO1 segment restates 100 units of part A at the ordered price. The ACK segment carries status code IA — item accepted. The buyer's system matches this line to the 850, sees no variance, and clears it automatically. Nothing needs a human.
Line 2 — part B, 50 units
The PO1 segment shows part B, but the ACK segment carries IB — item backordered — and an associated DTM segment gives a revised ship date three weeks out. The seller has accepted the line but cannot ship now. The buyer's system updates the expected receipt date and, if the delay matters, routes the line to a buyer who decides whether to wait or source the 50 units elsewhere.
Line 3 — part C, 25 units
The ACK segment carries IC — item accepted, changes made — and the PO1 price field shows a unit price higher than the buyer ordered. The seller is confirming the line but at a changed price. Because the 855 surfaces this now, the buyer resolves the price discrepancy before goods ship and long before invoice matching, avoiding a downstream invoice dispute of the kind that clogs three-way matching.
The outcome
From one 855, the buyer's system has auto-cleared one line, rescheduled a second, and flagged a third for a pricing decision — with no one reading a document. That is the value of a structured order acknowledgement: the routine confirmations disappear into automation and only the genuine exceptions reach a person. Compare this to receiving the same three answers buried in an email or a PDF, where a buyer has to read the confirmation, compare it to the PO by eye, and re-key the changes.
This example also shows why the acknowledgment is a commitment document. Once the supplier sends the 855 confirming part A at the ordered price and part C at the changed price, those become the terms the buyer holds the supplier to at delivery and at invoice.
EDI 855 vs EDI 997 vs EDI 895 vs Order Confirmation Emails
The 855 is easy to confuse with other acknowledgment documents. The distinctions matter because they operate at different layers — technical versus business — and because a buyer who treats a 997 as an order acknowledgment will believe an order is confirmed when it is not.
EDI 855 vs EDI 997
The EDI 997 is the Functional Acknowledgment. It confirms only that an EDI file arrived and was syntactically valid — that the buyer's 850 was received and could be parsed. It says nothing about whether the seller will fill the order. The EDI 855, by contrast, is a business response: it confirms what the seller will actually do with the order, line by line. A trading relationship typically uses both: the seller's system returns a 997 within minutes to confirm the 850 transmission succeeded, then returns an 855 once the order has been processed and the seller knows what it can commit to. Reading a 997 as if it were an 855 is a classic mistake — the file arrived, but the order may still be rejected.
EDI 855 vs EDI 895
The EDI 895 is a different transaction entirely — Delivery/Return Acknowledgment or Adjustment, used in specific industry contexts (notably grocery and warehouse replenishment) to acknowledge a delivery or return and communicate adjustments. It acknowledges movement of goods, not the acceptance of a purchase order. If you are confirming a PO, the transaction is the 855; the 895 sits later in the flow and in a narrower set of trading relationships. The similar numbering is the only thing the two share.
EDI 855 vs the order confirmation email
Outside true EDI, most suppliers acknowledge orders with a PDF order confirmation or a plain email — a sales order acknowledgement that states the same facts an 855 would: lines accepted, prices, quantities, and dates. Functionally, an emailed order acknowledgement and an EDI 855 do the same job. The difference is machine-readability. The 855 is structured and reconciles automatically; the email or PDF is unstructured and, without automation, requires a person to read it, compare it to the PO, and update the system by hand. This is the reality for the large majority of mid-market B2B trade, where full EDI onboarding across every trading partner is never completed. It is also why AI extraction of acknowledgment documents has become the practical bridge — it gives an emailed order ack the same straight-through, auto-reconciled treatment that an 855 gets, without requiring the partner to implement EDI.
Order Acknowledgments Beyond EDI: Why Most Are PDFs and Emails
The 855 is the ideal, but it is not the norm. Across most B2B trade, the purchase order acknowledgment does not arrive as EDI at all. It arrives as a PDF attached to an email, or as free text in the email body, or occasionally as a portal message — an order acknowledgement sample that looks like a formatted confirmation document rather than a structured transaction. Understanding why matters, because it defines where the real operational cost sits.
True EDI 855 exchange requires both parties to implement EDI, agree on a specification, map the transaction, and maintain the connection. Large retailers and OEMs mandate it and have the scale to justify it. The mid-market — the majority of suppliers and buyers by count — does not. Onboarding every trading partner to EDI is a multi-year program that most organizations never finish, so most order acknowledgments continue to flow as documents a human has to read.
That creates a specific, expensive gap on both sides of the trade.
On the buying side, a procurement or replenishment team sends out purchase orders and gets back a stream of PDF and email order acks in dozens of different layouts — one per supplier. Someone has to open each one, find the confirmed price, quantity, and date, compare them to the original PO, and update the system when the supplier changed something. At volume this is slow, and it is exactly the kind of comparison work where a tired human misses a changed price or a cut quantity — the same errors that later surface as invoice disputes in accounts payable automation.
On the selling side, a supplier that receives orders as emails and PDFs (rather than 850s) has the mirror-image problem: it must read each incoming order, enter it into the ERP, and generate an acknowledgment back to the customer. A true 855 would let the ERP emit the acknowledgment automatically; without EDI, the acknowledgment is a manual or semi-manual document the sales-support team produces. This is the same intake bottleneck described in order entry — unstructured documents arriving faster than a team can key them.
The result is that the acknowledgment step, which the 855 was designed to automate, remains largely manual for most of the market. An order acknowledgement sample in the wild is far more likely to be a supplier's branded PDF than a clean ACK-segment transaction. The practical question for most operations teams is therefore not "how do we implement EDI 855" but "how do we get 855-grade automation from acknowledgments that arrive as PDFs and emails" — which is precisely the problem AI extraction solves.
Your operations, on autopilot.
GeneralMind handles procure-to-pay and order-to-cash end-to-end — 98% decision accuracy, full auditability, zero manual steps. See it live in 30 minutes.
Book a demoHow GeneralMind Automates Order Acknowledgments
Most suppliers and buyers will never run true EDI 855 across every trading partner — the onboarding cost is too high and the mid-market long tail is too large. Our solution closes that gap by giving PDF and email order acknowledgments the same straight-through, auto-reconciled treatment an EDI 855 gets, without requiring anyone to implement EDI.
Read any acknowledgment format — Our solution ingests order acknowledgments however they arrive: EDI 855, PDF attachments, order-confirmation emails, free-text in the email body, or portal exports. The AI extracts every field an 855 would carry — the referenced PO number, each line's accepted price, confirmed quantity, backorder status, and committed delivery date — regardless of the supplier's layout and without per-supplier templates. Where a true 855 gives you ACK status codes, our solution derives the same line-level disposition (accepted, changed, backordered, rejected) from the document's actual content.
Auto-reconcile against the original order — Extracted acknowledgment data is matched line by line against the original purchase order in your ERP. Lines confirmed at the ordered price and quantity clear automatically. Lines where the supplier changed a price, cut a quantity, moved a date, or rejected the item are flagged as exceptions and routed to a buyer with the variance shown explicitly — the same clean-lines-through, exceptions-to-a-human split that makes EDI 855 valuable, applied to documents that were never EDI.
Post straight to the ERP — Confirmed acknowledgments and their committed dates flow directly into SAP, Oracle, Microsoft Dynamics, and other systems of record, updating the order with the supplier's committed price, quantity, and delivery date. No one re-keys a PDF; no changed price slips through to become an invoice dispute later.
Proven on supplier order confirmations — This is not theoretical. Our work with Kloeckner (see the case study) automates exactly this flow: supplier order confirmations arriving as unstructured documents, read by AI, reconciled, and posted to the ERP — turning the manual acknowledgment-checking step into an exception-only workflow. The result is the operational benefit of EDI 855 without the EDI project.
Frequently Asked Questions
EDI 855 is the ANSI X12 Purchase Order Acknowledgment transaction. It is the structured electronic message a seller sends back to a buyer in response to an EDI 850 purchase order, confirming — line by line — whether each item is accepted, accepted with changes, backordered, or rejected, along with the price, quantity, and delivery date the seller commits to. An EDI 855 turns a purchase order from a one-way request into a confirmed, reconciled commitment before goods ship.
An 855 EDI document is a purchase order acknowledgment formatted in the ANSI ASC X12 standard. It contains a BAK header segment referencing the original PO, PO1 segments for each line item, and ACK segments carrying line-item status codes (such as IA for accepted, IB for backordered, IC for accepted with changes, and IR for rejected). The document lets the buyer's system automatically match the acknowledgment to the original order and route only the changed or rejected lines to a person.
The EDI 997 is a Functional Acknowledgment that only confirms an EDI file was received and could be parsed — a technical receipt. The EDI 855 is a business response that confirms what the seller will actually do with the order, line by line, including prices, quantities, and dates. A seller typically returns a 997 within minutes to confirm the 850 arrived, then an 855 once the order is processed. A 997 does not mean the order is accepted; only the 855 tells you that.
EDI 895 is the Delivery/Return Acknowledgment or Adjustment transaction, used mainly in grocery and warehouse replenishment to acknowledge a delivery or return and communicate adjustments. It is not a purchase order acknowledgment — that is the EDI 855. The two are sometimes confused because of the similar numbering, but the 855 acknowledges a PO while the 895 acknowledges the movement of goods later in the flow.
The line-item status codes live in the ACK segment and tell the buyer what the seller is doing with each line. Common codes include IA (item accepted as ordered), IB (item backordered), IC (item accepted with changes), IP (item accepted, price changed), IQ (item accepted, quantity changed / partial acceptance), IS (item accepted, schedule date changed), IR (item rejected), and ID (item deleted). These codes let a buyer's system auto-clear accepted lines and route changed or rejected lines to a buyer for a decision.
No. A true EDI 855 requires both trading partners to implement EDI, which most mid-market companies never complete across every partner. The majority of order acknowledgments are sent as PDF order confirmations or emails, which state the same information — accepted lines, prices, quantities, and dates. The limitation of PDFs and emails is that they are not machine-readable, so without automation a person has to read each one and compare it to the PO. AI extraction gives these documents the same straight-through, auto-reconciled handling an EDI 855 gets, without requiring EDI onboarding.
See what's under the hood.
See how GeneralMind runs your operations end-to-end — across email, ERP, and every team.
Explore GeneralMind
