EDI 855 purchase order acknowledgment: segments and status codes

Place the 855 in the order cycle before reading one

A buyer sends an 850 purchase order. The receiving translator returns a 997 functional acknowledgment, which reports only that the interchange parsed. The supplier then returns an 855, which is the first document in the exchange that carries a commercial answer. If the buyer later changes the order it sends an 860 and the supplier replies with an 865. When goods ship, an 856 advance ship notice reports what is on the truck. Reading the 855 as the commercial answer, and the 997 as a syntax receipt, prevents the most common misreading of an EDI order flow.

• 850 purchase order, sent by the buyer, functional identifier PO
• 997 functional acknowledgment, returned by the translator, functional identifier FA
• 855 purchase order acknowledgment, returned by the supplier, functional identifier PR
• 860 purchase order change request, buyer initiated, functional identifier PC
• 865 purchase order change acknowledgment, seller initiated, functional identifier CA
• 856 ship notice and manifest, sent by the supplier, functional identifier SH

Read the BAK segment for the header level answer

BAK is the beginning segment for a purchase order acknowledgment and it carries the document level verdict. BAK01 is the transaction set purpose code, normally 00 for an original. BAK02 is the acknowledgment type code and states whether the supplier is acknowledging with or without detail and with or without change. BAK03 repeats the buyer's purchase order number and BAK04 the purchase order date, which is how the acknowledgment is matched back to the order. BAK08 carries a release number when the order is a release against a blanket, and BAK09 carries the acknowledgment date.

• BAK01 transaction set purpose code, commonly 00 original
• BAK02 acknowledgment type code, the header level verdict
• BAK03 purchase order number, the match key back to the 850
• BAK04 purchase order date
• BAK08 release number for a release against a blanket order
• BAK09 acknowledgment date

Know the BAK02 acknowledgment type codes you will actually see

BAK02 tells you how much detail to expect and whether anything changed. Trading partners publish a subset in their implementation guide, so treat the values below as the common set rather than the full X12 list, and confirm the subset your partner supports before building logic on it. The important operational distinction is between an acknowledgment that carries line detail and one that does not: a header only acknowledgment leaves you with no line level promise to plan against.

• AD acknowledge with detail, no change
• AC acknowledge with detail and change
• AE acknowledge with exception detail only
• AK acknowledge, no detail or change
• AH acknowledge, hold status
• AP acknowledge, product replaced
• AT accepted
• RD reject with detail
• RF reject with exception detail only
• RJ rejected, no detail

Read line level truth in the PO1 and ACK segments

Inside each PO1 loop the supplier returns one or more ACK segments. ACK01 is the line item status code and is the single most useful field in the document. ACK02 carries the quantity the supplier is acknowledging and ACK03 the unit of measure, which is why a quantity change is visible even when the status code alone looks like an acceptance. ACK04 is a date or time qualifier and ACK05 the associated date, so a rescheduled line reports its new promised date there. Order level dates appear in DTM segments with qualifiers such as 002 for delivery requested and 010 for requested ship.

• IA item accepted
• IC item accepted, changes made
• IQ item accepted, quantity changed
• DR item accepted, date rescheduled
• IP item accepted, partial shipment
• IS item accepted, substitution made
• IW item accepted, will be shipped
• IB item backordered
• ID item deleted
• IR item rejected

Treat an 855 as evidence with known gaps

An 855 answers what the supplier says it will do at the moment it replies. It does not tell you that a human reviewed the order, that the promised date survived the following week, or that an internal buyer approved the change the supplier proposed. A header only acknowledgment carries no line promise at all. Silence carries nothing: many suppliers on an EDI relationship never send an 855 for a large share of orders, and no absence of a document can be counted as agreement. Build the open order report on the acknowledged line, the acknowledged date, and the time the acknowledgment arrived, and keep the original ordered values beside them rather than overwriting.

Run the same business event without an EDI connection

Most supplier bases are mixed. A small number of partners are on X12 and the rest respond by email, which is where line level promises stop being machine readable. Pacteva covers that second group: a reviewed purchase order goes out as a secure accountless link, the supplier accepts, declines, or proposes a quantity, price, or date change per line, and the buyer resolves each difference explicitly. The result carries the same four facts an 855 carries at line level, ordered value, supplier response, buyer decision, and current commitment, in a form a planner can export. Pacteva does not transmit X12, act as a VAN, or replace an EDI translator.

Validate the workflow with one real purchase order

Before buying or replacing software, run one representative multi-line PO from reviewed source through supplier response and buyer resolution. Include at least one accepted line, one proposed date or quantity change, and one delivery or reminder edge case. Confirm that every participant can identify the current owner and next action, that the original order remains unchanged, and that the final commitment can be exported and traced to its response and decision. Also verify the supplier experience on a normal phone and desktop browser, revoke and reissue a response link, inspect a failed delivery, and test the role boundary with a non-owner buyer. This evidence is more useful than a feature checklist because it exposes adoption friction, hidden authority, and incomplete system boundaries before the workflow reaches production volume.