Read your AI bill like a finance person reads payroll

Most teams treat their AI bill the way they treat their AWS bill in 2014 — as a single line item that "just is what it is." Engineers ship, the bill arrives, finance pays.

This is how you lose control of a budget line that's going to be one of the top 3 software expenses by 2027.

Here's how to read your AI bill the way a CFO reads payroll. Same discipline. Different inputs.

Break it down by service first

Pull your AI invoices from the last 90 days. List every service touching them. Common categories:

→ Direct LLM API (OpenAI, Anthropic, Google) — usage-based → AI-flavored SaaS (Otter, Crayon, Intercom Fin, etc.) — subscription → AI agent platforms (Lindy, Relevance AI, etc.) — usage or subscription → AI coding tools (Cursor, Copilot) — subscription → AI research tools (Perplexity Pro, ChatGPT Team) — subscription

Sum the categories. Calculate % of total software spend. The number is usually higher than people expect because each line was approved separately.

Categorize by purpose, not vendor

The vendor breakdown is just the first cut. The more useful breakdown is by what work the AI is doing:

→ Conversational (chat with employees or customers) — chatbots, copilots, internal assistants → Operational (recurring work happens on schedule or trigger) — agents, automations, AI workflows → Augmentative (helps individual employees do their work) — AI editing, AI coding, AI research

These three categories have very different cost structures and very different optimal architectures.

→ Conversational: usage scales with employee count + interaction frequency → Operational: usage scales with workflow volume (often LARGER than expected) → Augmentative: usage scales with employee count + work intensity

Once you've categorized, the optimization paths become clear.

Identify the cost runaways

For each line item, calculate cost per unit of work:

→ For LLM APIs: $/1K tokens, then $/task type → For SaaS: $/seat or $/usage unit, depending on plan → For agent platforms: $/agent execution

Most teams discover one or two lines where cost-per-unit is much higher than expected. Common culprits:

→ Cloud LLM agent platforms charging $0.05-0.30 per execution for tasks that should cost cents at most → AI-flavored SaaS pricing that scales with usage in ways the contract didn't make explicit → Multiple tools doing overlapping work (e.g., two products both doing meeting transcription)

Flag these. They're where the savings will come from.

Map the data flow

For each AI tool, document:

→ What data goes IN to the tool (customer PII, employee data, financial data, etc.) → Where the data gets processed (their cloud, your cloud, your laptop, an LLM provider's cloud) → Who has access to logs → How long data is retained → Whether the data is used to train models

This is the conversation your security team should already be having. If they're not, you have an AI governance gap that will become a problem.

The data flow map also informs cost optimization: if certain data flows would be cheaper or more compliant when processed locally, you have a candidate workload to migrate.

Calculate the migration math

For each line where cost-per-unit is high OR data flow is sensitive:

→ Cost to switch: license fees + setup time + retraining + risk of disruption → Annual savings: current cost - alternative cost → Payback period: cost to switch / monthly savings

Workloads with payback under 6 months are no-brainers. Workloads with payback under 12 months are usually worth the switch. Workloads with 12+ month payback should wait.

The local migration candidates

Operational AI workloads — agents that run on schedule, classification, extraction, drafting, summary — are the easiest to migrate to local because:

→ Tasks are well-defined (specialized small models do them well) → Volume scales (cost predictability matters more) → Data is often sensitive (privacy posture matters)

For these workloads, the local migration math usually penciled out fast in 2025. In 2026, it's overwhelming.

What "reading your AI bill" should produce

The output of this exercise should be a short document (1-2 pages) showing:

→ Total AI spend, % of software spend, trend over time → Breakdown by category (conversational / operational / augmentative) → Breakdown by cost per unit of work → Data flow map for each line item → Migration candidates with payback period → Recommended optimization path

This is the document a CFO can act on. Without it, AI is a black box. With it, it's a managed expense.

The bigger frame

In 2024, AI was a "let's try this" experiment. Budgets were forgiving.

In 2026, AI is a permanent operating expense. The discipline that finance teams have applied to other expense categories for decades needs to be applied here.

The teams that build this discipline early will:

→ Avoid 2-3x cost overruns that hit teams that didn't audit → Make informed architectural choices about cloud vs local → Build budgets that scale with business, not with token usage → Have answers when auditors / customers / executives ask hard questions about AI

The teams that don't will look back in 2 years and wonder how the AI line got so big.

Where Avery NXR fits

We built Avery NXR for the operational category specifically. Flat cost per user, local AI by default, audit ledger for governance, data stays where you put it.

It's not the right tool for every workload. (Conversational AI? Use a chatbot platform. Augmentative AI? Use copilots designed for that.) But for the operational layer — recurring workflows that need to happen reliably and cheaply — it's what we'd recommend.

→ avery.software — Free Desktop tier. The operational AI workload that's eating your AI budget? Migrate it and measure.