EDI 867: The Product Transfer and Resale Report
EDI 867 explained: what the Product Transfer and Resale Report tracks, how it differs from EDI 852, and a worked distributor-to-manufacturer example.
EDI 867 is the ANSI X12 transaction set called the Product Transfer and Resale Report. A distributor, wholesaler, or reseller sends it to a manufacturer or supplier to report what happened to product after it left the sender's warehouse: sales to end customers, transfers between locations, and returns.
The EDI 867 Product Transfer and Resale Report is an ANSI X12 transaction used by distributors to report downstream product movement to manufacturers, communicating sales to end customers, inventory transfers between locations, customer returns, and other resale activity occurring after products enter the distribution channel. It's worth sitting with that word "report" for a second. An 867 doesn't order anything and it doesn't bill anyone. No payment obligation rides on it directly. That's a separate document, and we'll get to it.
Why manufacturers need EDI 867 at all
The moment a pallet leaves a manufacturer's dock and lands in a distributor's warehouse, the manufacturer's visibility into that product mostly disappears. The 867 exists to put it back. PartnerLinq lists pharmaceutical distribution, CPG, retail distribution, and military supply chains among the common industries running this transaction, and the use case stretches further than most people assume. Some utilities even use the 867 to transmit allowance transfer information to the US Environmental Protection Agency, which tells you this isn't a retail-only document the way people sometimes assume.
EDI 867 vs EDI 852: the confusion worth clearing up
These two get mixed up constantly because both carry "product activity" data back to a manufacturer. The difference is who sends them and what point in the chain they capture. EDI 852 and 867 are two X12 transaction sets that track product movement at different points in the supply chain: the 852, called the Product Activity Data report, carries point-of-sale and inventory figures from a retailer back to the manufacturer, while the 867 documents business-to-business movement such as distributors shipping to resellers, wholesalers selling to professional end-users, or warehouses transferring stock between locations. Manufacturers that participate in both retail and wholesale channels typically receive both, and read together they show how product is flowing through the network and whether it's actually reaching consumers.
| Attribute | EDI 852 | EDI 867 |
|---|---|---|
| Typical sender | Retailer | Distributor, wholesaler, reseller |
| Typical receiver | Manufacturer | Manufacturer or supplier |
| What it reports | Point-of-sale and on-hand inventory | Sell-through, transfers, returns |
| Where it sits | Retail shelf level | Distribution channel, B2B movement |
| Common pairing | 846, 850 | 844, 845, 849 |
Where 867 fits in the 845/844/849 chargeback chain
This is the part most 867 explainers skip, and it's where the document actually earns its keep in pharma distribution. The chain starts with contract pricing, not with the 867 itself. A manufacturer first negotiates a contract price for pharmaceuticals with a contracting entity such as a GPO or hospital, then notifies distributors of that pricing with an EDI 845 message. The distributor purchases drugs from the manufacturer at wholesale acquisition cost (WAC) and holds them in inventory, and a pharmacy covered under the contract orders at the negotiated price, which the distributor honors.
Here's the gap that gets charged back: the distributor paid WAC but sold at the lower contract price. The distributor notifies the manufacturer of everything sold under contract pricing, typically via EDI 844, requesting payment for the difference between WAC and contract price, the "chargeback," and the manufacturer responds agreeing or rejecting it, usually through an EDI 849. The 867 is the detail layer underneath that claim. Manufacturers must have the ability to process chargeback and rebate claims with standardized EDI 867 chargeback requests or a standard CSV import, which is exactly why Cardinal Health's own distributor policy groups end-user sales reporting under "Transaction Set #867" and pairs it directly with the 844 in its preferred-format table.
Worked example: Cardinal Health's 867-to-844 reconciliation
Cardinal Health's manufacturer reference manual spells out exactly which transactions move and in which direction. Outbound to manufacturers, Cardinal Health sends 820 payment order/remittance advice, 844 chargebacks, 850 purchase orders, and marks both 852 product activity data and 867 product transfer and resale report as optional. That "optional" tag matters: plenty of manufacturers run chargeback reconciliation on 844/849 alone and treat the 867 feed as a bonus sell-through audit trail rather than a hard requirement.
When a manufacturer does take the 867 feed, here's the reconciliation it enables. A given 867 line reports an NDC-level sale with quantity, ship-to, and sale date. The manufacturer matches that line against the corresponding 844 chargeback claim covering the same invoice. If the numbers line up, the chargeback gets paid. If they don't, Cardinal Health's own denial process requires specific fields to isolate the mismatch, including invoice number, invoice line item, the variance amount, the extended chargeback amount, the supplier material number, and an error or reason code from the industry-standard 849 list. Rutgers' 2018 research into this exact process found the most common causes of chargeback rejections were eligibility, pricing, and date issues, which is why the 867's raw sell-through detail matters as a tiebreaker when a 844/849 pair disagrees. Timing is tight, too: distributors should transmit chargeback claims no later than 45 days after the sale, with manufacturers processing them within 30 days of transmission.
What's actually inside an EDI 867 file
Strip away the ISA/GS envelope and the structure is short. The transaction opens with an ST header, then a BPT segment where the Beginning Segment for Product Transfer and Resale Report specifies the purpose and reference numbers for the whole report. One real distributor file from D&H shows the next layer in action: a PTD segment carrying a type code for the transaction, with one sample using the code SD for "Ship and Debit Sale", a label that will be familiar to anyone who's worked pharma or medical-device chargebacks, since "ship and debit" is the industry's own shorthand for this exact contract-pricing mechanism. From there you get LIN segments carrying the product identifier (NDC, UPC, or GTIN depending on the industry), quantity and sale-type detail, and a DTM segment defining the reporting period before the CTT trailer closes it out.
- ST/BPT: transaction header, report purpose, and reference numbers
- N1 loop: identifies the consignor and consignee locations
- PTD/LIN: transfer type code and product identifier
- QTY/SII: quantity sold or transferred, and sale-item indicators
- DTM: the reporting period the data covers
- CTT/SE: line counts and transaction trailer
After receipt, the trading partner fires back an acknowledgment rather than any kind of approval. The EDI 867 can be sent by either the buyer or seller when information on product transfers is desired, and after receiving one, an EDI 997 Functional Acknowledgement is sent back to confirm it arrived successfully. That 997 says nothing about whether the content is correct, only that it parsed.
Where implementation gets messy
The two recurring headaches are product identifier mismatches and ship-to resolution. A distributor's internal SKU rarely matches the manufacturer's NDC or GTIN without a crosswalk table, and a new pharmacy or dispensing account can show up in an 867 before the manufacturer has ever onboarded that ship-to ID anywhere else in its master data. Because the 867 is usually sent from a reseller such as a wholesaler or distributor to a vendor such as a manufacturer, and commonly used to reflect sales and returns tied to rebates, these mapping gaps show up right where the money is calculated, not somewhere harmless. Most teams solve this by routing 867 and 852 feeds through a B2B platform that handles the crosswalk logic rather than hand-coding it per partner, whether that's SPS Commerce, TrueCommerce, Cleo, Commport, or Astera. It's the same aggregation problem, just on the commercial side, that shows up on the execution side of the business: a manufacturer running freight through a dozen carriers has to normalize EDI 214 status updates and 990 tender responses that each carrier formats slightly differently. Platforms like MercuryGate, Descartes, project44, and Cargoson exist to solve that normalization for shipment data the way EDI translators solve it for 867 and 852 feeds, and Cargoson specifically builds direct API/EDI connections with carriers rather than relying only on standardized messages carriers must implement themselves.
FAQ
Is EDI 867 mandatory? Usually not on its own. Cardinal Health, for example, marks it optional in its manufacturer guidebook even though 844 chargebacks are mandatory. Whether you need it comes down to the trading partner agreement.
Who sends EDI 867, the buyer or the seller? It's usually sent from a reseller, such as a wholesaler or distributor, to a vendor, such as a manufacturer, though the spec technically allows either direction if both parties agree.
How is EDI 867 different from EDI 846? The 846 is an inventory inquiry/advice, typically closer to real time and focused on what's currently on hand. The 867 is a periodic report of what already moved, batched daily, weekly, or monthly depending on the agreement.
Does EDI 867 trigger a payment? No. It feeds the numbers that payment transactions rely on, but the actual request for money runs through EDI 844 and the manufacturer's response through EDI 849.
What format does EDI 867 use? ANSI X12 in nearly every case documented here. EDIFACT trading relationships in Europe sometimes use an equivalent message, but the 867 itself is a US/X12 construct.
