Partial Shipments and the 855: Getting Sam's Club and Walmart Acknowledgments Right Before the 856

A partial shipment is a normal day in the warehouse. The PO asks for 40, you have 28, and you ship 28. In EDI, though, it's one of the easiest ways to get a document rejected. The 855 Purchase Order Acknowledgment has to tell the retailer what happened to every line, in the retailer's own codes, before the ASN arrives to say what actually shipped.

This fall brought a reminder of how fragile that step is. In a September r/EDI thread, a Sam's Club supplier said its partial-shipment 855s started getting rejected around August 20, with no change on its side. After some back-and-forth, Sam's reportedly said it wanted a quantity-change code (IQ) for partials, not the reject code (IR) the supplier had been sending. The spec Sam's sent over was the older version the supplier already had, and it didn't clearly describe that usage. Replies in the thread pointed to two other suspects. Did the 855 repeat every original PO line with its exact line number? And was the 855 still going out before the 856?

That's one supplier's account, not a published retailer bulletin, so treat it as a signal rather than a rule. The failure pattern is common, though. Below is how a partial-shipment 855 should be built, what Walmart's published rules say, and how to read the 824 that comes back.

Why the 855 matters more on a partial

The 997 confirms that your file arrived and parsed. The 855 confirms what you plan to do with the order, line by line. On a partial, retailers use it to adjust what they expect at the dock, what they expect you to invoice, and whether they need to source the balance somewhere else.

So a mismatch hurts later. If your 855 says 40 accepted and your 856 says 28 shipped, that's a variance the retailer didn't plan for. If your 855 rejects the line and your ASN then ships 28 against it, the retailer is looking at an ASN for something it thinks was canceled. Either way, the trouble shows up downstream as an 824, a receiving exception, or an invoice that won't match.

Rule one: echo every 850 line with its original line number

The most common structural mistake is acknowledging only the lines that changed, or letting the ERP renumber lines when it rebuilds the order.

Walmart's published 855 spec for its Drop Ship Vendor program is explicit about this. Each PO1 loop carries the purchaser's order line number (qualifier PL), and that value has to match the original PO101 from the 850. Every PO1 needs an ACK segment, and that segment's quantity is required. Other Walmart programs use different layouts, but the principle holds across them: the 855 answers the retailer's lines. It isn't a new document built from yours.

Before an 855 goes out, check:

In the r/EDI replies on the Sam's thread, people zeroed in on this same point. An 824 complaining about a line-number mismatch usually means the 855 didn't mirror the 850's lines the way the retailer's current map expects. Changing the status code won't fix that.

Rule two: use the status code the retailer expects

X12 offers many ACK01 line-status codes. These are the ones that come up on partials:

Code X12 meaning Typical use
IA Item accepted Shipping the full line as ordered
IQ Item accepted, quantity changed Shipping part of the line
IB Item backordered Balance to follow, where backorders are allowed
IR Item rejected Not shipping the line
R1, R2, R4 Item rejected, with a reason Discontinued, invalid item, or not available

Each retailer picks which codes it accepts. Walmart's Drop Ship Vendor 855 lists IA, ID (canceled), R1, R2, R4, and AR (released for shipment), and IA has to come before AR. Some other drop-ship partners accept only IA and IR and don't allow backorders at all. According to the r/EDI report, Sam's now wants IQ instead of IR for a partial.

Keep the meanings straight. IR says "I'm not shipping this line." IQ says "I'm shipping this line at a different quantity," and the accepted quantity has to match what actually ships. Send IR and then ship 28 units, and you've contradicted your own acknowledgment.

When your spec doesn't settle the question, as happened to the Sam's supplier, get the answer in writing from the retailer's EDI team and file it with the map. A verbal "use IQ" that contradicts the PDF tends to get lost when the person who heard it moves on.

Rule three: send the 855 inside the window, before the 856

Acknowledgment windows vary. Some retailers count hours from receipt of the 850, and others count business days. Follow your partner's guide.

Order matters as much as timing. Integrators have warned that a rejected Walmart 855 can lead to rejected 856s and then rejected 810s, even when those later documents are clean. Practitioners also report that when the 855 and 856 go out close together, the ASN sometimes gets processed first.

Reading the 824: WARN, ERROR, and the 824 with no text

The 824 Application Advice is where retailers grade your data against their business rules. It's also where teams misread how serious a problem is.

SPS Commerce documents Walmart's ASN validation flow this way. If the 997 is rejected, Walmart couldn't read the file, so fix it and resend. If no 997 arrives at all, the ASN may never have been processed, so check your sender and receiver IDs. Once you have a clean 997, keep watching for an 824:

Two traps follow from that. One is treating a WARN as a stop-ship. The other is worse: an 824 with no text looks harmless, so any alert that filters on the word "ERROR" misses it. Walmart tightened its ASN business rules in May 2024 and said more error and warning 824s would follow, though without new SQEP charges at that point. SPS noted that Walmart usually sets a standard first, then tracks compliance, then starts charging. The ASN 824 Resolution Guide in Retail Link explains individual messages. Other retailers word their 824s differently, so translate each partner's language onto one internal scale: informational, fix and resend, or fix before arrival.

The spec on file is never the whole story

The Sam's thread shows where the real risk sits. The supplier's map didn't change. The retailer's validation apparently did, and the documentation the supplier had on hand didn't explain it. The supplier found out from rejections, then spent time chasing an answer.

Retailers change rules on their own schedule. Sometimes a bulletin goes out first, and sometimes the first sign is a pile of 824s. Three habits close the gap:

How managed EDI catches the silent change

IDXE is EDI Partners' proprietary, Azure-native managed EDI platform, and this work is what it's built for. That means partner-specific 855 maps that echo the 850 line for line, and validation that checks status codes, quantities, and line numbers against each retailer's current rules before anything goes out. It also means sequencing that holds the 856 until the acknowledgment clears, and 824 monitoring that reads severity the way each retailer means it, including the 824s with no text.

The bigger difference is who's watching. A managed team that sees traffic across many partners spots a quiet retailer change sooner than a supplier working from an onboarding PDF. EDI Partners then handles it as an operations event: confirm the rule with the retailer, update the map, log the change, and resend whatever needs resending.

Takeaways

If partial-shipment acknowledgments keep bouncing for one retailer, the cause is usually a rule change nobody announced, not something you broke. Talk to EDI Partners about 855 and 824 monitoring with IDXE →