855

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

CodeMeaning
ADAccepted — PO is accepted as-is
ACAccepted with Changes — some lines modified
RDRejected

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):

CodeMeaning
IAAccepted, no change
IQAccepted, quantity changed
IPAccepted, price changed
DRAccepted, date rescheduled
ICAccepted, changes made
ACAccepted and shipped
ARAccepted and released for shipment
AAAccepted — order forwarded to alternate supplier

Rejected (line canceled):

CodeMeaning
IRRejected
R1Rejected — not a contract item
R2Rejected — invalid item / product number
R4Rejected — 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

code
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

SegmentNameFLX StatusNotes
STTransaction Set HeaderRequiredST01 = 855
BAKBeginning AcknowledgementRequiredPurpose 00, ack type, PO#, date
N1 / N3 / N4Ship-To LoopSituationalShip-to address — mirror from 850
PO1Line Item LoopRequiredOne per line item from original 850
ACKLine Item AcknowledgementRequiredStatus code per PO1
CTTTransaction TotalsSituationalCount of PO1 segments
SETransaction Set TrailerRequired

Segment Specifications

ST — Transaction Set Header

ElementNameLengthM/OValue/Notes
ST01Transaction Set ID Code3 IDRequired855
ST02Transaction Set Control Number9 NRequiredUnique, must match SE02

BAK — Beginning Acknowledgement

ElementNameLengthM/OValue/Notes
BAK01Transaction Set Purpose Code2 IDRequired00 (Original)
BAK02Acknowledgement Type2 IDRequiredAD (Accepted), AC (Accepted with Changes), RD (Rejected)
BAK03Purchase Order Number22 ANRequiredMust match BEG03 from the original 850
BAK04Date8 DTRequiredDate of acknowledgement (CCYYMMDD)

N1 Loop — Ship-To Address (Situational)

When included, the N1 loop mirrors the Ship-To address from the original 850.

ElementNameLengthStatusValue/Notes
N101Entity Identifier Code3 IDRequiredST (Ship To)
N102Name60 ANRequiredCustomer name
N103Identification Code Qualifier2 IDSituationalZZ (Mutually Defined)
N104Identification Code80 ANSituationalFacility 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.

ElementNameLengthStatusValue/Notes
PO101Assigned Identification20 ANRequiredLine item number from the 850
PO102Quantity Ordered15 NRequiredOriginal quantity from the 850
PO103Unit of Measure2 IDRequiredEA (Each)
PO104Unit Price17 RSituationalUnit price from the 850
PO106Prod/Serv ID Qualifier2 IDRequiredGeneric 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
PO107Prod/Serv ID48 ANRequiredPrimary identifier — must match the 850
PO108Prod/Serv ID Qualifier2 IDSituationalAdditional type (e.g., BP Buyer Part #, EN EAN, MG Manufacturer)
PO109Prod/Serv ID48 ANSituationalValue for PO108 qualifier
PO110–PO117Additional ID PairsSituationalUp 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

ElementNameLengthM/OValue/Notes
ACK01Line Item Status Code2 IDRequiredAn accept code (IA/IQ/IP/DR/IC/AC/AR/AA) or a reject code (IR/R1/R2/R4) — see Status Codes above
ACK02Quantity15 NRequiredAcknowledged quantity. Must be ≤ PO102
ACK03Unit of Measure2 IDSituationalEA (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

ElementNameLengthM/OValue/Notes
SE01Number of Included Segments6 NRequiredCount of all segments including ST and SE
SE02Transaction Set Control Number9 NRequiredMust match ST02

Example File

EDI · 004010VICS
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.