Cost-to-serve software: a buyer's guide for logistics and distribution

What makes cost-to-serve different from general costing?

Product cost ends at the warehouse door. Cost-to-serve starts there.

It covers everything the act of serving triggers: order entry, picking and packing, transport and drops, returns, invoicing, credit control, customer service. In distribution these costs routinely run 10% to 30% of revenue, yet most ERPs spread them as a flat percentage, which is precisely how the weekly three-line Saturday customer hides.

The method question is settled in practice: this is time-driven activity-based costing territory, because only time equations price variety without drowning in survey work. The method itself is covered in how to calculate cost-to-serve.

What must the software model, concretely?

Order behaviour. Lines per order, units per line, order frequency, urgency flags. A 3-minute base plus per-line picking time is where most distributor models start.

Delivery behaviour. Drop size, route, distance or zone, tail-lift and timed windows. Transport is usually the biggest block and the worst-allocated one.

Returns and exceptions. Returns, credit notes, disputed invoices, manual interventions. Exception work is expensive precisely because it never appears in standard cost.

Channel differences. The same product through wholesale, e-commerce and direct sales consumes three different activity chains. The software must keep them apart.

A worked flavour of the equations involved, with illustrative numbers, is on our time equations reference.

What data does it need, and how hard is that?

Three feeds, all standard exports: order and delivery transactions at line level (CSV from the ERP, WMS or TMS), operating costs by department from the GL, and time estimates for the main activities.

That last feed frightens buyers and should not. TDABC time estimates come from short observation, not company-wide surveys; a distribution centre's core equations are typically drafted in days.

Scale is a fair worry in logistics, where a year of order lines runs long. For reference, our largest CostCtrl model in production processes 525,000 transaction rows for a logistics operator, loaded from exports, no live integration.

What separates real candidates in evaluation?

1. Ingests order lines, shipments and returns at your real volumes; test with a full year.
2. Time-equation logic that prices drop size, distance, lines and exceptions separately.
3. Transport cost attributed by route or zone behaviour, not by revenue share.
4. Unused warehouse and fleet capacity reported separately, not hidden in rates.
5. Outputs per order, per customer and per channel, with a native whale curve.
6. Any figure traceable back to minutes and rates, defensible in a customer negotiation.
7. Finance or operations can update a time estimate without the vendor.
8. Monthly refresh from the same exports, without a project.
9. Transparent subscription pricing before the pilot.

Criterion 6 deserves emphasis. Cost-to-serve numbers end up in front of customers during repricing. A figure you cannot trace is a figure you cannot defend.

What does the payoff look like in practice?

A distributor looked healthy on its P&L and was planning for growth. A TDABC cost-to-serve model, built from exports it already produced, found 830 of its 1,951 active accounts contributing negatively, roughly EUR 1.335M of margin given back each year through small orders, costly delivery patterns and unpriced service.

Repricing and service redesign recovered EUR 0.93M. No customers were fired; minimum order values, delivery charges and channel moves did the work. The finance team still runs the model.

The standard shape of a cost-to-serve result: not a cost-cutting programme, a repricing map.

Where does CostCtrl fit?

CostCtrl is a TDABC platform with cost-to-serve as a first-class use case: time equations for order, warehouse and transport activities, capacity cost rates, whale curves, order-level datasets from CSV or SAF-T, subscription pricing.

Consulting is embedded at the start and then leaves: a free Profit Check, a first model built with your team (ProfitAudit 360 where a fixed-fee full audit fits better), then handover to your controllers. If you need enterprise-wide network optimisation or a TMS, that is different software, and we will say so.

Fair questions.

What is cost-to-serve software?

Software that attributes order handling, warehousing, transport and admin costs to each order, customer and channel based on the activity they actually cause, usually via time-driven activity-based costing. Its headline outputs are cost per order, customer profitability and the whale curve.

How is cost-to-serve different from landed cost?

Landed cost brings a product to your warehouse: purchase, freight in, duty. Cost-to-serve takes it from your warehouse to the customer and through the admin cycle. Full customer profitability needs both.

Can our ERP calculate cost-to-serve?

ERPs record the transactions but almost never the activity cost attribution; they spread logistics and admin as flat percentages. That is why heavy-service customers look fine in ERP margin reports. The transactions your ERP exports are, however, exactly the fuel a cost-to-serve model needs.

Is this only for large distributors?

No. The economics bite hardest in the mid-market, where a few hundred mixed-behaviour accounts can hide six-figure leakage. The distributor case above was a mid-sized business, not a multinational.

How long until first results?

With exports available and TDABC as the method, weeks: draft equations, load a year of transactions, first whale curve. The long pole is usually agreeing what to do about the tail, not computing it.