EDI 846 Inventory Inquiry/Advice, Explained

What is EDI 846?

EDI 846 (Inventory Inquiry/Advice) is an ANSI X12 transaction set used to exchange inventory levels, availability, and restock timing between trading partners. It travels in both directions: a retailer can send it as an inquiry asking what's on hand, or a supplier can send it as an advice, pushing stock numbers out without being asked.

The EDI 846 Inventory Inquiry / Advice is a bidirectional inventory communication - it can be sent either as an inquiry (a buyer asking "what do you have in stock?") or as an advice (a supplier proactively broadcasting their current inventory levels). In practice you'll see the advice pattern far more often than the inquiry pattern, because most large retailers have simply told their suppliers "send us this on a schedule" rather than pinging for it document by document.

If you work outside the ANSI X12 world, the concept isn't unique to North America. In EDIFACT, comparable messages include INVRPT, the inventory report, and RECADV, the receiving advice message. Automotive suppliers running VDA will recognize VDA 4990 Global Inventory Report as the same idea under a different standard.

EDI 846 vs 852 vs 856: three transactions people mix up

846 tells you what's available right now. 852 tells you what moved. 856 tells you what already shipped. They get confused constantly during trading partner onboarding because all three touch "inventory" in some sense, but they answer completely different questions.

EDI 846 communicates current inventory levels (what's in stock), while EDI 852 reports sales and movement data (what sold). An 852 is historical: receipts, shipments, cycle counts, POS sales for a defined period. An 846 is a snapshot: this many units, at this location, as of this timestamp. The 856 (Advance Ship Notice) is neither of those. It's the document that says a specific shipment, with specific cartons and tracking numbers, has left the building. If your 846 says "500 units available" and your 856 for the same SKU hasn't gone out yet, that's expected. If your 856 shows units shipped that your last 846 never reported as in stock, you've got a mapping problem somewhere upstream.

None of this is purely a legacy EDI conversation anymore. Retailers typically require suppliers to send 846 updates at least daily; for fast-moving items, some programs require feeds every 4 hours or via near-real-time API integration. That's the hybrid reality most EDI teams are living in right now: batch 846 files for the long tail of partners, and an API feed for the two or three retailers who won't accept anything slower than near-real-time.

Why EDI 846 exists: drop-ship, VMI, and multi-location visibility

The message is mandatory in some industries such as vendor-managed inventory and retail drop shipping, and it is widely used in other industries as well. Without it, a retailer selling a supplier's stock on its own storefront has no way to know when to stop showing "In Stock."

It's not only external. Multi-location businesses also use 846 internally between warehouses. A distribution center checking a sister facility's stock before placing a new purchase order avoids a duplicate buy that shows up as excess inventory two months later.

The VMI loop is where 846 does its most interesting work. In VMI programs, the supplier receives point-of-sale or warehouse consumption data (often via an 852 Product Activity Data) and uses it to manage the buyer's inventory levels automatically. The 846 closes the loop, with the supplier sending inventory advices so the buyer can confirm the VMI replenishment is keeping shelves stocked. Without the 846 half of that loop, the buyer is trusting the supplier's replenishment logic blind. With it, they can audit it.

A worked example: supplier feeding Amazon and a big-box retailer

Picture a housewares supplier running dropship for Amazon alongside a standing account with a traditional big-box retailer. The two partners don't want the same thing, and that's the whole point of this example.

Amazon and major e-commerce retailers often require hourly 846 updates for dropship inventory, and Amazon typically requires multiple 846 updates daily with specific data elements for many of its supplier programs. The big-box retailer, running a slower-moving traditional supply chain, might be fine with once a day. Same transaction set, wildly different cadence, because the business risk is different: Amazon's storefront can sell a phantom unit within minutes of going out of stock, while a big-box DC has buffer stock and longer replenishment cycles absorbing the lag.

Here's what happens when the supplier's warehouse actually hits zero on a SKU. If a retailer's eCommerce platform shows an item as "In Stock" but the supplier's 846 indicates 0 available, customers get a bad experience (order placed, then cancelled). That cancelled order isn't just a customer service problem. It's a chargeback risk, a metric hit on the marketplace seller scorecard, and exactly the failure mode 846 exists to prevent.

Structurally, the transaction is simpler than people expect. A few core segments carry almost all the useful information:

Once that 846 lands and shows the SKU below reorder point, it should trigger a purchase order or an automatic replenishment shipment on the supplier side. That's where inventory data hands off to execution: tender the load, pick a carrier, generate tracking. Platforms like MercuryGate, Descartes, and Transporeon handle that on the enterprise freight side, while smaller multi-carrier tools such as ShipStation, Sendcloud, and Cargoson pick up the replenishment order and route it to a carrier without a planner touching a spreadsheet. The 846 doesn't move the box, but it's usually the signal that starts the clock.

Common implementation pitfalls

• Agreeing to a frequency that doesn't match reality. A partner who asked for daily 846s and gets weekly ones will oversell fast-moving SKUs and blame the supplier's data, not the schedule.
• Mapping inquiry and advice modes incorrectly in the translator, so an unsolicited advice gets processed as though it were a response to a request nobody sent.
• Treating the 846 as ground truth when the underlying WMS or ERP feed generating it is stale. An 846 built from a nightly batch export is only as fresh as that export, no matter how often you transmit it.
• Skipping validation on the QTY qualifiers, so "on hand" and "available to sell" get flattened into one number and the buyer overcommits against allocated stock.

Data quality problems upstream of the 846 don't show up as EDI errors. They show up as clean, well-formed transactions carrying wrong numbers, which is a harder bug to catch in testing.

FAQ

Is EDI 846 required or optional?

It's not required by any regulation, but it's mandatory in some industries such as vendor-managed inventory and retail drop shipping, meaning your specific trading partner agreement is what makes it non-negotiable.

Who sends the EDI 846, the buyer or the seller?

Either one, depending on setup. EDI 846 is bidirectional. Both buyers and sellers can send it. Suppliers typically send 846 to retailers providing inventory updates, and retailers may send 846 inquiries requesting current stock information.

How often should EDI 846 be sent?

There's no universal answer. Retailers typically require suppliers to send 846 updates at least daily; for fast-moving items, some programs require feeds every 4 hours or via near-real-time API integration, so check the trading partner's implementation guide rather than assuming.

What's the EDIFACT equivalent of EDI 846?

In EDIFACT, comparable messages include INVRPT, the inventory report, and RECADV, the receiving advice message.

Does EDI 846 replace real-time API inventory feeds?

No. Large retailers increasingly run 846 batch feeds for most of their supplier base alongside API connections for the partners who need sub-hourly accuracy, which is the same hybrid pattern showing up across most EDI transaction sets right now, not just this one.