Empties in SAP: bring your own Z-tables

SAP will not manage beverage empties for you out of the box. Standard empties handling is built around returnable packaging tied to material and bill-of-materials logic, not the one-way deposits, mixed loads and route-level balances of real distribution. So beverage teams end up in the Z-namespace: custom tables for deposit balances, custom reports, printed balance confirmations, and a partner add-on for excise. The gap is structural, not a configuration oversight.

What does standard SAP give you for empties?

Standard empties functionality models returnable packaging — a crate, a keg, a returnable bottle — as a material linked through a bill of materials to the product it carries. Move the full goods out, the empty comes back, and the packaging nets off against the delivery. It is a clean model when the container is an asset that cycles, and it works well for a closed keg fleet. SAP community guidance is blunt, though, that the standard was built for returnable packaging rather than one-way deposits. The moment a market mixes returnable and one-way deposit SKUs — which every beverage market does — the model stops describing reality.

Why does beverage reality break the model?

Two things break it: deposits and routes.

A one-way deposit is a liability, not a packaging offset. It is cash the brewer or wholesaler holds against a container that may never return through the same channel, and it has to be carried as a balance owed — per customer, per SKU, per deposit class, and often at more than one deposit rate in the same market. Standard empties logic has no native place to hold that ledger, because it assumes the container is an asset cycling back, not money parked against packaging that walked out the door.

Routes break the master data. Direct store delivery is how most beer reaches trade, and SAP's DSD practice expects a bill of materials, empties handling and a single sales area for each route — or you do custom development. One route mapped to one sales area is tidy on a slide and expensive in a live org with hundreds of routes and a sales-org structure that was never designed around trucks.

What ends up in the Z-namespace?

This is where the working title comes from. The community's own advice to beverage teams building on standard SAP is direct:

create your own logic to populate z-tables, create reports and print balance confirmations

Read that as a build list with three custom deliverables:

• Z-tables to hold the deposit and empties balances the standard tables do not model;
• custom reports to age and reconcile those balances by customer and route;
• printed balance confirmations — the document a customer signs to agree what they owe you in empties.

And that is before excise. Excise duty — the volume- and strength-based tax specific to beverages — is not native to S/4 either; SAP delivers it through partner add-ons. The excise tax page and vendor documentation name at least three: Vistex, GQS and Krones. So "SAP does beverage" resolves, in practice, to standard SAP plus a Z-namespace plus a third-party excise engine — three systems that have to move in step through every release.

Where does the liability actually live?

Ask finance where the empties deposit liability sits and you will often get a spreadsheet. That should sound familiar: it is the same shape as loyalty's deferred-revenue accounting gap — a real, audited liability the core system never modelled as a first-class object, so it gets reconstructed monthly in Excel. Empties are harder in one respect: the balance is bilateral. You owe the retailer for crates sitting in their yard; they owe you for crates that left on your truck; and the net has to be agreed, signed and aged on both sides before anyone trusts the number.

The custom code does not sit still either. Every Z-table and every route-level BOM is something your team now owns through each upgrade — the quiet tax we have written about when a platform you already paid for has to be paid for again, and when platform modules move faster than the team maintaining them. Custom empties logic is exactly the code no upgrade regression suite covers, because it was never SAP's to test in the first place.

So what is the way out?

Stop treating empties as a packaging side-effect and model them as a first-class domain object: a returnables-and-deposit ledger that carries balances per customer, per SKU and per deposit class, emits events on every delivery and return, and reconciles without forcing one route into one sales area. That is what we build on an event-bus architecture, with the SAP financial core left in place to post the journals it is genuinely good at — not to be the deposit system it was never designed to be.

The pressure only builds from here. Deposit return schemes keep widening to cover more one-way containers, and each new scheme is another deposit class, another balance to confirm, another degree of drift between the returnable-packaging assumption baked into standard SAP and the market outside it. The teams that treat empties as real domain data will spend the coming years extending a ledger; the teams still patching Z-tables will spend it regression-testing their own custom code against someone else's upgrade calendar.