Custom cost-to-serve analytics development
Your revenue reporting shows who your biggest customers are, not what it costs to serve them. Cost-to-serve analytics attributes transport, order processing, warehouse handling, returns and service contact to the customer, order and channel that cause them. Appfront builds this as software when the outcome must be repeatable and must consistently inform commercial decisions. Below, you can also read when a spreadsheet is enough.
Your largest customer by revenue is rarely your best customer by margin
Cost-to-serve covers everything that happens after gross margin: processing order lines, picking, driving, receiving returns, handling complaints, plus the discounts and rebates agreed in the annual contract. In 2001, Robert Kaplan and V.G. Narayanan described the whale curve: the most profitable twenty per cent of customers generate between 150 and 300 per cent of total profit, after which the tail gives that back. That tail often includes a name from the top of the revenue list.
This pattern arises where small urgent orders, high return rates, negotiated delivery terms and a lot of service contact come together: wholesale, foodservice, e-commerce with substantial return flows, and manufacturers with customer-specific delivery arrangements. Revenue reporting shows none of this: these costs sit in ledger accounts without a customer name.
Are you on the right page? Cost-to-serve looks backwards and explains what a customer has actually cost. If you want to look forward, with demand forecasting or a revenue forecast, that belongs in a predictive analytics dashboard. If the question is which stops go on which route tomorrow, that is a transport planning API.
Cost allocation per activity
Cost pools with one driver per pool: pick lines, cartons, stops, route minutes, customer contacts. The key is visible in the application, not hidden in a formula.
Net margin per customer and channel
From gross margin to net margin per debtor, delivery address, order line and channel, with drill-down to the underlying order lines.
Scenarios with a behavioural assumption
Model what a higher free-delivery threshold, fixed delivery days or an urgency surcharge would do, with an explicit assumption about how the customer will respond.
Where margin disappears in practice
The costs that leak away here are small per unit, they recur, and they sit in a cost centre that knows no customer name. Four patterns almost always come back.
The urgent order that returns four times a week
One customer doesn't order a full pallet a week, but four half roll cages, usually just after the cut-off. Each order costs a pick run, an extra stop, a delivery note and an invoice line. Below the free-delivery threshold, you also bear the freight.
Returns that aren't linked to any order line
For distance selling, there is a fourteen-day cooling-off period (Article 6:230o of the Dutch Civil Code); in B2B, a return usually goes through a separate credit note. Receipt, inspection, repackaging and write-downs land as warehouse costs in overheads, never with the customer who caused them.
Delivery terms agreed in the contract
Delivery within a fixed time window, arrival via a distribution centre's booking portal, a prescribed carrier, or export where you deliver DDP under Incoterms 2020 while EXW applies elsewhere. Those agreements sit in the contract, not in the cost price.
Service contact with no cost centre
Orders that arrive by email and are keyed in by hand instead of via EDI, changes after the cut-off, disputes over delivery notes, repeated questions about delivery status. Those minutes belong to a customer name, but sit in a salary line across all revenue.
Since 1 July 2026, heavy goods transport in the Netherlands has also been charged per kilometre driven under the truck toll, with rates varying by weight and emissions class. Panteia points out that the effect differs per trip and per customer, so a single average trip cost across all shipments no longer suffices.
The allocation key determines the outcome, not the dashboard
Direct costs are the easy part: a consignment note attaches to a shipment, a pick line to an order line. The real work lies in costs that cannot be traced to any single order: warehouse rent, planning, back office, customer service, quality control. You allocate these using a key, and that choice determines who comes out looking bad. Allocating per parcel penalises volume, per order line penalises range of products, and per picking minute requires time data that many WMS implementations rarely make accessible.
Activity-based costing is therefore not an objective measurement but a model built on assumptions. The underlying principle is causality: a cost should land where the activity that causes it takes place. Where that link cannot be demonstrated, you make a reasoned analogy, much as the IMA's Conceptual Framework for Managerial Costing sets both principles side by side. In 2004, Kaplan and Anderson introduced time-driven activity-based costing precisely because the classic variant got bogged down in endless interviews about how time was spent. What remains is a choice, and that choice should be open to discussion.
In practice, this means three things. For each cost pool, record which driver was used, who set it, and when it was last recalibrated. Show, for every amount, which key was applied, with a link through to the order lines. And build a sensitivity analysis. Without one, the person whose largest customer turns red will challenge the key, and they will win the argument.
Bringing the data together is usually the project
The arithmetic is the smallest problem. The data sits in four or five systems, at different levels of granularity, with keys that do not line up with one another.
Order lines from the ERP
Item, quantity, selling price and standard cost price per order line. Pay attention to customer identity: debtor number, delivery address and purchasing combination are three different things.
Carrier invoices and TMS
The actual rate appears on the carrier's invoice, including surcharges per consignment. Large carriers supply EDI messages such as IFTMIN, IFTSTA and INVOIC; smaller ones send a PDF.
Warehouse activity from the WMS
Pick lines, parcels and, where available, picking and packing times. If this source is missing, the warehouse remains a flat amount per order and the distinction disappears entirely.
Returns and credit notes
Usually the weakest source. Registration is often missing or does not refer back to the original order line, so returns handling and write-downs cannot be traced to a customer.
Ticketing and order intake channels (EDI, webshop, email) also drive the inside sales workload, while volume discounts and annual bonuses are usually held in contracts with no link to the customer. Integration is the hardest part: a single route carries orders from several customers, so transport costs must be allocated first to stops and then to shipments. Define explicitly which share of the costs can be demonstrably traced to an order and which share is allocated through a key.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →An outcome that leads to a conversation, not a report
An analysis is only worth something if it leads to a decision, and those decisions come from a limited set of levers: the free-delivery order threshold, a minimum order size, fixed delivery days per region, a rush or small-order surcharge, adjusted delivery terms in the annual agreement, and, in the extreme case, a deliberate parting of ways with a customer or delivery condition.
Scenario functionality is therefore at the core of the application, and every scenario contains an assumption about behaviour. A customer you push to a single weekly delivery moment may double their order size or move volume to a competitor. So show the volume risk too, with an assumption your account manager can adjust.
Finally, plan for the decision moment. Outcomes discussed at the annual agreement, the price review or the customer review lead to action; a standalone quarterly report does not.
Sources and integrations we connect:
When you had better not have it built as software
A first cost-to-serve analysis is a one-off exercise, and it belongs in a spreadsheet or an advisory engagement. You need a representative period of order lines, an export from your transport system and a set of assumptions. That will immediately show whether your data is sufficient. If a large share of freight costs cannot be linked to an order, then that is your first project, not an application.
For some readers, off-the-shelf software is the right answer. If your organisation runs on SAP S/4HANA, margin analysis, the account-based successor to CO-PA, is already present and reconciled with the financial ledger via the universal journal. Oracle offers an allocation engine for multi-level allocation keys with Profitability and Cost Management Cloud; Anaplan, Board and Jedox do the same. A second model alongside it gives you two versions of the truth about the same margin.
Custom development is justifiable when the weight of your costs lies outside the ERP, in TMS, WMS, carrier invoices and ticketing systems, and the package cannot ingest those sources at order-line level. It is also justified when allocation keys differ by channel or customer group, or when the standard set-up forces you to translate your operation into the vendor's model.
With custom development, expect a burden that falls to you: recalibrating allocation keys whenever the operation changes, version control so an earlier outcome remains reproducible, and someone who can explain the assumptions when the controller asks.
- Allocation keys differ by channel, region or customer group
- Scenarios depend on the quote, the annual agreement or the webshop threshold
- The outcome is used structurally in commercial decision-making
- There is someone who owns the model and defends its assumptions
Frequently asked questions about cost-to-serve analytics
The questions controllers, supply chain managers and commercial directors ask us most often.
Often that is the right choice. If you run on SAP S/4HANA, margin analysis, the account-based successor to CO-PA, is already present and reconciled with the financial ledger. Oracle Profitability and Cost Management Cloud and EPM platforms such as Anaplan, Board and Jedox offer a ready-made allocation engine. Custom development is only justifiable when your costs largely arise outside the ERP.
By agreeing the key in advance with controlling and operations together, and making it visible in the application. Every allocated amount should show which driver was used, who set it and when it was last recalibrated. A sensitivity analysis shows how much of the outcome depends on that choice.
That is the usual starting point and usually the hardest part of the work. Freight costs appear on the carrier's invoice and first need to be allocated across trips and stops. Returns often arrive as a separate credit note with no link to the order line. The first step is establishing which portion of the costs can be demonstrably attributed to an order.
For an initial exploration, almost always. A representative period of order lines, an export from the transport system and a set of assumptions will yield conclusions faster than any build. Software only becomes justifiable once the output must be repeatable and current, and is used structurally in commercial decisions.
Record ownership, source code and handover in the contract, and keep the model readable: every cost pool, driver and assumption documented, version control so that an earlier result remains reproducible, and calculations that can be traced without the original builder. A model nobody can explain will not be used.
No. A profitability report follows the ledger structure and usually stops at gross margin per product group or customer. Cost-to-serve follows the activities: how many pick lines, stops, driving minutes, returns received and customer contacts this customer has generated. At total level, both should reconcile.
Related services
Predictive analytics dashboard
Cost-to-serve explains what has happened. If you want to look ahead, with demand forecasting, churn risk or a revenue forecast per segment, that is a predictive model built on the same order and customer data.
Transport planning API
The delivery costs you allocate arise in the planning. A planning API determines which stops go on which trip and supplies the trip, stop and tariff data your allocation requires.
Want to know what your customers really cost you?
Tell us which systems record your orders, trips, warehouse activities and returns, and where the conversation about margin currently gets stuck. We will first assess whether your data supports a reliable allocation, and tell you if an analysis outside software will help you faster.