Beer route-to-market

Your distributors know your customers better than you do

TL;DRYou sell to distributors, so your systems capture sell-in — what you shipped — while their distributor management systems capture sell-out: which outlets actually bought. That data rarely flows back because DMS platforms are fragmented, sell-out is the distributor's leverage, and ERPs record documents, not demand. Closing the gap needs sell-in and sell-out on one event bus.

You sell to distributors, so your data stops at their loading dock. Everything past it — which bar reordered, which SKU stalled, which outlet quietly churned — lives in the distributor's system, not yours. Sell-in tells you what you shipped. Sell-out tells you what the market actually wanted, and your distributors own that record. The asymmetry is not a data-quality bug. It is the shape of the trade you built.

Why does your data stop at the distributor's loading dock?

Sell-in is the invoice you raise when a truck leaves your yard for a wholesaler. Sell-out is the transaction when that wholesaler's van drops a case at an outlet, or when the outlet pulls the pint. Your ERP records the first event with precision, because it is a financial system and sell-in is where revenue is recognised. The second event happens two or three handoffs downstream, inside someone else's software, and it never comes back.

 Sell-inSell-out
The eventStock leaves your warehouse for a distributorAn outlet buys from that distributor; a drinker buys from the outlet
Recorded inYour ERPThe distributor management system
Tells youWhat you shippedWhat the market actually wanted
Your visibilityPrecise, near real-timeAggregated, late, or absent

In markets run by the fragmented trade — the millions of independent bars, kiosks and family-run shops that McKinsey sizes at more than $2.8 trillion worldwide — that downstream event is most of your volume. You end up planning demand against a proxy: distributor purchase orders, shaped as much by their working capital and shelf space as by real consumer pull. When a wholesaler over-orders ahead of a price rise and then draws the stock down for two months, your sell-in curve lies to you twice — once on the way up, once on the way down.

Why is the distributor's system your real customer database?

A distributor management system is not a warehouse tool. It is a CRM you have no login for. It holds the outlet master: who orders, how often, at what price, on what credit terms, with what payment behaviour, and what they stopped buying last quarter. The rep who walks the outlet logs the relationship there. The van-sales settlement reconciles there. The promotion redemption, where one exists, lands there.

To you, that same outlet is at best a line buried inside an aggregated distributor order, and at worst invisible. You know a territory bought four thousand hectolitres. You do not know that ninety outlets in it churned to a competitor's lager while the total held flat, because thirty others grew. Averages are where outlet-level signal goes to die. It is the same blindness we described in why your ERP still can't tell you who has your kegs: the transactional core records the shipment, not the state of the asset or the customer at the far end of it.

Why doesn't sell-out flow back to you?

Three structural reasons, none of them accidental.

Heterogeneity. There is no single distributor system. A large brewer's third-party distributors run dozens of different DMS products, home-grown databases and paper. There is no shared schema for outlet, SKU or visit, so even a willing distributor cannot hand you clean sell-out without a bespoke integration per partner. And where the outlet itself is offline — much of the fragmented trade is — the sell-out is never captured digitally at all. We got into that constraint in if the app needs 4G, the fragmented trade doesn't have it.

Incentives. Sell-out data is the distributor's leverage. It is a large part of why you need them. Handing it over in clean, outlet-level form weakens their position in the next margin conversation, so the rational distributor shares aggregates, late, and only what the contract compels.

Architecture. Brewers who fix the first two still collide with the third. The ERP is a financial transactional core; it wants documents — orders, invoices, deliveries — not a live picture of demand. The scale of that mess is rarely admitted out loud, so it is worth citing a case that was: the CEO of a top-three global brewer told investors in 2025 that the company was running 43 different ERPs with unharmonised processes and data, and framed the goal not as another ordering app but as closing the loop:

how we're generating eB2B and linking it back to our distributor information system... back to our ERP transactional core

The hard part is the repetition of back. Generating eB2B orders is the easy quarter. Linking those orders to the distributor's system, and both of those to a financial core that was never designed to hold outlet-level demand, is the multi-year part. It is also why a straightforward-sounding promotion can take two quarters to ship: the data to target it and the plumbing to measure it sit in different systems, owned by different companies.

Is the gap actually closeable?

It is, and the proof is public. The world's largest brewer built its own eB2B platform and then pushed it toward sell-out with a scheme it documents as B2O — connecting a sell-in order to consumer-level redemption through traceable, points-backed digital coupons. Its December 2021 investor materials report issuing more than two million coupons to over one million unique consumers and an 84% coupon conversion rate on one such programme. Strip the marketing and the load-bearing claim is architectural: they made a single event — a coupon redeemed at an outlet — visible on both sides of the distributor boundary. That is sell-out, captured, and tied back to the sell-in that seeded it.

You do not close this gap by demanding better spreadsheets from your distributors. You close it by treating sell-in and sell-out as events on one bus, so that an order, a delivery, a redemption and a returnable pickup from the same outlet share a single identity — which is the whole reason we run these flows on a common event architecture rather than a stack of apps that each hold a different quarter of the truth.

Brewers who treat this as a reporting problem will keep buying dashboards that average away the only signal that matters. The ones who treat it as an identity problem — one outlet, one thread, sell-in and sell-out on the same bus — will spend the next few years learning, at last, what their distributors have always known. The point is not that you can finally see the outlet. It is that you can act on it before the distributor decides whether to tell you.

Frequently asked questions

What is the difference between sell-in and sell-out data?

Sell-in is what you invoice to distributors when stock leaves your warehouse. Sell-out is what those distributors actually sell to individual outlets and consumers. Sell-in drives revenue recognition in your ERP; sell-out reflects real demand. Most brewers see sell-in clearly and sell-out barely, because sell-out lives in the distributor's system.

Why don't distributors share outlet-level sell-out data with brewers?

Three reasons: their systems are fragmented with no shared schema, so integration is costly; many outlets are offline, so sell-out is never captured digitally; and outlet-level data is the distributor's commercial leverage. The rational distributor shares aggregates, late, and only what the contract forces.

Can a brewer get outlet-level demand without owning the distributor's system?

Yes, but not by demanding spreadsheets. You capture sell-out at the touchpoints you control — eB2B orders, deliveries, coupon redemptions, returnable pickups — and give each outlet one identity across them. Put sell-in and sell-out on a common event bus and the outlet-level picture emerges without owning every distributor system.

Stuck with exactly this?

BrewOS builds the full route-to-market stack for global brewers — order capture, stock, loyalty, returnables, delivery and analytics on one event bus, run by a team of ~20 engineers. Bring us the feature that’s been stuck the longest and we’ll show you how we’d ship it in days.

Book a 30-minute walkthrough