Setting Up EDI 852 for Walmart VMI Replenishment
How to configure, map, and test an EDI 852 feed from Walmart Retail Link for VMI, including ZA segment codes and rejection fixes.
Walmart tells a supplier to "start receiving 852s" and the supplier's EDI team spends the next two weeks trying to figure out what that actually means for their translator, their ERP, and their replenishment planners. If you're in that position right now, this walkthrough covers the actual build: envelope setup, ZA/SDQ mapping, CTT validation, and the acknowledgment loop, plus where these feeds typically break in production.
What the EDI 852 Actually Triggers Before You Start Mapping
The EDI 852 isn't a purchase order and it isn't an inventory snapshot. Product activity data enables a trading partner to plan and ship, or propose inventory replenishment quantities, for distribution centers, warehouses or retail outlets. That distinction matters because it changes who's driving the transaction. In a standard replenishment model, Walmart cuts an 850 purchase order based on its own inventory math. In a vendor-managed inventory arrangement, that responsibility shifts to you. EDI 852 plays a major role in enhancing supply chain visibility and is especially helpful for those using Vendor Managed Inventory and Scan-Based Trading approaches.
It's also worth separating the 852 from its cousin, the 867 Product Transfer and Resale Report, since both cross an EDI manager's desk in retail programs. The 852, called the Product Activity Data report, carries point-of-sale and inventory figures from a retailer back to the manufacturer. The 867 documents business-to-business movement: distributors shipping to resellers, wholesalers selling to professional end-users, or warehouses transferring stock between locations. If you're building a Walmart Retail Link feed for VMI, you're squarely in 852 territory. The 867 shows up more with distributor-to-distributor reporting.
Before You Start: Prerequisites Checklist
Don't open your translator until these are confirmed. Missing any one of them turns your first production transmission into a debugging session instead of a go-live.
- A signed VMI addendum to your Walmart trading partner agreement, with the retailer's specific 852 implementation guide in hand (formats vary by trading partner and even by division within the same retailer)
- Confirmed X12 version, since 004010 and 005010 handle qualifiers and date/time formatting differently, and your ISA/GS envelope needs to match what the retailer's gateway expects
- Working AS2 or VAN connectivity, with 997 or 999 functional acknowledgments already exchanging cleanly on other transaction sets before you add the 852 into the mix
- A current item master cross-reference mapping your UPC/GTIN to Walmart's internal item numbers and store numbers, since store-level identifiers are typically established during trading partner setup and drift over time as stores open, close, or get renumbered
- Mapping software capable of handling repeating LIN, ZA, and SDQ loops without flattening them, whether that's a platform like Cleo, TrueCommerce, or SPS Commerce, or a custom X12 parser your team maintains
On the connectivity side, know which transmission method you're on before you start mapping, since it affects error handling and cost. A Value Added Network acts as a secure middleman, and both partners connect to the VAN, which handles routing, format translation, and delivery confirmation. AS2 works differently: it creates a direct encrypted connection over the internet, using TLS/SSL to secure the channel and S/MIME to encrypt the payload, with non-repudiation through a digitally signed Message Disposition Notification.
Step-by-Step: Building and Receiving the 852
Once your prerequisites are locked, the build itself follows a predictable sequence. Here's the order that avoids rework.
- Pull the implementation guide and confirm cadence. Don't assume daily. Unlike many other EDI transaction sets, the 852 is often transmitted on a schedule rather than as a result of an event, and many retailers provide their suppliers with an 852 for each SKU on a weekly basis. Confirm whether Walmart's spec for your category is daily, weekly, or event-triggered on significant inventory shifts, because your downstream replenishment logic needs to match that rhythm.
- Set up the envelope. Configure ISA01-ISA08 and GS02/GS03 with Walmart's actual sender/receiver qualifiers, not generic placeholders, and confirm the BGN segment's transaction reference and date fields align with what the implementation guide specifies.
- Map the N1 loop. Identify the buyer and ship-to/store entities, using GLNs or Walmart-assigned store numbers depending on what the spec calls for.
- Parse the XQ segment. This carries your reporting window. XQ02 is the reporting date, and if reporting a date range, XQ02 is the start date and XQ03 is the end date. Get this wrong and every downstream quantity gets attributed to the wrong period.
- Map the LIN loop per SKU. Pull pricing from the CTP segment where present. X12's published 852 example shows this in practice: a supplier includes the product's retail price directly in the transaction, with the seller deciding to include the product's retail (code RTL) price, which is $12.57, giving the manufacturer visibility into selling price alongside movement.
- Map ZA activity codes and tie them to SDQ store quantities. This is the core of the transaction. The core of an EDI 852 is a set of quantity codes in the ZA segment, the X12 segment carrying per-SKU quantity data, each tagged to a specific activity type. Common codes include QA for quantity available and QS for quantity sold. X12's own documentation illustrates the split mechanic clearly: a ZA loop reporting gross on-hand quantity showed the first ZA Loop reporting the Gross Quantity On-Hand, with 500 products on-hand amongst the reported locations, and the SDQ segment underneath it broke that 500 down as the 500 eaches split amongst three pharmacy locations, with one location holding 115, another 120, and the third 265. Your Walmart feed works the same way, just with store numbers instead of NPI pharmacy IDs.
- Validate CTT hash totals and segment counts. The number of line items (CTT01) is the accumulation of the number of LIN segments, so if your parser reports a CTT01 that doesn't match your actual LIN count, stop before you acknowledge the file. Note that hash total usage in CTT02 varies by trading partner spec, so check whether Walmart's guide requires it or leaves it unused.
- Return a 997 or 999 functional acknowledgment and log the transaction with timestamp, control numbers, and segment counts for audit purposes before it touches your ERP.
Wiring the 852 Into Your Replenishment Logic
Receiving a clean 852 isn't the finish line, it's the input. The data still has to feed a decision engine, whether that's a VMI module inside your ERP, a dedicated planning tool, or a rules engine your team built, that converts on-hand and sales activity into a proposed shipment quantity. Skip this step and you've built an expensive reporting feed with no action attached to it.
In practice, 852 data rarely sits alone. It typically flows alongside or into 850 purchase orders and supplier-generated shipment recommendations, which then need to become 856 advance ship notices once a shipment is approved. Once your replenishment engine decides what ships and when, that shipment still has to get tendered to a carrier and tracked to delivery. This is the handoff point where transport execution platforms take over from the VMI decision layer, whether that's MercuryGate, Descartes, Blue Yonder, Uber Freight, Alpega, or a multi-carrier connectivity layer like Cargoson, which consolidates carrier communications, freight rate management, shipment tracking, and logistics document generation into a single dashboard. The 852 tells you what to ship. Something else has to actually move it.
Testing Before Go-Live
Run parallel transmissions before flipping production traffic. If Walmart offers a test environment for the transaction, use it, and check two things specifically: segment counts and hash totals matching your LIN loop count exactly, and store/item cross-reference tables reflecting current numbers rather than what was documented at initial trading partner setup. Outdated store mappings are the single most common cause of silent data loss in 852 feeds, since the file processes without error but quantities land against a store ID that no longer exists in your system, effectively vanishing from your replenishment math.
Failure Mode: Rejected or Silently Dropped 852s
Two failure patterns show up repeatedly once you're live. The first is an outright rejection, either a 997/999 with an error code or a file your translator accepts but can't fully process. The usual culprits are mismatched ZA activity codes your mapping doesn't recognize, a missing CTT segment, or SDQ store IDs that don't exist in your current cross-reference table. The fix is mechanical but requires discipline: re-verify the store ID table against Walmart's current list, confirm your CTT01 accumulation matches the actual LIN segment count in the file, and re-test with a sample transmission before resending anything to production.
The second pattern is worse because it doesn't throw an error. A file with incomplete data, say a missing CTP pricing element, still processes and still generates a 997 acknowledgment. But your downstream forecasting engine now has activity numbers without pricing context, and nobody notices until a planner asks why the replenishment recommendation looks off. This isn't a hypothetical edge case. The EDI 852 is a complex and lengthy document, and analyzing the data is difficult, even for suppliers working with one retailer. Poor data quality, such as inaccurate inventory levels, can make it difficult to rely on the data to make decisions. Build a validation layer that flags incomplete ZA/SDQ pairs before they ever reach your ERP, not after a planner catches the discrepancy manually.
Part of the difficulty is structural, not just technical. Every retailer provides a slightly different format for the EDI 852, which is why it's important to discuss each trading partner's requirements and capabilities prior to implementing this document. A mapping spec that works for one retailer's 852 won't necessarily transfer to Walmart's without adjustment.
How You Know It's Working
You'll know the feed is production-ready when acknowledgments come back clean on every transmission, store-level activity reconciles against Retail Link reporting without a manual correction step, and replenishment recommendations generate without an analyst pulling numbers by hand. The real test plays out over a full reporting cycle: stockout and overstock variance should visibly shrink once the VMI loop is running on its own.
If building and maintaining this mapping in-house isn't worth the engineering time, managed 852 services are a legitimate alternative, and worth comparing before you commit resources.
| Provider | Approach | Notable strength |
|---|---|---|
| SPS Commerce | Managed mapping plus analytics layer across a large retailer network | Gathers, aggregates, cleanses and analyzes sales and inventory intel from a partner network, with a library of best practice dashboards to act on from day one |
| TrueCommerce | EDI translation with VMI-specific transaction support | Positions the 852 explicitly around Vendor Managed Inventory and Scan-Based Trading approaches |
| Cleo | Integration platform / custom mapping | Flexible for teams building and maintaining their own translator logic |
| DiCentral | VAN and managed EDI services | Long-standing presence among EDI value-added-networks with 852 capabilities |
Whichever path you take, the mapping work described above is the same either way. If you build in-house, use this as your build checklist. If you outsource, use it to ask your vendor sharper questions about how they're handling ZA activity codes, SDQ store splits, and CTT validation before you sign anything.