How to measure the ROI of internal AI initiatives.

By COGScontrol Team · July 8, 2026

To measure the ROI of an internal AI initiative, treat it exactly as you would a product initiative: attribute its fully loaded cost — the LLM share as real invoice dollars allocated per project through a gateway, never tokens times a price list — divide by the one business metric it exists to move, and reconcile both sides to the P&L. The only thing that changes from function to function is the denominator — resolutions in support, reconciliations in finance, active seats for a copilot, hires in recruiting.

This guide is the operational companion to measuring the ROI of AI initiatives: the same discipline, applied to the AI that runs inside the business rather than inside the product — which is where most enterprise AI use cases now sit.

Why do internal AI initiatives get cut before product initiatives?

Because they are easier to cut. A product feature has revenue standing next to it; an internal initiative usually has only an invoice. When MIT's NANDA initiative reported that roughly 95% of enterprise generative-AI pilots deliver no measurable P&L impact, the finding — preliminary and contested — was less about the AI than about the measurement; and in its sample, internally built tools reached deployment about half as often as purchased ones. The internal initiative is the kind most likely to die unmeasured.

The finance data agrees. In a June 2026 survey of 260 senior finance professionals by CloudZero — a cost-intelligence vendor, so read with that in mind — only 22% of finance leaders said they can tie AI spend to business results today, and 35% had already killed an AI initiative over measurement gaps. Spend, meanwhile, rises by default — Uber exhausting its 2026 AI coding-tools budget by April is the cautionary case. Measurement is what keeps a working initiative funded, and the fix has two halves: a denominator per initiative, and a cost number that reconciles to the bill.

The one rule: every initiative gets a value denominator

The whole method reduces to a single discipline — name the metric each initiative exists to move, and make it the denominator of that initiative's unit cost. The denominators differ by function; the arithmetic does not.

Each row links to a full worked guide for that function. The denominator is the load-bearing choice: pick the wrong one and the ROI flatters itself (deflection is not resolution; a faster close is not a cheaper one). Pick the right one and the formula is unremarkable:

The denominator is the easy half. The half most teams cannot execute is the numerator — getting a per-project cost out of one provider bill.

How do you attribute LLM cost when the provider sends one bill?

Route all LLM traffic through a gateway and issue each internal project its own virtual key: the gateway records tokens consumed per key, and those counts become the weights for allocating the real invoice across projects.

Consider a composite example. A finance team builds an AI-assisted reconciliation tool that cuts the monthly close work it targets from 40 person-hours to two. Six months in, the CFO asks three reasonable questions — what did it cost to build, what does it cost to run, and should we keep paying for the tokens? Everyone in the room can name the hours saved. Nobody can name the cost, because the only cost artifact that exists is one OpenAI invoice covering every AI project in the company.

That silence is structural: the interesting unit — the internal project — is not a dimension the provider knows about. OpenAI and Anthropic bill at the account level, or at best the workspace level. The invoice states, authoritatively and to the cent, what the company owes; it says nothing about which team, tool, or experiment spent it. The reconciliation tool, the contract-review assistant, and an engineer's abandoned prototype all land in the same line. (A raw API key per project does not survive contact with reality: providers cap how many keys an account can manage, keys leak and get shared, and the bill still arrives as one aggregated number.)

An LLM gateway — LiteLLM is the popular open-source example — is the fix. Every internal tool calls the gateway instead of calling the provider directly, and the gateway issues virtual keys: lightweight, revocable, nameable credentials minted per project or team. The gateway is the natural chokepoint where “which internal thing made this call” is actually known. When the reconciliation tool holds a virtual key named recon-close-tool, every token it consumes — during the build, and every month since — is recorded against that name.

Why not just multiply tokens by the price list?

Because a gateway records token counts, not dollars. Negotiated discounts, committed-use tiers, credits, and taxes all live on the provider's bill — not in the gateway, and not in any public price list. Multiply gateway tokens by list prices and you fabricate a per-project cost that will not reconcile with the invoice the company pays. A number finance cannot reconcile is a number finance cannot use: it will not survive a close, an audit, or a skeptical CFO.

The reliable method inverts the naive one: allocate, don't reprice. Take the real provider bill — actual dollars, with every discount and credit already baked in — and split it across virtual keys in proportion to each key's share of tokens. The gateway supplies the weights; the invoice supplies the dollars. No price is ever invented; a real one is distributed.

Done properly, the allocation is finance-grade: attributed costs sum back to the invoice to the cent — checked, not assumed — traffic that bypassed the gateway lands in an explicit unattributed bucket rather than being silently smeared across projects, and the original invoice data stays immutable underneath, the property an auditor will ask about first. From there, a rule as plain as “LLM gateway key is recon-close-tool → project: Reconciliation Automation” puts LLM spend on the same axis as every other cost in the company's AI cost base.

How do you turn allocated cost into ROI?

Join each project's attributed cost to the operational metric it exists to move, at the cadence that metric is reported — only periods where both sides have data produce a figure, no zero-fills, no fabricated ratios.

Return to the reconciliation tool with illustrative numbers. The recon-close-tool key shows a build phase — three months of heavy token consumption while the team iterated — followed by a steady run rate of roughly $1,900 a month in allocated, invoice-true LLM spend. The tool saves 38 hours of close work a month. That is about $50 of LLM spend per hour saved, against a fully loaded finance-team hour that costs several times that. Now the CFO's three questions have answers with denominators: the build cost is the sum of the key's allocated spend through launch, the run cost is the monthly allocation, and the keep-paying decision is a one-line comparison that gets re-checked every close — the same unit-economics logic the company applies to customer-facing AI.

One discipline keeps the value side honest: measure the hours; don't survey for them. In a 2025 randomized trial by METR, experienced developers took 19% longer on tasks with AI coding tools while believing the tools had made them 20% faster — a small study, but a pointed caution against booking self-reported savings.

Why can't a spreadsheet or a cost tool close this loop?

The arithmetic above fits in a spreadsheet — for one provider, one gateway, one month. It stops fitting the first time a second team ships AI, a second provider is added, or the residual needs explaining at close: costs arrive scattered across model providers and buried in cloud bills, classifications change and have to reapply retroactively, and finance needs the number on the dashboard to equal the number on the invoice every single day, with an audit trail behind it.

The instinct is then to reach for a cost tool — a FinOps or cloud-cost platform. Those tools are genuinely good, but they answer a different question. They tell you what you spent; they were never built to tell you what it bought, because they have no concept of a value denominator. That boundary is the whole subject of FinOps vs AI Value Management, and it is why the four categories of AI ROI tooling are not substitutes for one another. LLM-observability tools have the opposite problem: they are built for engineers debugging latency, not for finance defending a margin.

What does measuring internal AI ROI actually require?

Three things a spreadsheet and a cost tool cannot jointly provide, and which AI Value Management exists to supply:

• Fully loaded attribution with an audit trail. Tokens across every provider — the gateway allocation above — plus the GPU, vector, and orchestration cost that serves each initiative. The model bill alone understates the truth, sometimes badly: ServiceNow's CFO could state that AI reasoning is under 10% of its cost to serve precisely because the company measured the other 90%.
• A business-metric join. The denominator — resolutions, reconciliations, seats, hires — imported and divided in, so the output is a unit cost rather than a spend total.
• Daily reconciliation to the P&L. Attributed spend tied to provider invoices every 24 hours, so the ROI survives close.

That is the job COGScontrol does — finance, support, HR and IT on one ledger. Register a LiteLLM gateway once, with a read-only spend key — it can see usage and nothing else — and COGScontrol turns one provider bill into a per-project ledger, reconciled to the cent. When the board asks what this quarter's AI spend bought, the answer is a number and a denominator per initiative, not a roadmap and an anecdote. Run your own figures through the AI unit economics calculator, or see the full system on the features page — pricing is a fixed subscription, never a percentage of your AI spend.