Token spend is usually a symptom. The causes and the fixes sit in the value creation tree, not on the invoice. Portfolio companies have committed real money to AI: seats, API consumption, platforms and a center of excellence. Sponsors expect that spend to appear in the EBITDA bridge within the hold period. Most programs, however, report cost per token and adoption, and neither is a measure of value.
When the bill rises, leaders ask to cut token cost because it is the line item they can see. Token cost is the product of three factors: calls, tokens per call and price per token. Only the last is a pricing problem. In the illustrative composite case that runs through this report, price explains 17% of spend growth; call volume and context bloat explain the other 83%.
Return on Transformation Investment (RTI) closes that gap in three moves:
- One number at the top. RTI divides economic contribution, net of the costs to achieve it, by the total transformation investment. Revenue, cost and capital are its three branches, and AI is a lever inside each, never a branch of its own.
- A measurable driver under every claim. Each lever rolls up through an operational driver that already exists as a field in a system of record (minutes per invoice, turnaround days, win rate), owned by a named tier of leadership.
- One loop for every leadership ask. Each complaint ("cut the API bill", "we are not seeing the return") is routed to a node in the tree, diagnosed with a defined data pull, resolved with an action set and proven with a driver that moved against a baseline.
Applied to an illustrative $420M aerospace component MRO, the approach moves a $2.4M AI program that nobody could place in the bridge to $3.9M of net run-rate contribution, an RTI of 2.0x on the year-two investment, while the program's own run-rate cost falls from $2.4M to $0.8M.
The punchline is simple: manage AI where value is created, not where it is invoiced.
Why is AI value so hard to see?
Portfolio companies buy AI on a promise of productivity and then manage it on an invoice, which breaks the link between spend and value. In our experience the pattern repeats across functions and sectors, and it has three stages.
- What gets funded. A business case built on self-reported "hours saved" and vendor benchmarks. Seats bought by function, API access granted broadly, pilots that proliferate. No baseline captured for the transaction the AI is meant to change.
- What gets measured. Monthly API and seat invoices by vendor; tokens consumed, prompts submitted and active users; occasionally a survey of perceived time savings.
- What the sponsor asks. "Where is it in the bridge?" "Why did the bill double when usage went up 30%?" "Cut AI spend 40% and keep the savings."
Those questions cannot be answered with what was measured, because three structural pieces are missing.
| Missing piece | What it looks like | Consequence |
|---|---|---|
| A unit of value | AI cost is tracked per token or per seat; value is asserted per program | Spend and value cannot be compared, so every cut is a guess |
| An attribution rule | Savings are claimed from surveys, not from a transaction metric that moved against a baseline | Bridge items are challenged and removed in diligence or by the board |
| An architecture view | Model choice, orchestration design and context size are engineering decisions invisible to finance | The largest cost drivers never reach the agenda; only price per token does |
Cost lands in one place; value scatters across operations, finance and sales. Until each dollar of AI spend is tied to a driver that finance already trusts, every conversation about AI returns to the one number on the table: the invoice.
How does RTI connect a lever to a return?
RTI is a value creation tree: one ratio at the top, three additive branches beneath it, and a measurable operational driver under every claim. The structure borrows from the classic sales force productivity tree, where each leader owns one ratio and the ratios multiply to a single number nobody can dispute: utilization × leverage × rate × margin collapses to contribution ÷ selling cost because the middle terms cancel.
RTI keeps three things from that model: a single top ratio with a defensible numerator and denominator, one ratio per leadership tier, and explicit tension between levers so trade-offs stay visible. It changes three things. The top of the tree is enterprise value, not AI. The first level is additive, because revenue, cost and capital do not share a unit. And every operational driver is a literal field in a system of record, not a concept.
Level 0: the return
RTI = (Revenue contribution + Cost takeout + Capital released × cost of capital − Costs to achieve) ÷ Transformation investment
Every term in the numerator is an annual flow. Revenue enters as incremental gross margin, not revenue. Capital enters as a capital charge: $10M of inventory released at a 10% cost of capital adds $1.0M a year. The one-time cash released is reported beside the ratio, in a cash view for the sponsor, rather than inside it. The denominator holds the full investment: AI and tooling (API, seats, platform), people and change (center of excellence, human review, training) and any capital projects.
Level 1 to level 3: from branch to operational driver
| Branch (level 1) | Operational drivers (level 2, examples) | Fields that prove them (level 3) | Source systems |
|---|---|---|---|
| Revenue contribution | Win rate, quote velocity, realized price, attach rate, retention, throughput and turnaround time | Opportunity stage and close date; quote and order timestamps; invoice price against list; work-order induction and ship dates | CRM, CPQ, ERP, MES |
| Cost takeout | Labor cost per transaction, FTE by function, material cost, quality cost, overtime and contractors | Timesheet hours by activity; transaction counts; PO price against standard; NCR and rework hours; payroll overtime | HRIS, ERP, ticketing, QMS |
| Capital released | Inventory days, expedite cost, DSO, DPO, asset utilization | On-hand quantity and unit cost; premium PO flags; invoice, due and paid dates; machine run hours | ERP, WMS, AR and AP aging, CMMS |
Four design rules keep the tree defensible
- Additive at level 1, multiplicative below. Branches add in dollars; inside a branch, ratios chain on a shared unit (hours, transactions, tokens). That allows a return per lever while terms still cancel inside each lever.
- One home per driver. Every measurable field rolls into exactly one level-2 ratio, so the same saving is never counted under labor and again under AI.
- Contribution is net. Human review, rework, licenses and change management are subtracted before a number reaches level 1. This is where most AI ROI claims fail diligence.
- AI is a lever, not a branch. AI contribution is recognized only through a business driver that moved. The AI cost branch prices the lever; it never creates value on its own.
Efficiency and effectiveness live inside this structure rather than beside it. Faster cycle times and fewer touches count only when the capacity is harvested (overtime, contractors or hiring removed) or redeployed into a revenue driver. Capacity created but not yet captured is reported on its own line, beside the ratio: it is the clearest measure of AI value leaking away.
What actually drives the AI bill?
How AI is deployed drives most of its cost, and every deployment driver is measurable and has an owner. The bill itself decomposes into three factors:
Token cost = Calls × Tokens per call × Price per token
Each factor maps to a different node of the tree and a different fix.
| Factor | Tree node | Typical finding | Controlling driver |
|---|---|---|---|
| Calls | Utilization: demand and waste | Calls per completed task more than double once agents are introduced; retries climb past 10% | Orchestration design, retry caps, tool-first resolution |
| Tokens per call | Utilization: context hygiene | Input tokens per call grow several-fold as every schema and skill loads on every call; cache hit rates stay low | Context loading policy, caching, retrieval caps |
| Price per token | Capacity leverage | Most tokens run on the frontier tier, including classification and extraction tasks a smaller model handles well | Model routing by task class, committed-use pricing, batch processing |
In the illustrative case, price explains 17% of spend growth and the other two factors explain 83%. A price-only response, such as renegotiating rates or switching vendors, addresses less than a fifth of the problem. That is why a token complaint routes to utilization before it routes to price.
Six deployment drivers, each with a measure and an owner
| Driver | What good looks like | Measures | Tree node |
|---|---|---|---|
| Model routing | Small models for classification, extraction and formatting; frontier models only where evals prove the need | Frontier token share; tokens by task class and model; eval pass rate by tier | Capacity leverage |
| Orchestration | Deterministic code where inputs are structured; few LLM hops; the orchestrator plans and small workers execute | LLM hops per task; orchestrator-to-worker token ratio; share of steps done in code | Utilization |
| Tools and skills | Tools resolve facts and the model formats them; schemas and skills load on demand, not by default | Tool-call success; context tokens from schemas per call; tasks resolved by a tool | Utilization |
| Context hygiene | Stable prompts cached; conversation state compacted; retrieval capped | Input tokens per call; cache hit rate; turns to completion | Utilization |
| Demand shaping | Every call tied to a business transaction; no-action calls surfaced; idle seats reclaimed | Calls per transaction; share of calls with no downstream action; active-to-licensed seats | Utilization |
| Quality gates | Evals per use case with acceptance thresholds; sampled human review | First-pass acceptance; review hours per output; incident count | Contribution margin |
Each row is an action plan waiting to be written: the measure is the baseline, the "good" column is the target, and the tree node is where the result is recognized.
Where value erodes between spend and contribution
A dollar of AI spend loses value at four points before it reaches the P&L. Utilization losses come first: retries, discarded output and calls no one acts on. Value yield losses follow, when productive work never moves an operational driver because no baseline or owner exists. Contribution margin losses are the human review, rework and incidents that consume the gain. Capacity leverage sets the price paid for whatever survives. Each erosion point is a node in the tree, which is what makes it possible to recover.
When does AI value count?
Two attribution rules protect the bridge: value is recognized only through an operational driver that moved against a baseline, and costs to achieve are netted before anything rolls up.
Rule 1: value flows through a driver, never from a survey
- Each funded use case names exactly one owning operational driver: minutes per invoice, turnaround days, win rate.
- A baseline is captured before deployment, typically 8 to 12 weeks of that driver for the same transaction type.
- A control exists: a pre-period, an untreated cohort or a staged rollout.
- Movement is priced at the rate the CFO already uses: loaded labor rate, gross margin or cost of capital.
- Self-reported "hours saved" are logged as leading indicators only. They never enter the bridge.
Rule 2: net, not gross
Human review hours, rework and incident remediation, allocated licenses, API, platform and center-of-excellence time, and first-year change management are all deducted. Gross, costs to achieve and net are reported for every use case, so the sponsor sees the full stack while only the net number rolls up.
One use case from the illustrative case shows the arithmetic.
| Line | Basis | Annual value |
|---|---|---|
| Gross saving | 41,000 invoices × (14.2 − 5.9 minutes) × $48 per loaded hour | $272k |
| Less human review | 15% sampled × 2.1 minutes × $48 per hour | ($10k) |
| Less rework and exceptions | 3.4% exception rate × 22 minutes × $48 per hour | ($25k) |
| Less allocated AI cost | API $31k + seats $18k + center-of-excellence time $22k | ($71k) |
| Net contribution recognized | Requires a 1.9 FTE redeployment plan executed by month 6 | $166k |
Every line ties to a system field or an invoice, the FTE action is named, dated and owned, and the gross number is visible while the net number is what counts. That is why it survives diligence.
Where it lands on the statements
Cost takeout and revenue contribution land on the P&L, and in a PE context they are valued at the exit multiple. Capital released lands on the balance sheet. Cash is worth one dollar per dollar rather than a multiple, but working capital is often the fastest lever in the first 100 days, which is why the cash view sits beside the ratio. AI's contribution to capital is almost always indirect, through a better forecast or faster dispute handling, so it must be attributed through the driver, never asserted.
Savings exist only when the FTE, contractor or overtime line moves. Minutes per transaction is the leading indicator; headcount is the bridge item.
Where should the work start?
With the question leadership is already asking. The playbook runs one six-step loop for every ask:
- Intake. Capture the leader's statement verbatim and the number they are reacting to.
- Route. Decompose the number (calls × tokens × price, or contribution ÷ investment) to find which factor moved, and assign the tree node.
- Data pull. Run that node's standard extracts: gateway exports by use case, model and token type; transaction metrics from the system of record; HRIS and AP.
- Diagnose. Compare against what good looks like and rank drivers by dollar impact and ease.
- Act. Select from the node's action library, and name the owner, baseline, target and date.
- Prove. Track the operational driver weekly, recognize contribution net of costs to achieve, and roll it into the bridge.
Six asks recur so often that each has a standard route through the tree. The outcomes shown are from the illustrative case.
| The ask | Where it routes | What resolves it | Illustrative outcome |
|---|---|---|---|
| "Reduce our token expenses." | Utilization first (context, waste), then capacity leverage (price) | A routing table by task class, caching stable prompts, loading skills on demand, batch processing, retry caps; committed-use pricing last | API spend down 41%, from $1.1M to $650k; acceptance up from 71% to 76% |
| "We're not seeing the return." | Value yield and contribution margin, then adoption | Attach every use case to one driver with a baseline; pause any that cannot name one; embed AI in the workflow; date the FTE action | Six use cases become four; $1.9M net contribution |
| "Spend grows faster than usage." | Utilization: orchestration and context | Move parsing and validation into code; plan once, execute lean; cap iterations; compact history | LLM hops per task from 5.1 to 2.0; tokens per completed task down 54% |
| "Cut opex 20%, and AI should help." | Cost takeout: labor cost per transaction and quality cost | Prioritize by hours × volume; set minutes-per-transaction targets; publish labor plans per function | AI-enabled processes deliver $3.3M of a $10M program |
| "Our AI program is a mess of tools and vendors." | The investment denominator and capacity leverage | One gateway, tagging at call time, one seat product, two vendors on committed rates | Vendors from 4 to 2; $310k saved; gateway coverage from 62% to 100% |
| "Quality and risk are eating the savings." | Contribution margin: review, rework, incidents | Evals per use case; structured outputs; facts looked up by tools, never generated; sampled review above threshold | Acceptance from 71% to 89%; review hours from 6,400 to 1,900; incidents to zero |
The gateway consolidation in the fifth ask produced the smallest direct saving and made every other result measurable. Enabling actions rarely win on their own numbers, which is why the sequence matters as much as the list.
What does RTI look like end to end?
An illustrative composite case shows the full path from an unplaceable AI cost to a defensible return. The company is constructed for teaching; its figures are indicative, not actuals.
| Profile | Detail |
|---|---|
| Business | PE-backed aerospace component MRO and repair development; 4 sites, about 1,900 employees; airline and lessor customers |
| Financials | Revenue $420M; EBITDA $38M (9.0%); the sponsor case targets $65M (15%) at exit in 24 months |
| Value creation levers | Turnaround time and throughput; labor productivity in the shop and back office; procurement and inventory; pricing discipline |
| AI program | 18 months old; $2.4M run rate: API consumption $1.1M, seats $0.6M, platform and gateway $0.3M, center-of-excellence staff $0.4M |
| Use cases | Work-order narratives, quote generation, supplier email triage, technical-publications Q&A, AP invoice coding, customer status replies |
| Reported results | A survey of 6.2 hours saved per user per week; no transaction metric finance accepts had moved |
At the 18-month review the sponsor asked four questions. Which use case has produced a line in the bridge? Why did API spend grow 2.1x while active users grew 1.3x? If AI spend is cut in half, what is lost? What would it take to get $4M of run-rate EBITDA from the program? A new CEO and CFO, 60 days into the role, had 100 days to show run-rate savings and nine months to show them realized.
The diagnostic
The gateway and billing export answered the second question before any interview.
| Indicator | The case | Reference range |
|---|---|---|
| Input share of spend | 74% | 45–55% |
| Cache hit rate | 14% | 50–70% |
| Frontier token share | 68% | 20–35% |
| Discarded output | 22% | Under 8% |
| Retries per call | 11% | Under 3% |
| Calls per completed task | 5.1 | 1.5–2.5 |
| Active-to-licensed seats | 59% | Over 85% |
| First-pass acceptance | 71% | Over 85% |
Quote generation and work-order narratives drove half the spend and ran almost entirely on the frontier tier, including the classification and extraction steps inside each workflow. It was a context and routing problem before it was a price problem.
The resolution
Worked through the tree and all six asks, the program moves from a $2.4M cost nobody could place to $3.93M of net run-rate contribution on a year-two investment of $1.95M: an RTI of 2.0x. Value that survives attribution enters through labor, revenue and capital drivers; the program's own run-rate cost falls from $2.4M to $0.81M; and year-two costs to achieve are netted before anything reaches the bridge.
Who owns which number?
Each leadership tier owns one level of the tree: the executive manages one ratio, senior leaders manage contribution per lever, and use-case owners manage weekly counters.
| Tier | Owns | Reviews | Cadence | Decision rights |
|---|---|---|---|---|
| Executive (CEO, CFO, sponsor) | Level 0: RTI and bridge items | RTI; run-rate against realized contribution; total investment; AI spend as a share of investment | Monthly; board quarterly | Fund, pause or stop levers; approve FTE actions |
| Senior leaders (COO, CCO, CSCO, CIO) | Level 1: contribution per lever | Revenue, cost and capital contribution, each net of costs to achieve; return per lever | Monthly | Reallocate investment across levers; set level-2 targets |
| Function and site leads | Level 2: operational drivers | Hours per transaction, turnaround, win rate, inventory days, cost per million tokens, frontier share, adoption | Weekly | Sequence use cases; own baselines and controls; approve routing and context policies |
| Use-case owners | Level 3: counters | Minutes per task, first-pass acceptance, calls per task, cache hit rate, retries, idle seats, review hours | Daily to weekly | Tune prompts, routing and tools; escalate a counter that trends against target for two weeks |
| Platform and center of excellence | Instrumentation | Gateway coverage, tag completeness, eval coverage, data freshness | Weekly | Enforce tagging; block untagged usage; maintain the routing table |
The tree fails when a tier reviews the level below its own: an executive debating cache hit rates, or a use-case owner asked to defend RTI. Cadence and decision rights enforce the separation.
How it fits with FinOps
Most companies already run FinOps for cloud cost, and RTI extends it rather than replacing it. FinOps owns rate optimization (capacity leverage) and usage optimization (utilization) today. RTI adds the step FinOps describes but rarely reaches: quantifying business value, through value yield and contribution margin, so that chargeback is justified by contribution rather than consumption. Positioned that way, RTI is FinOps unit economics for AI: familiar vocabulary, with one branch extended to the right.
Keeping the gains
Give every lever an owner, a baseline and a target on a named line of the P&L or balance sheet. Re-read the portfolio of use cases monthly in a use-case P&L (gross, costs to achieve and net) and report RTI to the board quarterly. Retire use cases that no longer earn their consumption, and invest behind the ones that compound.
How do you start?
Instrument first, cut cost second and prove value third, because nothing later can be proven without the gateway and the baselines. The 100-day plan runs in four phases, each with milestones that prove it.
- Days 1 to 30: instrument. Consolidate to one gateway with tagging on every call; inventory every use case against an operational driver; capture baselines for the top four transactions; stand up the eval harness. Proof: gateway coverage at 100% and baselines captured by day 30.
- Days 31 to 60: cut cost. Put the routing table, caching and context policy in place; refactor orchestration on agentic use cases; finish seat and vendor rationalization. Proof: API run rate down 40% and tokens per completed task down 50% by day 60.
- Days 61 to 100: prove value. Embed deployments in the systems of record (MES, CPQ, AP) so AI is a workflow step rather than a side window; run control cohorts; publish labor plans per function; move to sampled review where acceptance allows. Proof: embedded deployments live and labor plans signed by day 100.
- Months 4 to 9: realize. Execute FTE actions; convert run rate to realized savings; report a monthly use-case P&L to the board. Proof: first realized savings in the P&L by month 6, and RTI reported to the board by month 9.
The sequence is the point. Gateway consolidation delivers the smallest direct saving of any action, yet without it, none of the cost or value results can be measured, let alone defended in front of a board.
All case figures are from an illustrative composite case constructed for teaching; they are indicative, not actuals.
