The EDI 852, Decoded: Product Activity Is How a Retailer Tells You What Actually Sold

An 852 · Product Activity Data transaction is the retailer's report of what actually happened to your product in their stores and warehouses: what sold, what is still on hand, what is on order, and what moved between locations — item by item and location by location. It is not an order and it is not a payment. It is the demand signal that should drive both.

I run SignalEDI. This series has walked the retail order-to-cash chain in order: the 850 · Purchase Order that starts it, the 855 · Purchase Order Acknowledgment that promises it, the 856 · Ship Notice / ASN that ships it, the 810 · Invoice that bills it, and the 846 · Inventory Inquiry/Advice that tells a buyer what you can sell. Today's document runs in the opposite direction. The 846 is you telling the retailer what you have. The 852 is the retailer telling you what they did with it.

What is an 852 · Product Activity Data transaction, and why does it matter?

The 852 answers a question a purchase order never can: is the product moving? A supplier can ship every order on time, in full, and still be losing the account — because the product is sitting unsold in the wrong stores while it stocks out in the right ones, and the next order is being written from a forecast instead of from sell-through.

Retailers send 852 data on a cadence, commonly weekly, sometimes daily for high-velocity items. Each file reports activity for a period: quantities sold, quantities on hand, quantities on order, and sometimes returns, transfers, and receipts — broken out by item and by store or distribution center. That granularity is the point. A national total that says "you sold 10,000 units" hides everything actionable. A location-level file that says "these 40 stores sold out on Tuesday and these 60 have six weeks of cover" tells a supplier exactly where the next problem, and the next order, will come from.

How is an 852 actually structured?

At the top, the 852 identifies the reporting party, the supplier, the reporting period, and the activity being reported. Then it repeats, location by location and item by item. Each detail loop carries the product identifiers as the retailer knows them — typically the GTIN/UPC and often the buyer's own item number — the location, and a set of quantity-and-activity pairs: this many sold, this many on hand, this many on order, each qualified by a code that says what kind of activity the number describes.

That qualifier is the language of the document, and misreading it is the classic 852 error. The same item, at the same store, in the same file, will appear with several different numbers that are all correct — units sold is not units on hand, and neither is units on order. A mapping that collapses those qualified quantities into a single "quantity" field produces a confident, precise, and completely wrong picture of demand. The first implementation discipline with the 852 is therefore boring and essential: preserve the activity qualifier all the way into your reporting, never just the number.

A second structural fact matters just as much: the retailer's identifiers and calendar are the retailer's. Their item numbers, their location numbers, their fiscal week. An 852 you cannot cross-reference to your own SKUs, your own warehouses, and your own planning calendar is data you received but cannot use — which, operationally, is the same as not receiving it.

Why do suppliers who receive 852 data still plan from forecasts?

Because receiving a file and running a business on it are different projects, and the second one is where most 852 programs quietly die. The file arrives, someone opens it during onboarding to confirm it parses, and then it is archived — while replenishment, production, and allocation decisions keep being made from the last purchase order and a spreadsheet forecast.

The cost shows up in two familiar places. The first is the stockout nobody saw coming: sell-through accelerated in a region, on-hand fell for three reporting cycles in a row, and the signal sat unread until the retailer wrote an emergency order the supplier could not fill — followed, sometimes, by a compliance conversation about fill rates that the supplier's own inbox had predicted a month earlier. The second is the opposite: overproduction and over-shipment into locations already carrying heavy cover, tying up working capital in inventory that will eventually return or be marked down.

Used properly, the 852 changes the conversation with the buyer as well. A supplier who can say "sell-through is up 30 percent in the Southeast, cover there is under two weeks, and here is what we propose shipping" is not reacting to orders — they are collaborating on replenishment. That is a different, and much stickier, kind of account relationship.

Where do 852 workflows usually break?

The first break is cadence without ownership. A weekly file that no named person or system is responsible for reviewing within a defined window will be reviewed eventually, which means never. The value of activity data decays fast; last month's stockout signal is history, not a decision.

The second break is treating the 852 as a report instead of data — the same failure this series flagged for the 835 · Healthcare Benefit Payment / Remittance Advice in healthcare. Teams that eyeball a summary and file the raw transaction lose the trending that makes the document powerful: sell-through by location over time, cover weeks by item, and the early drift that precedes both stockouts and excess.

The third break is never reconciling the 852 against your own documents. Activity data should tie, loosely but recognizably, to what you shipped on the 856 and invoiced on the 810, adjusted for what the retailer already had. When reported on-hand jumps in a way no shipment explains, that is not a curiosity to ignore — it is a receiving error, a returns flow you have not accounted for, or a mapping error in the file itself, and it will corrupt every plan built on top of it until someone investigates.

Frequently asked questions

Is an 852 · Product Activity Data transaction the same as an 846 · Inventory Inquiry/Advice?
No — they run in opposite directions. The 846 is the supplier telling a buyer what inventory the supplier has available. The 852 is the retailer telling the supplier what happened to the supplier's product at retail: sales, on-hand, and on-order quantities by item and location.

Does an 852 create an order or an obligation to ship?
No. The 852 is reporting, not ordering. It informs replenishment and planning decisions, but the binding commitment still arrives as an 850 · Purchase Order (or under a vendor-managed or continuous-replenishment agreement the parties have separately made).

How often do retailers send 852 data?
Weekly is the most common cadence, with daily reporting for fast-moving items and some promotional periods. The exact cadence, locations covered, and activity types included are set by each retailer's implementation guide, so two partners' 852 files will rarely look identical.

Each EDI document in this series answers exactly one question well. The 852's question is "here is what actually sold, here is what is left, and here, location by location, is where your product is winning or stuck." Reading it on cadence, preserving its activity qualifiers, and planning from sell-through instead of habit is the discipline we build SignalEDI around.

— Chris, founder of SignalEDI