July 3, 2026 · 8 min read · Finance operations
How to file AI costs in your books
AI spend arrives as five different kinds of charge. File them all in one "Software" line and there is no question about AI you can answer without rebuilding the numbers by hand.
Here is what a single software line cannot tell you. How much of next quarter's AI bill is fixed. How much floats with use. How much of it is the cost of delivering your product. And which team caused the rise. Four questions, four splits — and all four have to exist before the charges land. Rebuilding them later means a spreadsheet that rots the day its author changes jobs.
Accountants call the list of buckets you file costs into a chart of accounts. Yours probably has a single bucket labeled Software, and that is the problem. The fix is small: five splits and one tag, mostly sub-buckets and labels inside books you already keep. A quarter of work, not a systems project.
Five splits
1. Fixed seat cost, apart from usage cost that floats
A seat is a paid license for one person. Seat cost and usage cost behave nothing alike, and they need different controls. Put them in one bucket and neither one can be forecast.
Seat cost moves in steps. It changes when headcount changes or when a license gets handed out. You can know it to the dollar a quarter ahead, and you control it by controlling license count. Usage cost floats with how hard people work the tools, and it has no ceiling unless you build one. An agent that retries hard can move the line further in a week than hiring moves it in a quarter.
The same vendor often bills both ways. GitHub Copilot Business is $19 per user per month, with overage at $0.01 per credit. Claude Code sells seats and burns tokens — a token is the unit AI vendors bill for, roughly a few characters of text — with observed all-in costs of $150–250 per developer per month. In one bucket you cannot tell whether a rise came from hiring or from a runaway loop. So you cannot tell whether the fix is a headcount conversation or an engineering one. Pricing by use has its own traps, and this split is what lets you catch them.
Control follows the split. Cap the fixed line with headcount, and set up tracking and alerts on the floating one.
2. AI cloud costs, apart from AI apps
Cloud AI is Bedrock, Vertex, Azure OpenAI and models you run yourself on GPU machines. Apps are Copilot, Cursor, ChatGPT Business and the rest of the subscriptions.
Three reasons to keep them apart. Cloud AI arrives inside a cloud bill and gets swallowed by "Cloud — Compute" unless you tag it at the source, after which it is invisible as AI spend forever. The owner is different too: platform engineering, not the tooling budget. And the deals are different, with committed-use discounts on one side and seat contracts on the other. A blended "AI spend" total gives you a size and nothing you can act on.
Models you run yourself split again. GPU hours are a cloud cost. The engineering time to run them is an operating cost, meaning a day-to-day running cost rather than a cost of delivering your product. Otherwise "we host it ourselves, it is cheaper" is a claim nobody can check.
3. AI your staff uses, apart from AI you sell
The most common mistake, and the most damaging.
AI you sell — the model calls that run when a customer uses your product — is cost of goods sold. That is what it costs you to deliver the product, and it sits inside gross margin. AI your own staff uses is an operating cost, and it sits outside gross margin. Mixing the two corrupts margin reporting in both directions.
Put internal tools into cost of goods sold and your gross margin moves because engineering bought more Cursor seats. Nonsense — but nonsense that gets discussed in a board meeting. Leave customer-facing model calls in operating costs and you overstate gross margin, the version that matters to investors, auditors and eventually a buyer. Report it that way for three quarters and correcting it becomes a restatement.
The hard cases are real: an internal tool that also powers a customer feature, or one API key serving both. The only clean fix is to split at the source, with separate API keys or vendor projects per purpose, set up that way from the start. Not a percentage applied at close. Split percentages are guesses that harden into policy. Attributing API costs at the key level is the same mechanism that makes this split work.
Mixing the AI you use with the AI you sell does not just misfile a cost. It moves your gross margin for reasons that have nothing to do with your product.
4. Owning team, as a tag rather than a bucket
Do not build teams into the bucket structure, or you will have a hundred buckets by next year. Use a tag, applied at the source: project tags on API keys, cost centers on card issuing, department on license assignment.
The reason is durability. Spend matched to teams inside a spreadsheet, rebuilt each month from a vendor export, lasts exactly as long as that person's patience. Put the tag on the charge instead and per-team and per-engineer numbers fall out of the books at close.
5. Card spend and shadow AI, flagged on their own
Shadow AI — AI tools bought on personal cards, outside of purchasing — needs its own flagged bucket until it moves onto a contract. The reason is specific.
Move a dozen retail seats onto a company plan and the company-plan bucket jumps. If that spend was never in the bucket before, the jump reads as growth. It is really a re-filing, and it usually comes with a *drop* in total cost. Without the flag you are explaining a fake increase to someone with every reason to doubt you. Finding that card spend is its own exercise. Give it a home in your books before you start.
Retire the flag once the move is done. It is temporary, not permanent.
The mechanics that break it
Vendor names, put in the same format as you read them in. One vendor bills under several names — a merchant string, a version with a payment processor's prefix, a legal entity name on the invoice — plus whatever a reseller or marketplace adds. Collapse them into one standard vendor ID with an alias table, as the data comes in, before you file it. Do it in the report instead and each report does it slightly differently. That is worse than not doing it at all, because the mismatch is invisible.
Usage billed after the fact. Usage in one month gets invoiced the next. Record it only when the cash moves and you understate one month, spike the next, and stay off by a period forever. Instead, record the cost in the month it happened, before the bill arrives, using the vendor's usage API at period end. Then adjust it to the real number when the invoice lands. If usage data is not ready at close, use a trailing average and write the method down. An estimate with a written basis can be audited. An unexplained one cannot.
Money paid up front for future usage. Committed spend and credit purchases are prepaid assets. Prepaid means you paid before you used it, so it sits as an asset and you spread the cost over time as it gets consumed, rather than expensing it the day you buy. Two things to watch. Credits that expire unused are a write-off, and that number is worth reporting on its own, because it is the clearest sign a commitment was too big. And spreading the cost by consumption needs a usage feed. Without one you will spread it evenly, which quietly defeats the first split.
Capitalizing, with care. To capitalize a cost means to spread it across future years instead of expensing it now. Whether any part of AI tooling or AI development cost qualifies as internal-use software is a live question, and the answer depends on facts a blog post cannot see. What stage the work is in. Whether you are buying a subscription or building software. How your existing policy reads. Treatment varies a lot between companies with similar-looking spend. This is a conversation with your auditors, and any vendor that answers it confidently without seeing your facts is guessing.
What your chart of accounts should do is make the question *answerable*. Keep costs separable by purpose, project and stage, so whatever treatment you land on applies without re-cutting a year of history.
What the structure buys you
A forecast that separates the line you control from the line that floats. Fixed seat cost projects off the hiring plan. Usage cost projects off a usage trend with a stated confidence band. Two methods, two error bars, one total — instead of a blended number that is wrong in a direction you cannot diagnose.
A per-engineer figure you can compare quarter to quarter, as long as the number you divide by holds still. Define it as engineers covered, not total headcount, write the definition down, and do not change it. It is also the only way a benchmark means anything. DX puts total cost per engineer at $200–600 per month for teams mixing inline and agent tools — a 3x spread on its own, and one that describes other teams, not yours. You cannot tell where you sit in it until your own books are cut cleanly.
And a defensible AI cost report — one page that shows what your AI tools cost and what you get back. Cledara's live data puts AI at 16.9% of total software budget as of July 2026. That is large enough that "it is in Software" has stopped being an acceptable answer. Deloitte's CFO guide to AI token economics argues the same from the governance side. A sample report shows what the cut-up version looks like.
The honest caveats
This is a structure, not a policy. It does not tell you which costs are a cost of delivering your product. That follows from how you recognize revenue and how your auditors see it, and reasonable companies land in different places. The split between what you sell and what you use gets genuinely hard with shared API keys, and splitting at the source is the only clean fix — which costs engineering time nobody budgeted. Costs booked from a trailing average will be wrong each month and roughly right each quarter, so disclose the method. Restating history is rarely worth it. Apply this going forward and accept a labeled break in the series. And per-engineer comparisons break the moment someone redefines the number you divide by.
Keep reading
- What an AI cost report is, and how to build one — what sits on the page once the buckets are cut
- How to attribute OpenAI and Anthropic API costs to teams — key-level mechanics for the team tag
- How to forecast next year's AI budget — projecting the fixed and floating lines
- Finding shadow AI spend on the company card — filling the card bucket
Find your recoverable AI spend
Before you cut new buckets, see what is in the old one — seats, tokens, cloud and card charges, all filed under one vendor name. Snapshot shows it as a one-page AI cost report, read-only, with the source labeled on every line.
`Start free` → /login?src=blog_ai-spend-chart-of-accounts
Find your recoverable AI spend
Spendassay turns this from an afternoon of spreadsheets into a live, proof-level audit with the recovery attached.