EDI 855 Purchase Order Acknowledgment Builder

What an 855 PO Acknowledgment Is

The X12 855 is the supplier's structured reply to an inbound 850 — a line-by-line "here's what I can actually ship" that's the second step of the EDI procurement loop. Unlike the 997 (which is a lightweight "I got your file" transport receipt), the 855 is business content: it confirms each PO line as accepted, accepted-with-changes, or rejected, along with a promised ship date, a promised price, and a promised quantity that may differ from what the buyer asked for. Buyers use the 855 to reserve dock space, update their inventory projection, and warn merchandisers about out-of-stock substitutions long before the 856 ship notice arrives. Most retail contracts require an 855 back within the same business day; compliance programs at Walmart, Target, and Amazon Vendor Central assess chargebacks against suppliers who don't reply, or who reply after their window closes.

The BAK02 Header and Line-Level ACK Codes

An 855's structure mirrors the 850 it's acknowledging, with two additions. The BAK segment (Beginning Segment for PO Acknowledgment) carries an overall acknowledgment type code — the most common being AC (acknowledge with detail and change) for the typical case where most lines ship as ordered and a few change, or AP / AT for simple accept / accept-with-changes. Then each PO1 line gets an ACK segment with a line-level code: IA (accepted as specified), IQ (accepted, quantity changed — the second-most common), IP (accepted, price changed), IC (accepted, multiple changes), IR (rejected, we can't ship it), IB (accepted, schedule date pending), or IS (accepted, substitute provided). The acknowledged quantity and unit travel in ACK02 and ACK03. DTM*067 carries the promised ship date, DTM*068 the promised delivery date.

How This Tool Generates a Valid 855

Paste or drop the inbound 850 and the tool populates everything: the PO number and date from BEG, the buyer and vendor parties from N1 loops, every PO1 as a 855 line pre-marked IA. Change any status to IQ / IP / IC / IR via a dropdown, edit the quantity or price inline for change codes, and add promised ship / delivery dates. "Bulk set" accepts or rejects every line at once for the common end-of-day batch case. The envelope uses standard ANSI X12 4010: a fixed-length 106-character ISA, a GS functional group header with PR (PO Acknowledgment) identifier, an ST*855 transaction set containing BAK, optional CUR (currency), REF segments for vendor reference and department, optional FOB, DTM*002 / DTM*067 / DTM*068 for requested / promised ship / promised delivery, N1/N3/N4 loops for buyer/vendor/ship-to/bill-to, per-line PO1 + ACK (+ PID description), and a CTT line-count trailer. The reply partner auto-swaps ISA06/08 and GS02/03 from the inbound envelope. Generated files parse cleanly through the EDI File Parser. The companion EDI 850 PO Builder, 856 ASN Builder, and 810 Invoice Builder share the same trading-partner store; the 997 Functional Ack Builder acknowledges the envelope.

What This Tool Isn't

This is a hand-builder — a developer testing a new trading-partner spec, a supplier producing a one-off reply, or a team reverse-engineering a buyer's acknowledgment expectations. It does not look up inventory or prices from any backing system (you decide IA vs. IQ vs. IR per line by hand), does not emit partner-specific compliance extensions (Walmart's VICS 4010 quirks, Target's supplier portal qualifiers, Amazon's required REF codes), does not handle transmission, and does not run reciprocal 997 tracking to verify the buyer received the 855. In production, those are all part of the integration; Ask James if you need the full loop.

EDI Integration with Your Systems

Most of the EDI integration work I do bridges X12 and whatever formats your systems produce and consume — modern APIs, database tables, spreadsheet exports, flat files, or legacy platform-native formats. Inbound direction: a partner's 850/856/997 lands in the exact shape your order entry, WMS, or AP system expects. Outbound direction: validator-clean 810/850/855/856/820 built from your systems' native data — handling partner-specific variations, acknowledgments, and exception workflows.

Need Automated PO Acknowledgments?

In production, 855s are emitted automatically within a partner-defined SLA — often measured in hours, sometimes within 15 minutes of the 850 arriving. The real work is wiring the inbound PO to the supplier's inventory, pricing, and allocation systems so the 855 reflects what can actually be shipped; routing exception lines (substitutions, partial availability, price mismatches) to human review without holding up the whole acknowledgment; and emitting the 855 with correct status codes and change values back through AS2, SFTP, or VAN. I build that loop, validator-tested against your buyer's implementation guide, with the glue to your ERP or WMS so the full 850 → 855 → 856 → 810 cycle runs without manual intervention. For 855 SLA compliance, trading-partner onboarding with a new buyer, or rescuing a chargeback-triggering acknowledgment program, Ask James.