Token Maxing is Eating Your AI ROI
Finance teams can’t opt out of AI. But most are buying it like a utility meter, for work that looks the same every month. This is our point of view on where the ROI leaks, and a practical guide to getting it back.
WHAT WE BELIEVE
- AI in the close is inevitable. The question is how you run it and how you pay for it, not whether.
- Tokens aren’t the problem. Unpriced variability is. You can budget a fixed cost. You can’t budget a meter that an agent controls.
- Recurring work belongs in a system, not a chat window. Chat is for one-offs. The close needs memory, controls and complete data.
- Pay for outcomes, not effort. The vendor that designs the agents should carry the cost when they run long.
PART ONE · WHY AI IS NOT OPTIONAL
AI in the close is no longer optional
PART ONE · WHY AI IS NOT OPTIONAL
Every new entity, bank account, vendor, lease and customer contract lands on roughly the same accounting team. Bills pile up in AP, cash needs applying in AR, intercompany grows with every acquisition, and fixed assets, prepaids, leases and capitalized software each need their own schedules and roll-forwards. The close calendar doesn’t stretch, and hiring doesn’t keep up. AI is how finance teams add capacity without adding days.
That is why the zero-day close, where reconciliations, accruals and reviews happen continuously during the month instead of after it, has become a conversation in nearly every finance team. For most companies it is still a goal. But the path to it clearly runs through AI doing the recurring work every day.
Adoption, though, is not impact. Gartner reported that 84% of finance organizations use or plan to use AI, but only 7% see high impact. In our experience, the gap is rarely the technology. It is how AI gets deployed and how it gets bought. To see why, start with the bill.
PART TWO · WHERE THE ROI LEAKS
Token prices fell. AI bills didn’t.
PART TWO · WHERE THE ROI LEAKS
AI keeps getting cheaper per unit, yet company AI bills keep climbing. Ramp’s data shows the per-token price falling roughly 46%, yet the bill still rising about sixfold. Cheaper tokens simply invite more of them, and the most expensive models end up doing most of the work.
The reason is structural. With AI agents, you approve the task, but the agent decides how many steps it takes, which model it uses and how often it retries. Each step is billed. The habit of treating usage as the goal, sometimes called tokenmaxxing, makes it worse: usage leaderboards, agents left looping, the most expensive model on every task.
Three patterns we keep seeing
The stories in the press all rhyme. Strip away the company names and three patterns repeat.
- Usage targets without cost design. Uber pushed engineers to adopt AI coding agents, burned through its full-year 2026 budget by April, and moved to caps of $1,500 per person, per tool. Caps stop the bleeding, but they also ration the tool. The fix is designing the work, not limiting the people.
- Governance changes the unit economics, not the ambition. FactSet kept growing usage after adding token governance: coding token use up 80%+ in a quarter, while spend grew half as fast. The lesson for finance: manage cost per unit of work, not total usage.
- The cost driver is invisible to finance. At AngelList, a single caching setting nobody in finance could see was costing $10,000 a month; it was fixed the same day. JPMorgan’s CFO has called the bank’s spend small today while warning it will accelerate. The invoice tells you what you spent, not why.
The real problem is the meter
OUR POINT OF VIEW
A CFO can underwrite a fixed cost. A CFO cannot underwrite a meter that swings 40% a month for reasons nobody in finance controls.
Finance operations are unusual: the work is recurring and bounded. The same recs, accruals and close come around every month, and the volumes are known in advance. Work that predictable should cost the same every month. Metering it by the token turns a known workload into an unknown expense, and buying a separate tool for each process multiplies the meters with nobody owning the total.
A fixed fee doesn’t make tokens free. It moves the overrun risk to the vendor, which is exactly where it belongs, because the vendor designs the agents, picks the models and decides how many retries happen. That is the logic of outcome-based pricing.
| Metered (per token or usage) | Outcome-based (fixed fee per module) | |
|---|---|---|
| You pay for | Compute consumed, including retries and loops | Defined work, scoped to your volumes |
| Your budget | Moves with agent behavior | Same fee every period |
| Overruns land on | You | The vendor |
| Billing starts | First API call | When it’s live and meets agreed criteria |
| Vendor incentive | More usage | Fewer exceptions, faster close |
PART THREE · A PRACTICAL GUIDE
Match the AI to the work
PART THREE · A PRACTICAL GUIDE
AI belongs across the whole close, judgment included. The question is which kind of AI fits each task, and three questions sort almost every one. Ask them before any tool conversation, not after.
Judgment work is where AI platforms differ most. Accruals for unbilled spend, lease classification, software capitalization, intercompany eliminations, capex versus opex and contract modifications need AI that can reason against your policies and past decisions, show its evidence and route the call to the right approver. A platform that only matches transactions will stall exactly where the close gets hard.
| Area | AI runs it | AI supports the judgment call |
|---|---|---|
| Order-to-cash and AR | Billing, cash application, collections follow-ups, AR aging | Contract modifications, variable consideration, credit reserves |
| Procure-to-pay and AP | Bill intake, GL coding, matching, cost-center allocations | Accruals for unbilled spend, capex versus opex |
| GL operations | Depreciation, prepaid amortization, intercompany matching, lease schedules | Lease classification and modifications, software capitalization, eliminations, impairment |
| Treasury | Bank recs across entities, banks and currencies | Unidentified cash, FX and timing exceptions |
| Close and reporting | Close checklist, flux drafts, COA mapping, report packs | Board narrative, disclosures, final sign-off |
Most trouble, though, starts between the first box and the last: recurring work that began as a one-off in a chat window and quietly became the process.
Why a chat window is not a finance operating model
Claude, ChatGPT and Microsoft Copilot are excellent tools. Our own team uses them every day, and finance teams should too. The problem is not intelligence: these models know the accounting standards well. What they don’t have is your business: which vendors get split across cost centers, which customers got non-standard terms, which software costs your controller capitalizes, and how the same edge case has been judged for three years.
| Chat window for recurring close work | A finance operating system | |
|---|---|---|
| Context | Re-explained every run; pasting a policy doesn’t make the model operate inside it | A policy layer learned from your own historical decisions |
| Edge cases | Hand-written prompts, potentially thousands, owned by whoever wrote them | Agents that build and update the logic as exceptions are resolved |
| Data | Connectors good for analysis but lossy; whatever the query pulled | Every transaction, pulled continuously from systems of record |
| Memory and cost | Starts from zero; re-reads the ledger and the meter runs again | Learns from each correction and escalates less over time |
| Controls | No posting, no control tie-out, no work papers | Built into the work, with audit trail and sign-offs |
A CFO’s playbook for AI ROI
If you do one thing after reading this, run these six steps this quarter. None of them require buying anything new.
| Step | What to do | What good looks like |
|---|---|---|
| 1. Find every meter | Pull AI spend from cards, AP and cloud bills. List each tool, its owner, its pricing model and the process it touches. | Every AI line has an owner and a purpose. Nothing renews by default. |
| 2. Sort the work | Run each process through the three questions above: repeats? rules-based? needs a signature? | Every process has the right kind of AI: autonomous for rules, judgment-capable for estimates and policy calls, with approvals routed to the right person. |
| 3. Measure cost per outcome | Track cost per reconciled account, per invoice processed, per entity closed, not tokens or seats. | You can say what a closed rec costs you, and whether it’s falling. |
| 4. Fix the easy leaks | Ask vendors and internal builders about model routing, caching, retry limits and caps per workflow. | Expensive models do hard work only. Cheap work runs on cheap models. |
| 5. Move recurring work off the meter | For the close, recs and AP, ask for a fixed fee scoped to volumes, with written success criteria and billing at go-live. | Overrun risk sits with the vendor. Your forecast holds. |
| 6. Prove it on a closed month | Backtest any new system against a month you have already closed, and review every mismatch. | You see accuracy on your own books before you pay. |
FIVE QUESTIONS FOR EVERY AI VENDOR
Is it priced per token, per seat or per outcome? Who eats the overruns? When does billing start, and what counts as success? How many people can use it? What happens at twice the volume?
Here is how we answer them.
PART FOUR · HOW HYPHENATE DOES IT
How Hyphenate prices it, and why it’s different
PART FOUR · HOW HYPHENATE DOES IT
Hyphenate is autonomous finance for the office of the CFO. We are not a point solution: we partner across order-to-cash, treasury, GL accounting and close, procure-to-pay, and reporting. And we price the way finance work behaves: recurring, bounded and knowable in advance.
How success-based billing works
We scope each module to your real workload: entities, bank accounts, transactions, bills and reconciliations a month. Before go-live we agree written success criteria with your team, such as accuracy against your own books or a shorter close. We prove it by backtesting against your historical books or running side by side, reviewing every mismatch together. In year one, each module bills only after it is live and passes. Then the rate is locked for the term. A one-time implementation fee covers setup.
What makes Hyphenate different
| What to look for | How Hyphenate does it |
|---|---|
| Priced on outcomes, not usage | Flat fee per module, billed only after success criteria are met. Token costs, model choices and retries are ours. |
| Proof before payment | Backtests on your own historical books and side-by-side runs, with mismatches reviewed jointly. |
| Built for judgment, not just matching | Handles complex calls such as lease modifications, software capitalization, intercompany eliminations, accrual estimates and contract changes by reasoning against your policy and precedent, citing evidence and routing the decision to the right approver. |
| Your policy, not generic AI | A policy layer learned from your past decisions and grounded in your accounting policies. It escalates less as your team accepts or corrects its calls. |
| Complete data, not snapshots | Continuous, read-only integration with your ERP, banks, CRM and billing systems, so every transaction is accounted for. |
| Built on your systems of record | Your ERP stays the book of record and existing tools stay in place. We are the system of action on top. |
| Explainable, auditable output | Every match or entry carries a rationale and confidence score, with exception workflows, sign-offs and work papers. |
| One platform, not twenty meters | Modules share data and controls across the office of the CFO, so the ledger is read once, not by a dozen tools. |
One platform, six modules
Order-to-Cash Billing, collections, cash application, AR, ASC 606
Treasury Bank recs across entities, banks and currencies
GL Accounting & Close Fixed assets, prepaids, leases, intercompany, close checklist
Procure-to-Pay AP bill intake, coding, allocations, accruals
Reporting & Insights COA mapping, flux commentary, board decks
Custom Build Agents built for your exact process
Each module is one flat fee. Add modules as you go; the meter never starts.
PART FIVE · FROM THE FIELD
Hyphenate field notes
PART FIVE · FROM THE FIELD
Pricing on outcomes changes everything behind the scenes: who we hire, which deals we take, how we build and how fast we move. Six moments from the last few months, with customer names left out.
HIRING
Every engineer builds a reconciliation agent before they join
Our technical interviews aren’t puzzles. Candidates build an agent that reconciles bank and book transactions, including one-to-many and many-to-one matches, with a bar of 100% precision: anything uncertain must escalate to a human, not guess. Separate rounds test AI product sense, productionizing and agent debugging. On the solutions side, we hire CPAs from public accounting and ERP implementation who have lived the close themselves.
Why it matters: the people building your agents know a wrong match on a bank rec is worse than no match at all.
DEALS
The first question on every deal
A large marketplace company asked us to take on cash recs across half a dozen banks, three-way order-to-processor-to-bank matching, gift-card inventory and partner invoicing. Before anyone talked features, our engineering lead’s note on the pricing thread was: get their volumes, we need to understand gross margin.
Why it matters: under a meter, a customer’s volume is the vendor’s upside. Under a fixed fee, it’s the vendor’s engineering problem, which is where it belongs.
CUSTOMERS
When accounting is the reason the business can’t say yes
The same company was turning down commercial deals that required pre-buying gift-card codes, because nothing could account for them properly: no code-level inventory, no cost flow, no disclosures. Cash recs ran on a treasury tool and a matching system built years ago in-house. We scoped one platform for all four problems, with every transaction drillable and a single sign-off trail.
Why it matters: the hair-on-fire problem is rarely “we need AI.” It’s “finance is now the bottleneck on revenue.”
CUSTOMERS
5 to 10 million transactions a month, and a 2.5-day revenue close
A high-volume subscription company processes millions of payment-platform transactions a month, more than its ERP handles comfortably, held together by expensive, fragile RPA bots. Their goal: revenue close from 2.5 days to 1, with auditors comfortable with automatic posting. Our answer wasn’t a slide. It was a side-by-side trial on their own data, against written success criteria.
Why it matters: proof on your data, before you pay, is the whole point of success-based billing.
DELIVERY
Paid at go-live, so we move fast
On one engagement the contract covered two processes. Our plan was to take over the customer’s roughly 40 reports by day 75, because the sooner the work runs in production, the sooner it meets its criteria and the sooner we are paid.
Why it matters: success-based billing aligns our incentive with yours: speed to value, not seats sold.
PRODUCT
Accountants review our code
Engineers write the code, but accounting subject-matter experts now review pull requests for accounting substance before they ship. A coverage guard holds unit tests at about 90%. Our own code-review agent uses a frontier model only for deep logic and a cheaper model for static checks, because under a fixed fee the token bill is ours.
Why it matters: what reaches your books has been checked by someone who has closed books.
THE TAKEAWAY
Pulling back from AI is not the answer. Paying for it on outcomes is. Measure cost per closed rec, not tokens burned.
See it on your own close.
Subscribe to our newsletter to receive the latest from Hyphenate.