The EDI 852 product activity data report is how a retailer tells you what sold, what is on hand and what was received, usually by store. It is the input to replenishment and the earliest warning you get on a slow seller.
Most brands find out how a season went from a reorder that never comes. The 852 product activity data report is the retailer telling you what sold, what is sitting on the floor and what was received, often store by store, weeks before the buyer calls. It is the most commercially useful document in retail EDI and the one most often left unprocessed.
The EDI 852 is the transaction set a retailer sends to a supplier reporting what happened to that supplier's products: units sold, units on hand, units received, and often units damaged or returned. Depending on the program it reports at the chain level, at the distribution center, or store by store.
It is the only document in the standard order cycle that flows purely for the supplier's benefit. The 850 tells you what to make, the 856 tells them what is coming, the 810 asks for money. The 852 tells you whether any of it worked.
Two programs depend on it entirely. Vendor managed inventory cannot function without it, because you are being asked to decide the retailer's buy and the 852 is your only view of their shelf. Replenishment programs use it to trigger reorders. Outside those, plenty of retailers send an 852 to suppliers who never open it, which is a strange thing to leave on the table given what it costs to obtain any other sell through data.
Each ZA segment pairs a qualifier with a number. The qualifier is what turns a figure into a fact.
| QS | Quantity sold. The headline number, and the one replenishment logic runs on. |
| QP | Quantity on hand. What is physically sitting in the location being reported. |
| QR | Quantity received. Useful for confirming a shipment actually landed where the ASN said it would. |
| QA | Quantity on order. What the retailer has coming from you that has not yet arrived. |
| QC | Quantity committed. Allocated but not yet shipped or sold. |
| QD | Quantity damaged. Small numbers that matter, because a pattern here is a packaging problem. |
| QW | Quantity withdrawn, typically from a distribution center to stores. |
A simplified weekly activity report for one item across three stores.
ST*852*0001 / XQ*W*20260803*20260809 / XPO*4500098765 / LIN**UP*012345678905 / ZA*QS*41*EA / ZA*QP*186*EA / ZA*QR*240*EA / SDQ*EA*92*0142*14*0187*19*0203*8 / CTT*1 / SE*10*0001| XQ | Reporting period. A code for the type of report and the date range it covers. This is what tells you whether you are looking at a week, a day or a period to date. |
| XPO | Optional purchase order reference, tying activity back to a specific order where the retailer tracks it that way. |
| LIN | Item identification, normally a UPC or GTIN. One per product being reported. |
| ZA | Product activity reporting. A qualifier and a quantity. Several per item is normal. |
| SDQ | Destination quantity. The store level breakdown: unit of measure, a location qualifier, then repeating pairs of store number and quantity. This is where a chain number becomes an actionable one. |
| CTT | Transaction totals, a control check on line count. |
| SE | Closes the transaction set with a segment count. |
The SDQ segment is the part worth building for. A chain wide figure of 41 units sold tells you the style is slow. The same 41 units split 14, 19 and 8 across three stores, against on hand positions you can also see, often tells you it is not slow at all, it is misallocated. Those are different problems with different answers, and only one of them is solved by a markdown.
Weeks of cover, calculated from sold and on hand, tells you when a door is going to run out. Proposing the reorder is a better position than waiting to be asked, and on a vendor managed program it is the job.
Store level detail separates a slow style from a badly distributed one. If three doors are sold out and twelve are sitting, that is a transfer conversation, not a markdown conversation, and you have to be looking at SDQ to see it.
Quantity received tells you what the retailer booked in. Comparing it to what your 856 declared is one of the cheapest ways to find a shortage claim before it becomes a deduction.
Sell through by week feeds size curve and colour decisions for the next buy far better than a shipped total does. Shipped tells you what a buyer believed. Sold tells you what a shopper did.
AIMS360 imports the 852 and matches activity back to your own style, colour and size records rather than leaving it as a file of UPCs. Sold and on hand land against the same product master that holds your available to sell position, so the retailer's shelf and your warehouse are visible in one place.
SDQ detail is preserved rather than collapsed to a chain total, so allocation analysis is possible.
On vendor managed programs the sell through you receive and the 846 availability you publish run off one record.
Quantity received reconciles against the ASN and invoice already on the order, which surfaces shortages early.
852 files are large and frequent. AIMS360 charges no per document or per kilocharacter fees of its own.
It is the product activity data report a retailer sends to a supplier, covering units sold, on hand, received and sometimes damaged or returned, often broken out by store. Suppliers use it to trigger replenishment, spot allocation problems, confirm receipts against their ship notices and plan the next buy on real demand rather than on what was shipped.
Direction and subject. The 846 goes from supplier to retailer and reports what you have available to sell. The 852 goes from retailer to supplier and reports what happened to product they already hold. On a vendor managed inventory program you normally run both: the 852 tells you what moved off their shelf, the 846 tells them what you can replace it with.
Weekly is the most common cadence, usually covering the retail week just closed. Daily happens on high velocity or vendor managed programs. Some retailers send period to date rather than period activity, which matters enormously when you build the logic: adding up a series of to date reports double counts everything. The XQ segment tells you which you are looking at, so read it rather than assuming.
They are quantity qualifiers in the ZA segment. QS is quantity sold and QP is quantity on hand. Those two together are the practical minimum for anything useful, because sold without on hand shows movement but not cover, and you will end up reordering into a location that is already full. Other common qualifiers include QR received, QA on order, QC committed, QD damaged and QW withdrawn.
It can, through the SDQ segment, which carries repeating pairs of store number and quantity. Whether you actually get it depends on the retailer and the program. Chain level only is common. If you can get SDQ, build for it, because it is the difference between knowing a style is slow and knowing it is misallocated, and those have different answers.
Rarely required in the sense that an 856 or 810 is required, because it flows toward you rather than toward the retailer. It becomes effectively mandatory on vendor managed inventory and replenishment programs, where the retailer is relying on you to make the buying decision. Outside those, many retailers will send it if you ask and set it up, and plenty of suppliers never do.
Last reviewed 7 August 2026 by the AIMS360 EDI team. Segment and qualifier detail reflects the ANSI ASC X12 852 transaction set. Which qualifiers a retailer sends, the reporting cadence and whether store level SDQ detail is included are program decisions that vary by account and can change.
A 30 minute demo on your own accounts, with store level activity mapped to your product master.
