What Is EDI 852? The Complete Guide From File to Warehouse

What Is EDI 852? A Plain-English Definition

EDI 852 is the Product Activity Data transaction set published by X12, the body accredited by the American National Standards Institute (ANSI) to maintain North American electronic data interchange (EDI) standards. Put simply, it is a retailer's report card on your products: units sold, units sitting on shelves, units on order, and units that arrived.

A purchase order tells you to ship something. This document asks for nothing. It is purely informational, yet that information is often the closest look a supplier ever gets at actual consumer demand. That is why so many retail trading partners treat it as one of their most valuable feeds.

If a retailer just added the 852 to your onboarding requirements, here is what to expect: a recurring file you need to receive, acknowledge (usually with a 997), and ideally put to work. The subsections below cover who sends it, what it contains, and how it relates to documents you already trade.

Who Sends the EDI 852 and Who Receives It

In retail, the store chain is the sender and the supplier is the receiver. Manufacturers, consumer packaged goods (CPG) brands, and distributors make up most recipients. A third-party logistics provider (3PL) may take in the file for a brand when it manages that brand's inventory or replenishment.

The direction sometimes reverses. A distributor, for example, might send sell-through figures upstream to a manufacturer. For most retail relationships, though, plan on data flowing from retailer to supplier.

What the 852 Reports and How Often

A typical file breaks out the following for each item at each location:

• Units sold at point of sale (POS)
• On-hand inventory
• Quantity on order and not yet received
• Quantity received
• Returns, adjustments, and out-of-stock flags

Products are identified by Universal Product Code (UPC), Global Trade Item Number (GTIN), the retailer's own item number, or your vendor SKU. Mismatches between these identifiers are a common reason data fails to load, so a clean cross-reference table pays off early.

Weekly delivery is the norm, usually covering a Sunday through Saturday retail week. Some retailers move to daily files for fast-moving categories or VMI programs, where the supplier is responsible for keeping shelves stocked.

Where the 852 Fits Among X12 Supply Chain Documents

Think of the order-to-cash cycle as the main road and the 852 as a parallel lane. The 850 purchase order, 855 purchase order acknowledgment, 856 advance ship notice, and 810 invoice move goods and money between partners. Product activity reporting describes what happened after those goods reached the shelf.

That feedback loop is what makes the document central to forecasting and replenishment. Sales and on-hand numbers hint at whether the next 850 will be larger or smaller, and whether your warehouse should build stock ahead of it.

Inside the EDI 852 Document: Segments, Codes, and a Sample File

Every 852 follows the same layered structure. An outer envelope names the sender and receiver. A header sets the reporting period and parties, a detail loop repeats for each item with activity types and quantities by location, and a summary closes the transaction.

EDI coordinators use this structure to validate files and troubleshoot rejections. Demand planners and IT staff use it to decide which fields map to ERP and warehouse system records. Retailers publish implementation guides listing the segments and codes they actually send, so treat what follows as a baseline and confirm details with each partner.

Segment-by-Segment Structure

• ISA/IEA, interchange envelope: sender and receiver IDs, date, and control number.
• GS/GE, functional group: group ID "PD" for product activity, plus the version code.
• ST, transaction set header: identifies the set as an 852.
• XQ, reporting date/action: report type and the start and end dates of the period.
• XPO, preassigned PO numbers: optional, used in some replenishment programs.
• N9, reference identification: vendor number, department, or report ID.
• N1, party identification: supplier, retailer, or reporting location.
• LIN, item identification: UPC, GTIN, retailer item number, or vendor SKU.
• ZA, product activity reporting: the activity code, such as sold, on hand, or on order.
• SDQ, destination quantity: location-by-location quantities for that activity.
• CTT, transaction totals: count of LIN line items.
• SE, transaction set trailer: segment count and control number.

Envelope segments (ISA, GS, and their trailers) wrap the transaction so it can be routed to the right mailbox and translator. Header segments, from ST through N1, appear once per report. The LIN, ZA, and SDQ group repeats for every item, which is why a file for a large chain can run to thousands of lines even when it covers a single week.

Annotated EDI 852 Sample File

This simplified file reports one item across three stores for one week.

ISA*00*          *00*          *ZZ*RETAILERID     *ZZ*SUPPLIERID     *240610*0600*U*00401*000000123*0*P*>~
GS*PD*RETAILERID*SUPPLIERID*20240610*0600*123*X*004010~
ST*852*0001~
XQ*H*20240602*20240608~
N9*IA*12345678~
N1*SU*ACME FOODS*92*12345~
LIN**UP*012345678905*VN*AC-1001~
ZA*QS*84*EA~
SDQ*EA*92*0101*12*0102*30*0103*42~
ZA*QA*310*EA~
SDQ*EA*92*0101*95*0102*110*0103*105~
CTT*1~
SE*11*0001~
GE*1*123~
IEA*1*000000123~

• GS*PD: product activity group, X12 version 004010.
• XQ*H: period runs June 2 through June 8, 2024.
• N9*IA: the retailer's internal vendor number for the supplier.
• LIN: UPC 012345678905, vendor SKU AC-1001.
• ZA*QS with SDQ: 84 sold (12, 30 and 42 at stores 0101, 0102 and 0103).
• ZA*QA with SDQ: 310 available at those stores.
• CTT1 counts one line item; SE11 counts eleven segments from ST to SE.

ZA Activity Code Reference Table

ZA01 tells you what kind of quantity follows. These are the codes you will see most often:

• QA: current inventory on hand and available for sale, covering shelf and backroom stock
• QS: quantity sold, drawn from register scans
• QP: on order but not yet received, meaning open POs to the store or DC
• QR: units received during the period
• QO: out-of-stock count or flag
• QU: units returned by consumers or stores
• QT: inventory adjustment, such as shrink, damage, or cycle count changes
• QI: in transit between a DC and a store

Some retailers add codes for markdowns, forecasts or dollar values, and meanings can vary by implementation.

How SDQ Carries Store and DC Quantities

Most of the document's value lives in SDQ. SDQ01 is the unit of measure and SDQ02 is the location qualifier (92 means a buyer-assigned code, such as a store number). Location and quantity pairs follow, typically up to ten per segment, so a large chain sends many SDQ segments per ZA line. Your system must read every pair, translate each store or distribution center (DC) code into a location record, and reconcile totals against ZA02 when it is present. The same mapping discipline applies to financial documents, covered in our guide to EDI payments.

Version Notes: 004010 vs 005010 and EDIFACT Equivalents

Most retailers still send 852s in X12 version 004010. Some have moved to 005010 or later, which refines elements and code values but keeps the core segment flow. GS08 carries the version, so your translator should route each file to the matching map.

Outside North America, retailers often use EDIFACT, the United Nations EDI standard. The closest equivalents are SLSRPT (sales data report) and INVRPT (inventory report), and global suppliers may need maps for both. If you sell into Europe and North America, expect to maintain two parallel sets of mappings that land in the same internal fields.

EDI 852 vs 846, 867, and 850: Which Document Does What

Suppliers often mix up the 852 with other inventory and sales transactions because the documents share many data elements: item identifiers, quantities, locations, and dates. What separates them is who sends each one, what it describes, and what happens once it arrives.

An 852 describes retail activity after goods reach the retailer's shelves and stockrooms. The 846 tells a trading partner how much stock is available, and it usually comes from the supplier or its 3PL. The 867 records product transfers and resales, a pattern most common in wholesale distribution. The 850 differs from all three because it is a binding purchase order.

Confusing these documents causes real problems. A team might build a map for the wrong transaction set or wait on data that a document was never designed to carry. If you are setting up several of these flows at once, our guide to EDI integration for distributors explains how the pieces fit together.

Comparison Table

• 852, Product Activity Data: sent by the retailer. Covers POS sales, on hand, on order, and receipts by store. Informational, and it feeds planning.
• 846, Inventory Inquiry/Advice: usually comes from the supplier or a 3PL. Reports stock available to ship. Informational, and it supports ordering.
• 867, Product Transfer and Resale Report: typically sent by a distributor. Records resales and transfers to end customers. Supports chargebacks and rebates.
• 850, Purchase Order: sent by the retailer. Lists items, quantities, prices, and ship dates. A binding order you must fulfill.

Here is a simple way to remember the split. The 850 says what to ship, and the 846 says what you are able to ship. The 852 and 867 both describe what became of product after it left your dock.

The 852's Role in VMI, CPFR, Sell-Through, and Pay-by-Scan

The product activity report shows what shoppers actually bought, store by store. That makes it central to several collaborative programs between retailers and suppliers:

• VMI: In a vendor-managed inventory arrangement, the supplier reads on-hand and sales figures from each report and creates replenishment orders for the retailer, instead of waiting for a buyer to place them.
• Collaborative planning, forecasting, and replenishment (CPFR): Both companies exchange forecasts, and the 852 supplies the actuals used to measure how accurate those forecasts were.
• Sell-through analysis: Brands compare units shipped against units sold to spot slow movers, flag stores holding excess stock, and measure promotion lift.
• Pay-by-scan (scan-based trading): The supplier owns the merchandise until it rings up at the register, and reported sales quantities can support settlement between the two parties.

Each program changes what happens inside the supplier's warehouse. VMI and CPFR turn retail sales into outbound orders, so pick volumes begin to follow point-of-sale trends rather than buyer calendars. Pay-by-scan pushes ownership questions down to the store level, which makes accurate shipment records just as important as the incoming sell-through numbers. A warehouse management system connected to these feeds can keep inventory, orders, and planning tied to one consistent set of figures.

How Suppliers and 3PLs Put 852 Data to Work

Receiving an 852 is easy. Acting on it takes a workflow that carries the data from a communication channel into the systems where planners and warehouse teams make decisions. Most organizations stall right here: the file arrives, the EDI team acknowledges it, and the numbers never land in the ERP or WMS in a usable shape. Closing that gap turns a compliance requirement into a planning asset. The four steps below trace one file from start to finish.

Step 1: Receipt Over VAN, AS2, or SFTP

Retailers transmit these reports through one of three channels. A value-added network (VAN) works like a mailbox service sitting between trading partners. Applicability Statement 2 (AS2) is an internet-based protocol that sends files directly, with encryption and signed receipts. Secure File Transfer Protocol (SFTP) drops files onto a shared server. Large retailers usually dictate which channel you use, so confirm it early in onboarding. Whichever channel applies, record the connection details in the partner profile and test a small file before the first production transmission.

Step 2: 997 Acknowledgment and Validation

Within the retailer's required window, your EDI translator should return a 997 functional acknowledgment confirming receipt and successful parsing. Some partners on newer versions ask for a 999 instead. Run validation checks at the same time:

• Segment counts match the value in SE01
• Control numbers are unique
• Dates fall inside the expected reporting period
• Every UPC and store code is recognized

Flag failures before bad records reach downstream systems.

Step 3: SDQ Parsing and Mapping Into ERP/WMS

Next, flatten the file into usable records. Each combination of item, activity code, location, and period becomes one row. Then map:

• LIN UPC or vendor SKU to your ERP item master
• SDQ store or DC codes to customer ship-to or location records
• ZA codes to fields such as sales history, customer on-hand, and open retailer orders

Save every row with the period dates from XQ so weekly files stack into a clean time series. For a closer look at how translated documents feed warehouse systems, see our overview of EDI and warehouse management integration.

Step 4: Forecasting, Replenishment, Slotting, and Demand Planning

Once mapped, edi 852 data supports decisions such as:

• Forecasting: replace shipment history with true point-of-sale demand by store.
• Replenishment triggers: when store inventory plus on-order drops below weeks-of-supply targets, generate VMI orders or alert account teams.
• Out-of-stock prevention: flag locations showing sales but zero on-hand.
• Slotting: move fast sellers closer to pick faces before the demand reaches your DC.
• Demand planning: measure promotion lift and regional trends.

Picture a few hypothetical cases. A CPG supplier selling to Walmart sees sell-through climb in Southeast stores ahead of a heat wave and pre-builds inventory. A Target vendor spots stores where shelf stock is falling while on-order sits at zero. A Home Depot supplier lines up seasonal staging with weekly sales curves from individual stores. In each case, the value comes from getting retail signals onto the warehouse floor quickly enough to act, which depends on how directly the translated data reaches the systems that run picking and replenishment.

Common EDI 852 Implementation Challenges and How to Solve Them

No two retailers send identical EDI 852 files. Even a single retailer's feed shifts over time as programs, store counts, and item lists evolve. The problems below appear in implementation after implementation, and each one has a practical fix. Building these controls in from day one costs far less than cleaning up months of distorted forecasts later.

Retailer-Specific Requirements and Cadence

One retailer transmits weekly files with five ZA codes. Another sends daily files with only two. A third changes cadence during peak season with little warning. The fix is a partner profile for every account that records the X12 version, transmission cadence, ZA codes in use, and location qualifiers. Before data reaches planning tools, normalize daily and weekly feeds to a common retail calendar (a 4-5-4 fiscal calendar, for example) so no period gets counted twice.

UPC/SKU Mismatches and Missing Stores

Incoming files often reference UPCs that do not match your item master. Packaging changes, case versus each codes, and retailer-assigned numbers are the usual culprits. Store lists drift too, as locations open, close, or get renumbered. Keep a cross-reference table that links UPC, GTIN, retailer item number, and vendor SKU. Route unrecognized items and stores to an exception queue rather than dropping them, since discarded lines quietly understate sell-through. Compare store counts week over week and set an alert when a meaningful share of locations disappears from the feed.

Restated Files, Data Volume, and Validation Errors

Retailers sometimes resend a corrected report for an earlier period. If your process appends instead of replacing, history inflates and forecasts drift upward. Key each record on item, location, activity code, and period, then overwrite whenever a restatement arrives.

Volume is a separate concern. A national chain's file can hold millions of SDQ quantity pairs, so process large files in batches and archive every raw transmission for audit. When validation fails, log the exact segment and element that broke. That detail lets EDI staff resolve the issue with the partner in one exchange instead of several.

Trading Partner Testing Best Practices

Before going live, work through these steps:

• Obtain the retailer's current implementation guide and sample files.
• Confirm the communication channel, sender and receiver IDs, and 997 acknowledgment timing.
• Test files that include every ZA code and a complete store list.
• Reconcile ZA totals against summed SDQ quantities.
• Verify item and location mapping against ERP master data.
• Send a restated test file to confirm overwrite logic works.
• Run in parallel for two or three cycles before relying on the numbers.

The same discipline applies when you onboard other transaction sets alongside sell-through reporting. Our guide to the EDI 866 production sequence document covers a different flow, but the partner profiles, mapping checks, and parallel runs described here carry over directly.

Next Steps: Turning 852 Data Into Inventory and Warehouse Decisions

An 852 feed gives suppliers, distributors, and 3PLs something rare: a direct view of what shoppers actually buy and what is still sitting on retail shelves. That view is only worth as much as the speed at which it reaches a decision. When EDI processing feeds straight into ERP and warehouse workflows, a planner can respond to a demand shift within hours of the retailer's file arriving. When the same information passes through spreadsheet exports and email attachments, the response can trail the shelf by weeks. By then the stockout or overstock has already happened.

Before scoping an implementation, walk through each step your data takes today: receipt, translation, mapping to item records, review by planners, and the replenishment order that follows. Note where a person has to copy, reformat, or wait on someone else. Those handoffs are usually where retail activity data loses its value.

Quick Answers Before You Start

• Who sends it? The retailer transmits the 852 to the supplier, not the other way around.
• How often? Weekly files are the most common. Some programs send daily data, which suits fast-moving or promotional items.
• Is it required? That depends on the retailer and the program. VMI and pay-by-scan arrangements typically make it mandatory, while standard replenishment relationships may treat it as optional.
• Can a supplier request it? Often, yes. Many retailers share sell-through reporting on request, particularly with vendors in collaborative programs. Your buyer or EDI onboarding contact is the right person to ask.
• What should you check internally? Confirm that retailer item numbers, UPCs, and your own SKUs map cleanly to one another, and that someone owns the review of each weekly file.

How a WMS Connects 852 Data to Warehouse Workflows

A warehouse management system that receives translated EDI documents can place sell-through and on-hand reporting in the same environment as item records, locations, and stock levels. When that happens, store-level sales and inventory quantities can inform replenishment, slotting, and production planning without anyone re-keying numbers.

Consider a hypothetical example. A supplier sees sell-through on a seasonal item jump at 40 stores in one region. If the 852 figures sit alongside warehouse inventory, the team can check available stock, move that item to a faster pick location, and build replenishment orders for the affected distribution centers in one session. Without that connection, the signal might sit in an inbox until the next planning meeting.

When you evaluate a platform for this work, ask practical questions:

• Can it accept 852 output from your EDI translator on the cadence each retailer uses?
• Can it hold retailer store codes and tie them to ship-to or location records?
• Does it overwrite a prior period cleanly when a corrected file comes in?
• Can planners see customer on-hand next to your own DC stock without exporting to a spreadsheet?
• Who on your team will own exceptions such as unknown UPCs or missing stores?

If your team already receives these files but struggles to act on them, or a new retailer requirement is on the way, Request a Call to discuss your current setup with Comparatio.

Frequently Asked Questions