# AI Portfolio Rationalization That Finance Can Run

Published 2026-10-08 · Brian Diamond

Track: finops

Segment: strategy

A $180,000 monthly AI bill is not necessarily a spending problem. It is often an ownership problem. When finance receives invoices from cloud platforms, model providers, and AI gateways without a clear view of the teams, agents, and business processes behind them, cost control becomes guesswork. AI portfolio rationalization gives that spend a business structure before leaders start cutting tools or freezing adoption.

The goal is not to reduce the number of AI vendors at any cost. It is to determine which AI capabilities are producing measurable value, who owns their costs, where duplication exists, and which commitments the business can support. That distinction matters. A finance team that cancels a seemingly redundant model contract may reduce an invoice while disrupting a production workflow. A platform team that consolidates too early may trade vendor sprawl for a single, expensive dependency.

A rational portfolio is one that can be explained in operating terms and booked in financial terms.

## AI Portfolio Rationalization Starts With Ownership

Most organizations begin with a vendor inventory: model providers, cloud AI services, embedded AI features in SaaS applications, vector databases, gateways, and internally built agents. That inventory is necessary, but it is not yet a portfolio view.

A portfolio view connects each spend source to a business owner, a technical owner, a cost center, and a defined use case. Without those four fields, a line item is just a bill. With them, the organization can ask better questions: Is this capability still in use? Is the same function being purchased elsewhere? What cost should be charged to the business unit receiving the benefit? Does the use case have an expected unit cost or margin impact?

Consider a company paying for three ways to summarize customer calls. Customer Success uses a SaaS platform with embedded AI. Sales Operations has built an internal workflow using an LLM API. Product is testing a separate agent through a cloud AI platform. The right answer may be consolidation, but not automatically. The embedded feature may be low-effort but difficult to attribute. The internal workflow may be cheaper per call but require engineering support. The product pilot may be strategically important despite its current cost.

Rationalization makes those trade-offs visible. It does not assume that the lowest model price is the best financial outcome.

### Separate the portfolio into capabilities, not invoices

A vendor-centered inventory can hide overlap because one provider may support several valid use cases, while one use case may run across several providers. Organize the portfolio around capabilities such as document processing, customer support assistance, sales research, software development support, or internal knowledge retrieval.

Then identify the systems and agents delivering each capability. A single customer-support agent, for example, may generate costs from a model API, cloud compute, retrieval infrastructure, observability tooling, and a gateway. If finance allocates only the model invoice, it understates the true cost of serving that workflow.

This also prevents a common mistake: treating all AI spend as one corporate technology expense. An agent that processes insurance claims or support tickets is closer to an operating cost of that business process than to a generic IT overhead charge. It should be managed accordingly.

## A Practical AI Portfolio Rationalization Process

The process works best when finance, procurement, platform engineering, and AI program leaders share a common operating model. Finance should not be expected to interpret token logs, and engineering should not be asked to invent accounting policy alone.

### Build a complete spend and usage baseline

Start with the last three to six months of invoices, cloud billing exports, procurement records, expense reports, and gateway data. Include committed spend, usage-based charges, credits, and embedded AI fees where they can be identified.

For each source, capture the contract owner, invoice entity, renewal date, service category, and total monthly cost. Then attach available operational data: requests, tokens, compute hours, agent runs, documents processed, or users served. The exact meter depends on the service. The important point is to preserve the relationship between cost and consumption.

Do not wait for perfect data. It is normal to find untagged API keys, shared service accounts, and costs that cannot initially be assigned below the company level. Label those costs as unallocated rather than forcing a false allocation. An unallocated bucket is a useful management signal. It tells leaders where instrumentation and ownership are missing.

### Assign direct costs first, then allocate shared costs

Direct attribution should be the default. If an API key is used exclusively by the Revenue Operations agent, its variable model and gateway costs should be assigned directly to Revenue Operations. If a cloud project serves only one product team, its AI infrastructure costs should follow that project.

Shared costs require an [allocation rule](https://www.onaro.io/blog/ai-agent-chargeback-allocating-agent-spend) that reflects the benefit received. For a shared gateway, request volume may be reasonable. For a company-wide internal assistant, active users or measured usage may be better. For a shared retrieval platform, indexed documents, query volume, or business-unit usage may be more defensible depending on the architecture.

Consistency matters more than theoretical precision. A controller should be able to explain why the method was chosen, how often it is reviewed, and what data supports it. If the method changes, document the reason and effective date.

For example, suppose a shared AI platform costs $48,000 per month. Engineering accounts for 50% of measured requests, Customer Support 30%, and Legal 20%. The monthly allocation could be recorded as:

\`\`\` Dr. AI Expense - Engineering $24,000 Dr. AI Expense - Customer Support $14,400 Dr. AI Expense - Legal $9,600 Cr. Shared AI Platform Clearing $48,000 \`\`\`

The entry is simple. The evidence behind it matters more: request data, the allocation policy, named cost-center owners, and a reconciliation to the vendor invoice.

### Evaluate value at the use-case level

Once costs are assigned, evaluate each capability against an outcome that business owners recognize. For a support agent, that may be cost per resolved ticket, containment rate, or reduction in handling time. For a document-processing workflow, it may be cost per document processed and error rate. For a sales workflow, it may be cost per qualified account researched, paired with evidence that the output is actually used.

Not every use case needs immediate revenue attribution. Internal knowledge tools can provide real value through faster work and reduced rework. But they still need a stated hypothesis, a responsible owner, and a spending threshold. “Employees like it” is not sufficient governance for an expanding usage-based cost.

This is where rationalization decisions become clearer. Keep and scale use cases with [measurable value](https://www.onaro.io/blog/ai-roi-measurement-case-study) and controllable unit economics. Consolidate duplicate capabilities where one option meets business requirements. Renegotiate commitments that are consistently underused. Retire pilots without a sponsor, a usage base, or a credible path to production.

### Treat commitments differently from variable consumption

Many AI budgets fail because they mix fixed commitments and variable usage into one number. A committed annual platform fee behaves differently from model consumption that can double after a successful product launch.

Budget these components separately. Assign fixed platform costs using a stable allocation basis, such as planned headcount, active business units, or an agreed service model. Forecast variable costs from operational drivers: tickets, documents, transactions, agent runs, or customer activity. Then test the forecast against volume scenarios.

If a customer-support agent costs $0.18 per handled interaction at current volume, calculate what happens at 1.5 times and 2 times the volume. Include model costs, gateway fees, supporting cloud services, and any human review required for exceptions. That gives FP\&A a forecast tied to business activity rather than a vague technology growth assumption.

## Put Governance Into the Monthly Operating Rhythm

Portfolio rationalization is not a one-time procurement exercise. AI usage changes quickly as teams add agents, switch models, alter routing logic, or move pilots into production. A quarterly vendor review alone will miss the financial impact.

Set a monthly cadence that reconciles billed costs to metered usage, reviews unallocated spend, checks budget variance by cost center, and flags material changes in unit cost. The meeting should produce decisions, not just dashboards: assign an owner to an untagged workload, revise an allocation method, adjust a budget, or stop a low-value service.

Controls should match the size and risk of the spend. A small experimental project may need a named owner and a modest [budget alert](https://www.onaro.io/blog/ai-agent-budgets-alerts-and-spend-policies). A production agent affecting customer operations may require approval thresholds, documented allocation logic, usage monitoring, and retained evidence for finance and audit review. The point is not to slow experimentation. It is to ensure that experimental spend has an exit decision before it quietly becomes permanent overhead.

A platform such as Meridian can help automate the metering, allocation, and financial handoff, but the operating decisions still belong to the business. Technology can identify that an agent consumed a given amount of model spend. Finance and business leaders determine whether that cost is acceptable, where it belongs in the ledger, and what outcome it must support.

The healthiest AI portfolio is not the smallest one. It is the one where every meaningful dollar has an owner, every shared cost has a defensible method, and every scaled use case can explain the value it is expected to create.

Onaro Meridian is [FinOps for agentic AI](https://www.onaro.io/finops-for-agentic-ai): the system of record that attributes, controls and books what AI agents spend.

Canonical: https://www.onaro.io/blog/ai-portfolio-rationalization