Your Chargeback Policy Is Becoming a Settings Page

Earlier this month I sat with a client who had switched on seven cost allocation tags in one of their four AWS payer accounts. Collection had started a fortnight before and the backfill tickets were not raised, so nothing sat behind the tags yet. That part is a data problem with a known fix and a known wait.
Tagging will not answer the harder question underneath it. Once the data exists, which cost do you allocate, to whom, under what rule, and at what internal rate? Those four economic decisions sit at the core of any reproducible allocation, and no tool settles them for you. In the same month they sat open at that client, three vendors shipped capabilities that can each hold one of the answers. Each answer would live inside a single product.
What shipped
On 15 September AWS added custom rates and usage tier pricing to Billing Conductor, which it says removes the need to “calculate percentage-based markups or markdowns against public on-demand pricing to model your commercial agreements”. It already lets you set global or specific markups or discounts across billing groups, and analyse the margin between pro forma and billable cost.
Anthropic shipped a multiplier in Claude Code’s modelPricing managed setting, “above 1, up to 10”, described in the changelog as being “for marked-up internal chargeback rates”. An administrator can enter the organisation’s contracted per-token rates under overrides, apply a multiplier, or do both. Anthropic states that the setting “changes what Claude Code reports, not what Anthropic charges”. The figure a developer sees in the terminal need not be Anthropic’s price at all. It can be the organisation’s own contracted rate with its own markup on top, calculated and displayed by the vendor’s tool.
Microsoft Foundry added project-level cost attribution, in preview, with every project “automatically associated with a project tag on its underlying usage”.
These are not three versions of the same thing. Billing Conductor is close to a chargeback system, the Claude Code setting is a rate construct, and Foundry sets an attribution boundary while leaving the question of what a project means economically where it was. All three, though, make it possible to encode an economic decision in a settings page.
This is not a problem invented by three convenient announcements. The FinOps Foundation’s State of FinOps 2026, drawn from 1,192 respondents and more than 83 billion dollars of annual cloud spend, puts AI spend management at 98 per cent against 63 per cent a year earlier. Allocation is the leading priority across the newer technology categories, and respondents report allocating AI cost to business units as harder than traditional infrastructure.
Use the native tooling
For a client with almost all of its spend on one provider, native tooling holds pricing behaviour that a FOCUS-only pipeline will not. AWS documents the gaps in its own FOCUS 1.2 export: ContractedUnitPrice, ListUnitPrice and SkuId “might be null” where the specification says they should not be, and split cost allocation for EKS and ECS sits in the Cost and Usage Report rather than the FOCUS table. A cross-provider model built to the lowest common denominator discards that; one built properly keeps the native detail and normalises beside it. Native should be the default unless a named requirement justifies reproducing it elsewhere. A regulated client whose auditor wants one allocation method applied across cloud, licences and data centre has that requirement. A client with one provider and a spreadsheet does not. If an advisory proposes the rebuild without naming the requirement, ask why.
The treatment nobody chose
AWS publishes exactly what its pro forma billing leaves out: “Credits (redeemed at the payer or linked account level), Free Tier credits, Support plans charges (Enterprise, Business, Developer), Non-public discounts (for example, Solution Provider Program), Usage-based discounts (for example, bundled discounts), Tax, Refunds”. The documentation adds that “the pro forma data differs from the data shown in your AWS bill and doesn’t reflect the actual charges due to AWS each month”.
AWS also ships custom line items to put those back, and its own documented use cases include allocating support fees, applying tax and distributing credits. The exclusions are a starting position with an override sitting next to them.
Whether an internal customer carries its share of Enterprise Support, whether a negotiated discount reaches the consuming team, whether tax belongs inside an allocated figure: each requires an explicit answer for a given business, and each has more than one defensible answer. A pro forma view calculating something is not yet your internal chargeback treatment. It becomes the treatment when somebody carries that output into management reporting or a chargeback posting without checking what it assumed, and where the organisation has specified nothing, the default is what gets carried.
The four decisions
Write the four decisions down in a definition you govern, and keep that definition separate from any tool that implements it.
Cost basis is the first: which source cost the calculation starts from, and how commitments, discounts, credits, support, tax and refunds are treated. The pro forma exclusions above show a product supplying a default treatment that may become the starting point.
Recipient is the second: the product, customer, business unit or cost centre that carries the cost. What matters is one canonical recipient model with documented mappings from each provider’s constructs into it. Recipient models maintained independently per console create reconciliation and drift risk.
Allocation rule is the third. How shared cost divides, and what happens to a dollar nothing claims.
Internal charge rate is the fourth. Pass-through, markup, subsidy or standard rate. Where the allocation feeds management reporting or a chargeback posting, changing this rate changes the economics presented for the consuming product. The authority to configure that number is not the authority to define what it means, and an organisation needs the second written down, whoever holds the first.
Two properties run through all four. Each is effective dated, because a rate that changed in July makes last quarter unreproducible if nobody wrote down when. And the total needs to be reconcilable to source economics through a stated bridge rather than equal to it: provider cost, plus internal service loading, less any subsidy, equals the internal charge. A seven per cent loading is meant to make those numbers differ; a difference nobody can explain is the failure.
Take a product running infrastructure on AWS, inference in Foundry and coding agents against Claude Code, and let each system be authoritative for the part it does well. AWS holds a pro forma treatment of the infrastructure economics, exclusions and all, while Foundry identifies project-level usage and Claude Code holds an organisation-configured internal rate. Each is defensible on its own terms. What does the product cost? Nothing in the three of them reconciles those locally valid constructs into one figure, because the rule that would join them was never written down.
Why FOCUS does not close this
FOCUS is the obvious place to look, and it gets halfway.
FOCUS 1.4 carries allocation columns, names chargeback among the scenarios it supports, and permits custom columns with an x_ prefix “to facilitate reporting capability that is not covered by the columns included in the specification”. You can put x_InternalPrice and x_PolicyVersion into a FOCUS dataset this afternoon. As of September 2026, AWS, Microsoft and Google document FOCUS exports only up to 1.2, so their data lags the allocation columns added in 1.3.
That solves storage and stops there. Nothing in the specification says what an internal price means, how it is derived, who approves a change to it, or how a second implementation reproduces last month’s figure from it. FOCUS gives an enterprise somewhere to put its own economic concepts and leaves the meaning with the enterprise. The standardised allocation columns describe data generator calculated splits, where the generator divides an origin charge into finer allocated charges by a documented method while preserving reconciliation. Deciding which business unit carries the result is a different problem.
Neither Anthropic nor OpenAI currently appears on the Foundation’s list of providers publishing a FOCUS dataset, so billing taken directly from either arrives in whatever shape they choose. And the current 1.5 scope, targeted for December ratification and still being finalised, covers model identity and an actor dimension rather than internal pricing.
FOCUS has materially improved the semantic portability of billing data. The portability of an organisation’s internal economic policy is a separate problem and was never in its scope.
A2A, the Italian multi-utility, brought AWS, Azure and Google Cloud billing into one view and reported 1.5 million euros of annual savings in 2025, on AWS’s telling and with no total spend to measure it against; the write-up says nothing about who defined the rules applied on top of that data layer.
The reproducibility test, and what it takes to pass
Could finance reproduce last month’s allocation from source billing data and a versioned definition, without depending on the console configuration that happened to be in place at the time?
Vendor configuration can be held in version control and deployed as code, and AWS states that a pricing plan change affects the current billing period while prior periods remain unchanged. A well governed Billing Conductor configuration is reproducible, and none of this requires a vendor to design for dependency. It arises when an organisation lets implementation state become the only authoritative expression of its own policy, which means the organisation created it and can prevent it. Where the answer is no, restating a prior period means reconstructing what the console was set to at the time, rather than rerunning a policy you govern.
Solving that does not inherently require another platform. It requires a versioned definition carrying enough to rebuild the result: the cost basis and its adjustment treatments, the recipient mapping, the allocation logic and its exceptions, the rates, the effective dates and who approved each. Naming the four decisions is not sufficient. “Shared observability cost distributed on trailing three-month production telemetry volume, regulatory workloads excluded, five per cent floor” is a rule somebody can rerun next March. “We allocate observability fairly” is a sentence.
What the backfill won’t settle
The backfill will land, the tags will start earning their keep, and the reports will work. The next job at that client is to agree the cost basis, the canonical recipient mapping, the allocation rules and the internal charge rates well enough that finance can reproduce the result from source data. Implement those decisions in the native tools where those fit, and keep the versioned definition as the organisation’s own. Whoever approves the internal charge rate should sign the document that defines it.
Could you rerun last month’s allocation?
Bring one shared cost and we will work through its cost basis, recipient, rule and rate with you.
Book a Conversation