One number for finance and technology

Picture a monthly review of AI spend, with round numbers for the example. The engineering lead shows a dashboard with $50,000 of usage last month. The finance lead has the invoices, and they add up to $41,000. The next half hour goes into working out which number is right, and the decision the meeting was for waits another month.

Usually both numbers are right. They come from two different sources and answer two different questions, so the fix is to bring the two sources into one figure that both teams can check.

Two sources, two questions

The engineering number usually comes from the vendor's own usage data: tokens and seats by model and key, priced from the public price list. Vendor consoles do this well. The data arrives daily, it shows which model and which key spent the most, and it is the number an engineer needs to choose a model or change a prompt.

The finance number is the invoice, what the company owes. It arrives once a month, often as a few lines per vendor with no team or workload on them, and it is the number finance records in the accounts.

The FinOps Foundation draws the same line in its announcement of FOCUS 1.4 (June 10, 2026), the open specification for billing data that it maintains. Usage data, it says, "helps answer 'what did we use?' not 'what's on the invoice?'" Version 1.4 adds an invoice dataset for that reason, with the tax lines that usage data usually leaves out.

Surveys find the same gap. In a survey of 500 finance leaders in the US and UK (DoiT and Sapio Research, February 2026), 37% named finance and engineering defining success differently as a barrier to measuring the return on AI, and only 15% said they can calculate that return without major obstacles.

What sits between the two numbers

The difference between usage at list price and the invoice is rarely a mistake, and each part of it usually has a name. A negotiated rate below the list and the tax lines are easy to find. Three others need more care. A credit lowers what you pay this month, but not what the work cost. A commitment is paid whether it is used or not, so the invoice can carry a charge with little usage behind it. And some models are sold through a cloud marketplace: AWS's Bedrock FAQ says customers will see a separate AWS Marketplace bill for certain Bedrock models. On our own AWS account in September 2026, every Claude charge arrived that way, so a cost report filtered to Amazon Bedrock showed none of it.

In the example above, a contract rate 10% below list explains $5,000 of the gap, and $4,000 of credits used that month explain the rest.

Reconcile to each invoice, and keep the detail

To reconcile is to check the total against each invoice and give a reason for every difference. We suggest this order:

1. 1Start from usage, because only usage carries the model, the key, the team and the day.
2. 2Price it at your own rates rather than the list, once someone enters what the contract says.
3. 3Apply credits and commitments as lines of their own, so both teams can see them.
4. 4Add the marketplace bills for every model you buy that way.
5. 5Compare the result with each invoice. Where a difference remains, show it as its own line with its reason, rather than spreading it across teams.

Owners by rules anyone can read

Once the total matches the invoices, the next step is to say who each dollar belongs to, in a way finance can check. We suggest writing each mapping down as a rule: this key belongs to the support team, this inference profile to the search product, this workspace to the data team. When someone disagrees, they change the rule, and every report follows it.

Some spend cannot be told apart from the data alone, such as one shared key behind a gateway that several teams call. You can divide that spend by a rule finance agrees to, for example by each team's share of requests, as long as every report says it is a split and not a measured fact. Spend that no rule reaches stays on its own line as "No owner yet", so the totals do not look more complete than they are.

Why the arithmetic has to be code

Language models are good at reading a question in plain words, but they are the wrong tool for producing the number. The same question can get a different answer the second time, and nobody can trace the result back to an invoice line.

Finance will use a number only when someone can trace it back to the invoice.

So we keep the two jobs apart. Code with tests computes the costs, splits and totals from the recorded data, the same way every time, and code writes the answer with the rows it came from. A language model may only help read a question like "why did the support team's AI cost rise last month?" into a plan that code checks and runs. Ask AI works this way.

The AI P&L: one report, three readers

Once cost is reconciled and has owners, it can sit beside what it produced. An AI P&L shows three things for each workload, month by month:

• Cost: the reconciled spend, with its owner.
• Outcomes: the resolved tickets, merged pull requests or won deals, each marked observed, declared or not measured yet.
• Value: what those outcomes are worth, as the business owner set it, against the cost.

Finance, engineering and the business owner each read a different part of the report. Because every part comes from the same reconciled total, a question from one of them gets an answer the other two can accept.

Four questions for your next review

1. 1Does our AI total match every invoice, marketplace bills included, and does each difference have a name?
2. 2Are our contract rates and credits entered, or are we still pricing usage at list?
3. 3Is every owner set by a written rule, and is every split labelled as a split?
4. 4Can someone trace any figure in the report back to the invoice line it came from?

When the answer to all four is yes, the review can spend its time on the question it was for: what the AI spend produced, against what you expected.