Contribution margin by product, customer or project: why it takes three systems

Contribution margin is what a product, customer or project earns after the costs it directly causes: revenue minus material, freight, payment fees, commissions and other variable costs. It shows what each line contributes to covering fixed costs. In most growing companies it is calculated once a quarter in a spreadsheet, because revenue, product costs and overheads sit in different systems.

The calculation itself is simple. What makes it hard is that the ledger rarely knows which product, customer or project a cost belongs to. This guide explains the German multi-level method, why the data falls apart, and how to structure bookings so that margin per line becomes a filter instead of a project.

---

What is a multi-level contribution margin?

German controlling uses the Deckungsbeitragsrechnung (contribution margin accounting), usually in several levels. Each level subtracts a layer of cost that can be clearly assigned at that level and no lower:

• Contribution margin I (DB I): revenue minus variable costs. For a physical product that means material or purchase price, packaging, outbound freight, payment fees, sales commissions and returns.
• Contribution margin II (DB II): DB I minus fixed costs that belong to one product or product line, such as a dedicated production line, product-specific marketing or tooling.
• Contribution margin III (DB III): DB II minus fixed costs of a business area, plant or sales channel, such as a warehouse that only serves one channel.
• Operating result: DB III across all areas minus company-wide fixed costs like management, finance and rent for head office.

The point of the levels is honesty about allocation. DB I needs no allocation at all. DB II and DB III need clear rules but no guessing. Only the final step deals with costs that no product causes. A product with a positive DB I and a negative DB II is covering its material but not its own production line. That is a different decision from a product that loses money on every unit.

The same logic works for customers and projects. For a customer, DB I subtracts discounts, freight and payment terms; DB II subtracts the account manager and customer-specific service. For a project, DB I is revenue minus hours at cost and external spend.

The customer view often surprises people most. A large wholesale customer with a good list price can end up with a weak DB I once volume discounts, free shipping, long payment terms and frequent returns are counted. A small customer who orders full pallets and pays on time can be worth more than the revenue ranking suggests.

Why is the BWA not enough for margin decisions?

The BWA (the monthly management report from your tax advisor) shows one gross profit for the whole company: revenue minus material. It is built from the chart of accounts, so it knows the type of cost but not what the cost was for. A freight invoice is freight, not freight for product line A.

That is fine for the tax advisor (Steuerberater), whose job is a correct ledger and tax filings. It is not enough for a managing director deciding whether to drop a product, raise prices for one customer group or accept a low-margin project. German commercial law asks for proper bookkeeping, not for internal cost accounting, so the step from the BWA to margin per line is a choice each company makes, and usually makes in Excel. For reading the P&L itself, see P&L analysis.

Why does contribution margin take three systems today?

Take a company that sells physical products through a web shop and to wholesale customers. To calculate DB I per product, it needs:

1. Revenue per product and customer from the shop and the invoicing tool, net of discounts, returns and credit notes.
2. Product cost per unit from the warehouse or inventory system, valued the way the stock is valued.
3. Variable costs per order from the ledger: freight invoices, payment provider fees, commissions. These are booked to accounts, often in a monthly total.

Each system has its own product codes, its own period logic and its own idea of what a return is. Someone exports all three, maps the codes, allocates the monthly freight total by order count or weight, and builds the result. By the time it is ready, the month is six weeks old and the spreadsheet holds assumptions nobody remembers.

For companies that produce rather than trade, a fourth source appears. Under § 255 HGB (German commercial code), inventory is valued at production cost, which must include reasonable shares of material and production overheads, while selling costs must be left out. That valuation is right for the balance sheet, but it is not a variable cost, so the "cost of goods sold" in the ledger is not the variable cost you need for DB I. Why stock values and the books drift apart is covered in inventory valuation.

How do you structure the books for margin per line?

The fix is to put the information on the booking when it is created, so nobody has to reconstruct it later.

• Use dimensions, not accounts. Product line, customer, project, channel and cost centre belong on each booking as dimensions. Creating separate revenue accounts per product makes the chart of accounts unreadable and still says nothing about the freight. Our guide to general ledger structure explains the difference.
• Classify costs as variable or fixed once. Decide per account and per cost type which level each cost belongs to, and write it down with your controller.
• Tag at the source. A freight invoice should carry the orders it covers. A payment fee should carry the order it belongs to. An hour logged by a project team should carry the project.
• Agree allocation rules for what cannot be tagged. Some costs, like a shared warehouse, need a key. Choose one, keep it stable and show it in the report.
• Close the loop with planning. Once margin per line is in the books, it can sit next to the plan, as described in budget vs actual per cost centre.

How does Agent F help with contribution margin?

In Agent F, orders, invoices, inventory, purchasing, time tracking and the general ledger share one data model. A sale, the stock movement it triggers and the freight it causes are linked, not exported and mapped.

Every booking carries dimensions such as product line, customer, project, channel and cost centre. When a supplier invoice arrives, Agent F suggests the account and the dimensions from your booking history, each with a confidence score. A freight invoice is suggested against the orders it covers; a payment fee is linked to its order. A person confirms or corrects, and the system learns from the correction. Every change is recorded in the immutable audit trail.

Because dimensions are on every line, DB I, DB II and DB III per product, customer or project become a filter on live data rather than a quarterly project. You can ask in plain language which product lines had a falling DB I last quarter, and get the answer from the same numbers that go into the DATEV export for your tax advisor. The HGB inventory valuation stays correct for the balance sheet, while the margin report uses the variable cost view, from one set of bookings.

What should you do first?

Start with one level and one dimension. Pick DB I by product line, list the variable cost types that belong in it and check which of them already carry a product reference today. Then pick the largest untagged cost, usually freight or payment fees, and decide how it will be tagged from next month. After two or three months, compare the result with your last spreadsheet version: the differences show where your allocation assumptions were wrong. When margin per line arrives with the month instead of six weeks later, it can inform decisions while they are still open, the theme of real-time financial reporting.

Learn how Agent F works, or see it on your own product and customer data at agent-f.ai/demo.