Custom AI billing systems leak 4 to 7% of ARR through missed events and reconciliation errors. That is the finding from a March 2026 survey of 350 software executives by PwC and m3ter, published in The Register.
The culprit is not the initial build. It is everything that happens after.
The Thing Nobody Anticipates
Every AI company eventually builds a billing system. It starts as a few if-statements. A token-count field. A margin multiplier.
Then a founder at a voice AI platform discovered it this way. One of their billing indicators had the wrong name. One character. The data had been silently wrong for weeks. Not a crash, no error thrown. Just a mismatch nobody caught until the month-end reconciliation meeting.
Four meetings to diagnose. One character to fix. Zero confidence in anything the dashboard had shown before that.
That is not a billing problem. It is an engineering bandwidth problem. And it compounds. Because billing for AI agents is not infrastructure you build once. It is a subscription to a maintenance backlog.
AI agent billing is the practice of metering what an AI agent actually consumes per run: LLM tokens, speech-to-text minutes, text-to-speech characters, telephony costs, and third-party API calls. It attributes those costs to a specific customer and outcome. Then it reconciles them into an invoice before the billing period closes. It is not payment processing. It is the layer that exists before payment, and it is the layer standard SaaS tools were never built to handle.
TL;DR
- Revenue leakage: 4 to 7% of ARR disappears through missed events and reconciliation errors in homegrown systems (PwC/m3ter, March 2026).
- Maintenance burden: Companies that build AI billing internally allocate 25 to 40% of engineering resources to billing-related work, including data pipeline maintenance, usage aggregation logic, and pricing configuration.
- Time to production: 6 to 18 months for basic functionality. Then 12 to 18 more months discovering edge cases that never showed up in the initial estimate.
- Sub-dollar transaction economics: Stripe's $0.30 fixed fee per transaction consumes 60% of revenue on a $0.50 agent interaction before compute costs. That is US pricing, which you can verify at stripe.com/pricing.
- Agentic AI in production: Only 11% of agentic AI use cases reach full production, according to a January 2026 Camunda survey of 1,150 IT leaders. Billing complexity is one reason engineering never gets there.
Why AI Billing Never Stays Built
This is the part the build-it-yourself estimate always misses. The initial build is finite. The model ecosystem it sits on top of is not.
Start with provider churn. Switching LLM providers and APIs is not an edge case for AI companies, it is standard operations. Major LLM providers slashed prices repeatedly across 2024 and 2025. GPT-4o mini launched at 60% below GPT-3.5 Turbo. DeepSeek cut API pricing by over 50% in late 2025 alone (IntuitionLabs, 2026). The tracker at llm-stats.com logs these changes continuously, not annually, not quarterly. Every update means your billing logic is wrong. On a custom system, fixing it is an engineering sprint. On a purpose-built platform, it is a config change.
That is the visible problem. The less visible one is already breaking most systems today: cache tokens.
Most billing systems do not track cache tokens as a separate parameter. GPT-5 offers 90% discounts on cached input tokens. If your system does not distinguish cached from uncached, your cost calculations can be off by up to 90% on every single call. This is a structural accuracy problem in every billing system built before cache pricing became standard practice, which is most of them.
Now add the agents themselves. The risk is not accidental. It is architectural. Giving agents more autonomy structurally creates unbounded cost exposure by design. A four-agent LangChain pipeline ran for 11 days in November 2025 before anyone noticed. Final bill: $47,000 (DEV Community, 2025).
Scale that across a multi-agent architecture and the amplification becomes structural. AI agents consume approximately 4x more tokens than standard chat interactions. Multi-agent systems use approximately 15x more (Augment Code, 2026). Billing logic written for single-agent interactions fails silently on these workloads. Nothing crashes. The number is just wrong.
These are not four separate problems. These are four compounding reasons the same billing system breaks in a different way every quarter.
What Building AI Billing Infrastructure Actually Costs
The initial build appears on the roadmap. The maintenance never does.
Companies that build AI billing internally allocate 25 to 40% of engineering resources to billing-related work. Two years after one team shipped their billing engine, they still had two engineers dedicated full-time to maintaining it.
At 10 customers, the spreadsheet holds. At 100, it breaks. The headache arrives earlier than founders expect and edge cases do not wait for scale, they wait for the next provider change.
And the timeline never matches the estimate. Building AI billing internally typically requires 6 to 18 months. A team scopes billing, feels good about the estimate, builds the parts they can see, and then spends the next 12 to 18 months discovering the parts they could not.
Here is the part that should settle the debate:
Even OpenAI built an in-house billing system. It involved maintenance of custom scripts and manual labor for tracking usage and invoicing customers. Then OpenAI moved to a purpose-built platform because the homegrown approach was not sustainable.
If the company that builds the LLMs could not keep custom billing maintainable, your team probably cannot either. Billing for AI is a treadmill. You can build it. You cannot stop running it.
The Decision Scorecard
| Factor | Build It Yourself | Purpose-Built (Paygent) |
|---|---|---|
Time to first invoice | Months, not days | Days |
Engineering sprints per quarter on billing maintenance | 2 to 3 | 0 |
Multi-vendor cost attribution (LLM + STT + TTS + APIs) | Manual wiring per provider | Native |
Cache token tracking | Rarely implemented | Built-in |
Revenue leakage risk | 4 to 7% ARR (PwC/m3ter) | Automated reconciliation |
Rogue agent loop protection | Alert after the fact | Execution budget enforcement |
LLM pricing update response | Engineering sprint | Config change |
Per-customer margin visibility | Manual spreadsheet | Real-time dashboard |
The 5-Question Framework: Should I Build My Own Billing System?
Run your own situation through these honestly.
Is billing core to your product or core to your operations? If billing is your product, build it. If it is operational plumbing under an AI agent product, every hour spent on it is an hour not spent on the thing customers actually pay you for.
Do you have engineers who will own billing maintenance permanently? Not for the build. For the next three years of provider changes, cache pricing shifts, and reconciliation edge cases. Permanently is the word that decides this. Most teams do not have that headcount to spare.
Does your cost structure include more than one vendor layer? A single-layer cost is tractable by hand. The moment you have LLM plus STT plus TTS plus telephony plus third-party APIs in one interaction, manual cost attribution breaks. The delta between billed and consumed starts growing.
Do your pricing models change faster than once per quarter? In 2026, they do. A custom system means a code change every time a model updates pricing. A purpose-built one means a config change.
Do you need per-customer cost visibility before you invoice? If you need margin per customer before the period closes, a spreadsheet of cost-per-action will not get you there at scale. If you can wait until after, you are already leaking.
If four or five of these point in the same direction, that is your answer.
Operational Failure Modes
Three that appear in every custom AI billing system at scale.
Rogue agent loops. Four LangChain agents. 11 days. $47,000 (DEV Community, 2025). The team had alerts. Alerts tell you what happened. They do not stop it from happening. Purpose-built platforms enforce execution budgets at runtime. Custom systems notify you after the money is gone.
Idempotency failures. A job retries twice. You bill for three. The number invoiced and the number consumed diverge silently. At low transaction volume this is invisible. At scale it compounds into unexplained ARR discrepancies you cannot trace.
Invoice illegibility. AI agents execute across five to seven API layers per run. An invoice that says "API usage: $847" tells your customer nothing. Enterprise finance teams reject invoices they cannot audit line by line. Purpose-built billing attributes cost per call, per layer, per outcome. The problem is never the invoice amount. It is the missing line items.
When Building Makes Sense
Two cases only.
First, billing is your product. You are a payment infrastructure company, not an AI agent company. Billing maintenance is core work, not a tax on engineering.
Second, sovereign data residency requirements prevent any external data flow. Certain BFSI and regulated deployments where cost data legally cannot leave your environment.
Outside these two cases, building is a choice that compounds.
A Note on Migration
Every month you run a legacy billing system while planning to migrate is a month of known revenue risk.
The expensive part of migration is not the technical work. It is reconciling what you thought you charged with what you actually should have charged. The longer the gap, the larger the reconciliation problem, and the more of that 4 to 7% ARR leakage you have already absorbed.
Where Paygent Fits
Most founders who come to Paygent have shipped working products with no idea what each customer was costing them.
Paygent gives you every cost layer per call, attributed by customer, by agent, and by vendor, before the invoice period closes. When an AI pricing update breaks your billing logic, it becomes a config change and not a sprint.
See how it works on a live deployment → withpaygent.com
