How to Send an EDI 855 to Amazon Vendor Central

Amazon Vendor Central won't tell you your EDI 855 was wrong. It just deducts money. If you've ever gotten a chargeback for a purchase order acknowledgment that "looked fine" when you sent it, this walkthrough is for you. We'll build a compliant EDI 855 purchase order acknowledgment segment by segment, in response to a real Amazon EDI 850, and cover the specific way partial rejections go wrong when the ACK codes don't match what actually ships.

What the EDI 855 Actually Does (and Why Amazon Enforces It)

The 855 is the seller's formal response to a buyer's 850. It confirms, modifies, or rejects an order, and it does so at the line-item level, not just at the header. TrueCommerce describes it plainly: an EDI 855 Purchase Order Acknowledgement is an EDI transaction set normally sent by a seller to a buyer in response to an EDI 850 Purchase Order, and the document tells the buyer if the purchase order was accepted, required changes, or was rejected.

SPS Commerce frames the acknowledgment details the same way: confirmation of the entire order or specific line items, including the status of each item (accepted, rejected or backordered). That granularity is the entire point. A blanket "yes" on the header doesn't tell Amazon anything useful if three of your twelve line items are actually short.

One thing people get wrong early: the 855 is not a substitute for the 997 functional acknowledgment. This EDI transaction is not meant to take the place of an EDI 997 Functional Acknowledgement but should be sent in addition. The 997 confirms Amazon's translator could parse your file syntactically. The 855 confirms whether you can actually fulfill the order. You need both, and they answer different questions.

Before You Start: Prerequisites

Don't start mapping until you have these in hand:

• A validated, successfully translated EDI 850 from Amazon, including the PO number, line-level quantities, unit of measure, and UPC or vendor SKU on every line.
• Access to your inventory or allocation system so ACK quantities reflect what you can actually ship, not what the 850 requested.
• Amazon's current trading partner specification for the 855, pulled from your VAN or translator (Cleo, TrueCommerce, SPS Commerce, Stedi, or IBM Sterling all publish Amazon-specific guides).
• Confirmation of your response window. Amazon's is generous compared to some retailers, but generous is relative.

On that last point: know your partner's clock before you build anything. Amazon expects rapid responses—typically within 24 hours—as the basis for order confirmation and downstream planning. Compare that to Target, which is the outlier almost everyone gets wrong the first time. According to BOLD VAN, most major retailers, including Walmart, Kroger, Costco and Home Depot, require a response within 24 to 48 hours of PO receipt, while Target is the famous outlier at 30 minutes. If you're building one 855 template and reusing it across retail partners, that 30-minute figure alone should tell you why a single generic map doesn't survive contact with a real partner portfolio.

Step-by-Step: Building the 855

1. Pull the original 850 and extract the header and line data. You need the PO number, PO date, every line item's requested quantity, unit of measure, and the product identifier qualifier Amazon used (usually UP for UPC or SK for vendor SKU).
2. Build your envelope headers. Populate ISA, GS, and ST using the interchange qualifiers your Amazon trading partner agreement specifies, and increment your control numbers per your normal outbound sequencing. Get this wrong and the whole interchange bounces before anyone even looks at your ACK codes.
3. Construct the BAK segment. This is the Beginning Segment for Purchase Order Acknowledgment, and BAK02 carries the overall acknowledgment type: AD for "acknowledge with detail and change," AC for "acknowledge with detail, no change," or RD for "rejected detail." BAK03 and BAK04 carry the original PO number and PO date exactly as they appeared on the 850. Amazon's own sample files use exactly this pattern, for example BAK*00*AD*L1234567*20130805, pairing the acknowledgment type with the vendor's original PO number.
4. Loop through PO1 segments, one per line item. Mirror the quantity, unit of measure, and product ID qualifier from the corresponding 850 line. Do not invent a new line numbering scheme, Amazon matches on PO1 sequence back to the original order.
5. Attach an ACK segment to every PO1 loop. ACK01 carries the disposition code for that specific line. The three you'll use most often against Amazon are IA (item accepted), IR (item rejected), and IB (item backordered). If a product identifier itself was wrong, R2 flags a rejected line due to an invalid or unrecognized product number. ACK02 and ACK03 carry the quantity and unit of measure you're actually confirming for that status, which may be less than what was ordered.
6. Add DTM segments for any changed ship or delivery dates. If you're backordering a quantity, DTM qualifier 067 (or your partner's equivalent) tells Amazon when to expect that portion, rather than leaving them guessing.
7. Close with CTT and your trailers. CTT01 is the count of PO1 line items included in the transaction, used by the receiver to validate that nothing dropped in transit. Follow with SE, GE, and IEA to close out the transaction set, functional group, and interchange.
8. Transmit over the same channel used for the 850, typically AS2, and log your interchange control number so you can trace the acknowledgment later if a dispute comes in.

Here's the structural skeleton you're aiming for, condensed from Amazon's own published 855 sample: a BAK header, then one PO1/ACK/DTM cluster per line, then CTT and trailers. Every line item on the original 850 needs its own PO1/ACK pair in your response. Amazon is explicit about this: partial acknowledgments are not accepted; rejections or changes need to be specified per line. You cannot roll up a mixed order into one summary status.

How to Confirm It Worked

You know the 855 landed correctly when two things happen. First, your translator receives a 997 functional acknowledgment back from Amazon's VAN or AS2 endpoint, confirming syntactic acceptance of the interchange, envelope structure, and segment counts. No 997, or a rejected one, means Amazon's system never processed your file at the structural level, regardless of what your ACK codes said.

Second, check the Amazon Vendor Central EDI dashboard or your VAN's tracking portal for a "received" or "acknowledged" status tied to the original PO number. If the PO still shows as awaiting acknowledgment past your response window, don't wait for a chargeback notice to tell you something failed silently.

Common Failure Mode: Mismatched ACK Codes and Late Response

The failure that costs the most money isn't a missing 855. It's a technically valid 855 that lies. A supplier sends BAK02=AC with every line ACK01=IA, full acceptance, because it's the fast path and inventory looked fine that morning. Two days later the warehouse discovers a short pick on line 4. The ASN goes out reflecting the real quantity, the 810 invoice follows the ASN, and now Amazon has three documents that don't agree with each other, plus an 855 that promised something you didn't deliver.

BOLD VAN's analysis of 855 rejections puts it directly: when an EDI 855 Purchase Order Acknowledgment is rejected during partner testing, the root of the issue usually lies in mapping errors, code mismatches, missing required elements, or misinterpretation of trading partner specifications. The same logic applies in production, except now it's not a test failure, it's a chargeback.

The fix is validation before transmission, not correction after the fact. Before you send the 855, check every ACK quantity against real-time inventory or allocation data, not the previous night's snapshot. If a line can't be fully confirmed, use IB or IR honestly, with a corrected DTM date if it's a backorder rather than a hard reject. Automate exception flagging so a human reviews anything that isn't a clean full accept, instead of defaulting every line to IA because that's what the template does. A slower, accurate 855 beats a fast, wrong one every time a chargeback report gets generated.

Where This Fits in Your Broader EDI-to-TMS Workflow

Once an 855 confirms a ship date, that date doesn't stay inside your EDI translator. It flows into the ASN you'll send as an 856, and from there into carrier tendering and pickup scheduling. If the 855 promised a date the warehouse can't hit, that error propagates straight into whatever system is booking freight, whether that's Cargoson, MercuryGate, Descartes, or Uber Freight. A TMS building a tender schedule off a confirmed ship date that was never actually confirmable isn't a compliance problem anymore, it's a working capital and carrier reliability problem. Getting the 855 right at the source is cheaper than untangling it three systems downstream.

Key Takeaways

• Segment order is BAK, then a PO1/ACK/DTM loop per line, then CTT, SE, GE, IEA. Every original 850 line needs a matching PO1/ACK pair.
• Amazon expects the 855 within roughly 24 hours of the 850; Target expects it within 30 minutes, so don't build one template for every retailer.
• A 997 confirms syntax, not fulfillment. You still need the 855 to confirm what you can actually ship.
• Validate ACK quantities against live inventory before transmission. Blanket IA acceptance is the single most common cause of downstream 856/810 mismatches and chargebacks.
• Partial header-level acknowledgments aren't accepted by Amazon. Reject or modify at the line level, every time.