EDI 855 — Purchase Order Acknowledgement
Supplier → Flxpoint · PO acknowledgement
EDI 855 — Purchase Order Acknowledgement
Purpose
Confirm receipt of a Purchase Order (850) and communicate your intent to fulfill it — line by line. Originates with the Supplier, sent to Flxpoint.
In Plain English
The 855 is the supplier's commitment back to the retailer: "I got your PO and here is exactly what I plan to ship." Unlike the 997 — which only confirms the file envelope arrived — the 855 confirms business intent, line by line. For each item on the original 850 the supplier responds with an acknowledgement code: accept as-is, accept with a changed quantity, backorder, or reject. Flxpoint uses the 855 to update the order status in the channel before the shipment actually moves, so the end customer sees accurate expectations. A missing or partial 855 is a common source of support tickets because the retailer cannot tell what will ship until the ASN arrives hours or days later.
Frequency
Send within 24 hours of receiving the 850. Required for every PO received.
Business Rules
- The 855 must reference the original 850 PO number
- You must respond to every line item from the 850
- Accepted quantity must be ≤ the original PO quantity
- Unit of measure must be
EA(Each) - Send one 855 per 850 — do not combine multiple POs in one 855
Status Codes
BAK02 — Transaction Purpose
| Code | Meaning |
|---|---|
AD | Accepted — PO is accepted as-is |
AC | Accepted with Changes — some lines modified |
RD | Rejected |
ACK01 — Line Item Status
Flxpoint resolves each line to acknowledged or canceled from the ACK01 code. The Standard EDI parser does not reject a file for an unrecognized ACK01 — a code in neither list is simply a no-op (the line ends up neither acknowledged nor canceled), so use a code from one of these lists.
Accepted (line acknowledged):
| Code | Meaning |
|---|---|
IA | Accepted, no change |
IQ | Accepted, quantity changed |
IP | Accepted, price changed |
DR | Accepted, date rescheduled |
IC | Accepted, changes made |
AC | Accepted and shipped |
AR | Accepted and released for shipment |
AA | Accepted — order forwarded to alternate supplier |
Rejected (line canceled):
| Code | Meaning |
|---|---|
IR | Rejected |
R1 | Rejected — not a contract item |
R2 | Rejected — invalid item / product number |
R4 | Rejected — contract item not available |
Pharma vendor variants: Kinray and AmerisourceBergen run custom parsers and add IS = Accepted with Substitution (the substitute item's identifiers follow on the ACK segment); AmerisourceBergen also treats IW (On Hold) as accepted. IB (Backordered) is not supported by the generic parser or by Kinray. Use these only if your integration's spec calls for them.
Vendors send more codes than the base parser maps — and that's fine. The base acknowledgement process maps only the four cancel codes (IR/R1/R2/R4); any other code is left unmapped, never rejected. Real vendors send a much wider set: RSR EDI alone sends ~25 codes including ROS, IB, CC, R3, R7. Because Flxpoint never rejects on ACK01, Flxpector does not flag an unrecognized ACK01 as invalid — if the inspector ever flagged a real vendor code like ROS it would be a false positive. If you need the cancellation reason surfaced (e.g. RSR), the vendor parser can write "{CODE} - {description}" to a fulfillment-request item custom field rather than expanding the accept/cancel lists.
Supported 855 senders: firearms/outdoor partners route their 855 through SPS Commerce. RSR sends its 855 this way today; Sports South 855 support is rolling out the same way (INT-56919 — dev-tested, in final rollout). Note that 860 (PO Change Request) is a different transaction; Flxpoint does not currently support inbound 860, even where a partner's SPS connection offers it.
Segment Hierarchy
ISA Interchange Header GS Group Header (GS01 = "PR") ST Transaction Set Header (ST01 = "855") BAK Beginning Acknowledgement for PO ┌─ PO1 Loop (repeats per line item) │ PO1 Line Item Detail │ ACK Line Item Acknowledgement └─ CTT Transaction Totals (optional) SE Transaction Set Trailer GE Group Trailer IEA Interchange Trailer
Segment Overview
| Segment | Name | FLX Status | Notes |
|---|---|---|---|
| ST | Transaction Set Header | Required | ST01 = 855 |
| BAK | Beginning Acknowledgement | Required | Purpose 00, ack type, PO#, date |
| N1 / N3 / N4 | Ship-To Loop | Situational | Ship-to address — mirror from 850 |
| PO1 | Line Item Loop | Required | One per line item from original 850 |
| ACK | Line Item Acknowledgement | Required | Status code per PO1 |
| CTT | Transaction Totals | Situational | Count of PO1 segments |
| SE | Transaction Set Trailer | Required |
Segment Specifications
ST — Transaction Set Header
| Element | Name | Length | M/O | Value/Notes |
|---|---|---|---|---|
| ST01 | Transaction Set ID Code | 3 ID | Required | 855 |
| ST02 | Transaction Set Control Number | 9 N | Required | Unique, must match SE02 |
BAK — Beginning Acknowledgement
| Element | Name | Length | M/O | Value/Notes |
|---|---|---|---|---|
| BAK01 | Transaction Set Purpose Code | 2 ID | Required | 00 (Original) |
| BAK02 | Acknowledgement Type | 2 ID | Required | AD (Accepted), AC (Accepted with Changes), RD (Rejected) |
| BAK03 | Purchase Order Number | 22 AN | Required | Must match BEG03 from the original 850 |
| BAK04 | Date | 8 DT | Required | Date of acknowledgement (CCYYMMDD) |
N1 Loop — Ship-To Address (Situational)
When included, the N1 loop mirrors the Ship-To address from the original 850.
| Element | Name | Length | Status | Value/Notes |
|---|---|---|---|---|
| N101 | Entity Identifier Code | 3 ID | Required | ST (Ship To) |
| N102 | Name | 60 AN | Required | Customer name |
| N103 | Identification Code Qualifier | 2 ID | Situational | ZZ (Mutually Defined) |
| N104 | Identification Code | 80 AN | Situational | Facility or location identifier |
N3 and N4 follow (address line, city/state/zip) — same structure as 850.
PO1 — Line Item Detail
PO1 in the 855 echoes back the line items from the original 850. Include the same product identifiers that were in the 850 PO1. Multiple ID pairs (positions 6–17) are supported.
| Element | Name | Length | Status | Value/Notes |
|---|---|---|---|---|
| PO101 | Assigned Identification | 20 AN | Required | Line item number from the 850 |
| PO102 | Quantity Ordered | 15 N | Required | Original quantity from the 850 |
| PO103 | Unit of Measure | 2 ID | Required | EA (Each) |
| PO104 | Unit Price | 17 R | Situational | Unit price from the 850 |
| PO106 | Prod/Serv ID Qualifier | 2 ID | Required | Generic parser expects SK here. It reads a strict positional layout: SK@PO106, BP@PO108, EN@PO110, MG@PO112, UP@PO114, VP@PO116 (value in the following element). Pharma vendors (Kinray, AmerisourceBergen) use VN at PO106 via custom parsers |
| PO107 | Prod/Serv ID | 48 AN | Required | Primary identifier — must match the 850 |
| PO108 | Prod/Serv ID Qualifier | 2 ID | Situational | Additional type (e.g., BP Buyer Part #, EN EAN, MG Manufacturer) |
| PO109 | Prod/Serv ID | 48 AN | Situational | Value for PO108 qualifier |
| PO110–PO117 | Additional ID Pairs | — | Situational | Up to 4 more pairs matching the 850 |
Tip: Include all product ID pairs that were in the original 850 PO1. This ensures Flxpoint can match the acknowledgement to the correct line item even if the primary ID is ambiguous.
ACK — Line Item Acknowledgement
| Element | Name | Length | M/O | Value/Notes |
|---|---|---|---|---|
| ACK01 | Line Item Status Code | 2 ID | Required | An accept code (IA/IQ/IP/DR/IC/AC/AR/AA) or a reject code (IR/R1/R2/R4) — see Status Codes above |
| ACK02 | Quantity | 15 N | Required | Acknowledged quantity. Must be ≤ PO102 |
| ACK03 | Unit of Measure | 2 ID | Situational | EA (Each) — read by some vendor parsers |
The generic Standard EDI parser reads only ACK01 (status) and ACK02 (quantity) from the ACK segment. Product identifiers come from the PO1 segment, not the ACK.
Pharma vendor variant — ACK identifiers & substitution
This applies only to Kinray / AmerisourceBergen (custom parsers), not to the generic 855. When ACK01 = IS (Accepted with Substitution), the substitute item's identifiers ride in later ACK positions — Kinray scans ACK07/08 through ACK13/14 for qualifiers ND/N4 (NDC), VC/VN (vendor catalog), UP (UPC). For those integrations, include the identifier the PO line carries so Flxpoint can match the line; otherwise the SKU resolves null and the ack fails to save (root cause of the Kinray cross-dock 855 issue, mid-2026).
Cross-Dock PO acknowledgements
For a Cross-Dock PO, saving the 855 is idempotent — once the acknowledged quantity is recorded it cannot be re-applied. Re-sending the same 855 returns Acknowledged quantity can't be greater than total quantity for sku …, which is expected. The Cross-Dock PO stays in Processed status (there is no separate "Acknowledged" status badge for cross-dock).
SE — Transaction Set Trailer
| Element | Name | Length | M/O | Value/Notes |
|---|---|---|---|---|
| SE01 | Number of Included Segments | 6 N | Required | Count of all segments including ST and SE |
| SE02 | Transaction Set Control Number | 9 N | Required | Must match ST02 |
Example File
ISA*00* *00* *ZZ*SUPPLIER *ZZ*FLXPOINT *240115*1200*U*00401*000000010*0*P*>~GS*PR*SUPPLIER*FLXPOINT*20240115*1200*10*X*004010VICS~ST*855*0010~BAK*00*AD*PO-12345678*20240115~PO1*1*2*EA*29.99**SK*SKU-ABC123~ACK*IA*2*EA~PO1*2*1*EA*49.99**SK*SKU-DEF456~ACK*IA*1*EA~PO1*3*4*EA*15.00**SK*SKU-GHI789~ACK*IQ*2*EA~SE*9*0010~GE*1*10~IEA*1*000000010~
Scenario: 3-line PO response
- Line 1 (SKU-ABC123): 2 units — Fully accepted (
IA) - Line 2 (SKU-DEF456): 1 unit — Fully accepted (
IA) - Line 3 (SKU-GHI789): Only 2 of 4 units available — Partial acceptance (
IQ, qty=2)
Common Mistakes
⚠️ ACK02 must always be ≤ PO102. You cannot accept more than was ordered. Sending a higher quantity will cause a validation error.
⚠️ BAK03 must exactly match the PO number from BEG03 of the 850. A mismatch means Flxpoint cannot link the acknowledgement to the original order.
⚠️ One 855 per 850. Never combine acknowledgements for multiple POs in a single transaction set.
Something unclear?
Ask our AI assistant — it knows this spec and can explain any segment, error, or rule in plain English.