Building a cost model that can answer what technology delivers for the business is a step-by-step discipline, and this is the next piece in our series on it. We started with attribution: assigning each cost to the team, product, or service that owns it.
But some costs don't resolve to a single owner. They're attributed to a shared entity: a Kubernetes platform running workloads for a hundred use cases, an observability platform the whole engineering org depends on, or a company-wide software license. One bill, many consumers, no obvious way to say who owes what.
That cost still has to reach the consumers and beneficiaries, or you won't have an accurate Total Cost of Ownership (TCO) model, to serve chargeback, unit economics, margins, and the forecasting needs of your organization. Getting you there is the job of allocation.
Why allocation is hard
Shared cost is a rapidly growing reality of the modern IT estate. Kubernetes clusters, AI gateways, datalakes, security tooling, company-wide licenses: each are consumed by many to different degrees. As organizations consolidate onto shared platforms, the share of cost that belongs to everyone, but accounted for by no one, keeps rising.
The hard part is not the arithmetic of dividing a pool. It is that the division only means something once three other things are in place.
Attribution has to be right first
An allocation starts from cost already attributed to the shared service, so it inherits whatever attribution got wrong. If part of the platform's cost never reached it, the SaaS datastore it runs on, the observability it generates, the AI gateway in front of it, then the pool being divided is too small and every recipient is undercharged by their share of what is missing. A perfectly fair split of an incomplete pool is still the wrong number.
The organization has to agree on the strategy and its semantics
An allocation is a statement about who carries what, so it holds only if the parties accept the basis. Who is in the receiver set, what the resulting number is for, showback or chargeback, and who can dispute it: those are agreements between the platform owner, the teams consuming it, and finance. Better tooling does not settle them.
Some strategies need data the organization may not collect yet
Dividing a platform by what each team actually consumed requires consumption data (pod-hours, tokens, query volume, seats) collected, retained, and joinable to cost. Dividing by headcount or revenue requires that business dataset to be in the model. Plenty of organizations have neither on day one. The strategies available to you are bounded by the data you hold.
The first two are prerequisites you work through. The third decides which strategies are open to you today, and it is where allocation efforts most often stall, waiting on data nobody has started collecting.
The strategies, and what each one asks for
Allocation is a choice of strategy: how to divide a shared cost among the parties that consume it. There is no single correct strategy. Each is valid for a different need, a different level of maturity, and a different kind of cost.
Fixed. Distributes by explicit ratios that sum to 100%. Needs an agreement on the shares.
N-way. Distributes equally across the receivers. Needs a static or dynamic set of receivers.
Proportionate. Distributes by a driver metric: pod-hours, tokens, seats, queries, headcount, revenue. Needs data to determine distributions, joinable to the cost.
Replace. Swaps coarse cost for finer-grained cost covering the same resources, so nothing is double-counted. Needs a granular cost dataset for those resources.
Read down the list and two things move together. Each strategy resolves cost more precisely than the one above it, and each asks for more data to apply. Fixed needs an agreement and nothing else. Replace needs an entire second dataset.
The distribution strategy choice can vary per shared cost, not per organization. A company-wide license may sit on Fixed indefinitely because the shares genuinely do not move, while the database platform beside it starts on N-way and moves to Proportionate once query-level consumption is available, and a Kubernetes platform that has its own granular cost based on pod-level telemetry can use Replace. A mature estate picks the right tool for the right job.
Start somewhere, then make it better
The most common failure in allocation is not a crude split. It is no split at all: a shared platform left sitting on the central cost centre while the organization waits for the telemetry that would do the perfect allocation.
"Unallocated shared cost is unaccounted cost."
Waiting is the worst outcome. No product carries it, no team sees it in their numbers, and nobody argues about it, which reads as agreement and is not. Meanwhile every unit economic above it is understated by the amount left behind.
Starting with a fixed or n-way split, and being clear that is what it is, is the better move. It is not the accurate answer, but it puts a number in front of people, and that is what starts the work:
Start with a simple allocation. Fixed shares an arrangement that already exists, n-way where it does not. Date it, and say plainly that it is a first pass.
Let stakeholders push back. A team that believes its share is too high has to say why, and the reason is almost always a claim about consumption: we run a fraction of the workloads, we call it far less often than they do.
Turn the disagreement into a data requirement. That claim names the driver the split should be using. Instrumentation gets prioritized when a stakeholder disputes a number, far more reliably than when a platform team asks for it on its own.
Move the strategy up as the data arrives. Proportionate once the driver is collected and joinable. Replace where a platform tool already produces granular cost for the same resources.
The split improves because the conversation happened, and the conversation happened because there was a number to disagree with. Treat each strategy as the right one for now, revisited on a schedule, rather than a permanent verdict.
Why this matters
Get allocation right and shared cost stops being the weak point in every number above it. Unit economics hold up because the platforms underneath them are divided on a basis the organization has agreed to, and sharpened as better data arrives.
Chargeback stops being a fight, because a team that questions its share can be shown exactly how the number was reached, traced through every hop and reconciled to the bill. Forecasts improve, because a split that is maintained deliberately moves with the business, instead of lurching when someone finally revisits a percentage nobody has looked at in a year.
How StitcherAI approaches allocation
A strategy is only as good as the system that executes it. StitcherAI runs allocation on a foundation that stays correct and stays auditable.
It starts with scope. Shared cost does not all live at the same level: some is shared inside a single account, some across a provider, some across the whole estate. StitcherAI allocates at the level that matches the cost, so a cluster shared within one team and a platform shared company-wide are each handled at their true scope rather than forced through one blunt split.
Every allocation is balanced by double-entry accounting. When a shared cost is distributed, StitcherAI posts the amounts moved to the recipients and an offsetting entry against the source, and the two net to zero. The bill total never changes; the cost is only redistributed. An IT Finance team can split a platform across forty teams and know, without checking, that the model still ties out to what the provider charged. Cost is moved to where it belongs, never invented and never lost.
This runs on the same normalized foundation as attribution. FOCUS normalizes every source into one schema, so the figures being distributed are consistently defined rather than stitched together from each provider's terminology. That lets a receiving team read its share without a specialist translating provider taxonomies first. And because the datasets that drive each split, the usage data, the headcount, the revenue figures, live in the cost model alongside cost, the allocation recomputes as they change. When consumption shifts or a team's headcount moves, the split moves with it, without anyone rebuilding it by hand.
Every hop is traceable
Real organizations are layered, and a single allocation is rarely the end of the story. A shared platform's cost is allocated to the internal services that run on it. Those services may themselves be shared, so their cost is allocated onward to the products that depend on them, and those products onward to the business units they belong to. Allocation follows that structure, one hop leading to the next, until every dollar reaches a final owner.
The risk in any multi-step redistribution is that it becomes impossible to follow. StitcherAI records how every amount moved at each step: where it started, which rule moved it, in what proportion, and where it landed. A finance team can trace a single dollar from its original bill through every hop to the team that ultimately carries it.
This traceability comes from treating the cost model as versioned, inspectable logic rather than a spreadsheet, an approach we call Finance as Code, and the foundation of a defensible model. It is a subject in its own right, and the next piece in this series. For allocation, the point is simple: however many hops a dollar takes, the path can always be followed.
Bill to business
Allocation carries a shared cost from the component it landed on to the teams that actually consume it, so it becomes something the business can act on: divided on a basis the organization stands behind, reconciled to the bill, and traceable to the last dollar.
That is what lets the numbers built on top of it hold. Unit economics and margins are only as sound as the shared cost feeding them, and a shared platform is often the largest cost a product carries. Get its split right and an organization can stand behind a product's full cost to run, including the platforms and shared services it draws on.
This is how StitcherAI turns shared cost from a black box into a number every team can trust. See what it looks like against your own estate.