Why your ERP still can't tell you who has your kegs

Because standard ERP was built to move product and book revenue, not to track an asset that leaves your dock full, comes back empty, and belongs to you throughout. A keg is a returnable container carrying a deposit liability, but in most SAP landscapes it survives as a bolt-on: an empties-update flag in billing, a retrieval bill of materials, a deposit line item. None of that adds up to a per-outlet ledger of who is holding your steel.

Where does an ERP actually put a keg?

Follow one keg through a typical SAP configuration and you find it scattered across three places, none of them an asset register. The full keg moves as a saleable material. The empty is handled through the empties-update logic in SD billing, which nets returnable containers against deliveries. The container itself is modelled as a retrieval bill of materials, with tied or untied deposit items attached so the deposit posts correctly, and brewers lean on the EA-CP industry extension to carry the empties and deposit semantics the core was never designed for. Configuration guides and community write-ups covering this pattern have circulated since the mid-2010s, and the shape has barely changed.

Each piece works in isolation. Together they describe how a keg gets billed, not where it physically is. The empties-update flag knows a container was expected back on an invoice; it does not know that one outlet has been sitting on twelve of them since March. The deposit line knows money changed hands; it cannot give you the deposit balance for a single account without a report that stitches years of documents together. The ERP has a general ledger for deposits and no subledger for kegs.

Why doesn't the money force a reconciliation?

Because the deposit is too small to hurt anyone. A keg deposit in the trade typically runs around $30 as of April 2026, against a replacement cost of $100 to $150 per keg, so the deposit covers only 15 to 20 percent of what the steel is worth. When a keg goes missing, the brewer eats the gap, the outlet forfeits a deposit it stopped noticing years ago, and neither side has enough on the line to spend an afternoon reconciling. The economics are built for nobody to care until year-end.

At industry scale that indifference is expensive. US brewers lose roughly 400,000 kegs a year, up to $35 million on 2019 figures, and keg shrinkage works out to somewhere between $0.46 and $1.37 per barrel produced. Those are not rounding errors on a fleet that ties up real capital in stainless steel. But the loss is smeared thinly across thousands of outlets and hundreds of thousands of turns, so it never lands on one desk as a number large enough to fund a fix.

Why can't the order-capture front end pick up the slack?

You might expect the modern order-capture layer to close the gap, since that is where the outlet relationship actually lives. It doesn't, because the commerce platforms brewers deploy on top of the ERP have no native concept of a negative-quantity 'return empties' line, and no native per-outlet container account. SAP Commerce and Salesforce B2B model a cart as things you buy, not things you owe back. Every returnables flow you see in those systems was bolted on for a specific project: a custom line-item type here, a custom account object there, a nightly job to reconcile against the ERP deposit postings. It works until the integration owner leaves.

The result is that the people closest to the containers are the worst-instrumented. Your distributors often know the real state of your fleet better than you do, the same fragmentation that shows up whenever outlet-level truth lives in someone else's system. The one channel that touches the outlet on every order is structurally blind to the container that order should have carried back.

So who actually knows who has your kegs?

The truck does, briefly, and then forgets. The driver who drops six full and lifts four empties holds, for about thirty seconds, the most accurate container count in the company, and unless the route app captures it as a first-class movement, that count evaporates when the door rolls down. It is the returnables version of how perfect-store programmes die in the last mile of data: the event happens, the record doesn't. We have argued separately that the delivery that arrives full and leaves empty-handed is exactly where the returnables ledger is won or lost.

What fills the vacuum is a spreadsheet. Ask most brewers for deposit liability by outlet and you get a workbook maintained by one person in finance or logistics, reconciled quarterly against ERP deposit totals, trusted by nobody and corrected by everybody. Here is what each layer can and cannot tell you:

None of these is the asset ledger the fleet needs, and no amount of ERP configuration turns a billing construct into one. The container is treated as a side effect of selling beer rather than as an object with its own identity, location and owner.

The fix direction is not a better empties-update flag; it is a per-outlet container account that exists as a first-class object, updated by every physical movement — dispatch, delivery, pickup, return — as events rather than reconciled after the fact. That is the shape we build returnables on when we put container movements on the same event bus as orders and stock, so the ledger becomes a live projection of what the trucks actually did rather than a quarterly apology. The brewers who get there first will stop asking who has their kegs and start asking why anyone ever kept the answer in a workbook.