AI companies should own their metering, not the entire billing stack

I’ve had conversations with billing engineers at a range of tech companies, and so often the story goes something like this:

I’m on the platform team that deals with things like authentication and feature flagging, and we got handed the billing some time ago. We inherited this system that was put together in a hurry years ago by a product team when they first wanted to try usage-based billing. It grew from there. Errors have been showing up in billing, and when an enterprise customer asks us to prove an invoice is correct, it can take days. I hear GTM wants to add even more pricing levers to this thing, but we’re just trying to keep up as is. I’m not even sure how the accounting side works—we just send them the data exports once a month.

Billing is famously bigger and harder than it looks, and it comes with costly consequences: billing errors, revenue leakage, failed audits, and even missed windows for IPO.

The problem is that “billing” combines several distinct jobs. Collecting usage events, applying prices, issuing invoices, processing credits, and recognizing revenue are different jobs, with different requirements, constraints, and challenges.

AI is bringing these problems forward. Companies charging for tokens and compute hours need to measure usage, update balances, and enforce spending limits. Enterprise customers bring negotiated rates, committed credits, and contract modifications. Teams encounter this complexity before they have dedicated billing expertise, making the decision about what to build and what to buy an early architectural choice with lasting consequences.

For AI companies, I recommend a division: own usage measurement, pricing logic, and customer balances; use specialist software for invoicing and revenue recognition; and connect them by coordinating a single representation of commercial agreements.

Breaking down “billing”

The simplified map above illustrates how to break down the problem space into areas. I’ll elaborate below.

Metering

Metering, reflected in the red box above, is focused on infrastructure and compute. You collect the data of how your products are being used, transform (and often aggregate) that information, and resolve applicable prices for the events.

Missed events lead to under-billing. Double-processing leads to over-billing. This layer has to handle both your event volume and the logic of your pricing model.

Customer balances aren’t strictly part of metering. But if your product needs to show a live balance or enforce a spending limit, the two become tightly coupled. Each usage event has to be collected, priced, and reflected in the balance quickly enough for the product to act on it. A delay anywhere in that path leaves the product working from stale information.

That shared latency requirement puts live balance management alongside metering.

Invoicing

Invoicing (blue box) is the layer at which invoices are sent, payments are drawn, and refunds are issued. It’s an extremely sensitive layer and it often involves stakeholders across multiple departments. Finance and accounting are responsible for assuring the correctness and accuracy of what they bill customers, while account managers, salespeople, or support representatives have access to the tools to issue credits and refunds to customers.

Accounting

Accounting (green) involves seemingly arcane requirements to continually capture, interpret, calculate, and record the financial story of your agreements. In many companies, revenue accounting is the most specialized work in the accounting department as well as the most sensitive audit area.

Correct revenue recognition under ASC 606 depends on a lot of data and context. The contracts (both implicit and explicit), all changes to them, subsequent events, usage data, and billings are necessary inputs to produce the revenue story, making it a tricky layer of the stack to get right. Many teams suffer a hybrid approach where a naive first draft of accounting entries comes from their billing provider, and a separate set of spreadsheet-driven adjustments reinterprets and reallocates that draft into compliant accounting.

Contracting

Contracting is the model of the business and its agreements, inclusive of legal clauses and rate card configuration. All layers of billing depend on some or all of contracting, making it non-trivial to see how and where to break up the problem space.

Build vs. Buy

Traditional billing vendors claim to cover every part of the diagram above. Send us your events, model your pricing in our app, and we’ll do everything.

But for mid-market and enterprise businesses, they generally quickly find that:

• They have to run their own collection and aggregation infrastructure in front to compress the events down to smaller volumes that the vendor can handle.
• They have to manage enterprise agreements or subscription billing in a parallel system.
• The contracting layer struggles with per-contract variability and contract modifications.
• Accounting is an afterthought. Your accounting department still depends on spreadsheets (or yet another software tool) for revenue recognition, as the basic journal entry export from the system doesn’t meet the accounting requirements.

In theory, they do everything for you. But they aren’t experts in everything.

You can outgrow different parts of an end-to-end system at different times. Event volume may force you to build your own aggregation infrastructure while the vendor’s pricing tools still work for you. Variability in contracts may exceed what its agreement model is built for, or accounting requirements may become more rigorous than its journal entry exports can support.

The difficulty is replacing the piece that you’ve outgrown. Your pricing rules, usage data, and invoicing workflows all depend on one monolithic system, so replacing one component can require changes across the stack. You end up building workarounds around a vendor you still need for other jobs. Over time, those workarounds make it even harder to move.

Nonetheless, I don’t usually recommend solving the full stack without any vendor. So where do you get help?

Is billing part of your product?

A common build vs. buy heuristic is this: build in-house where it shapes your product and customer experience, and outsource non-customer-facing concerns. Where something is a blocker to your product roadmap, you often want more control and in-house expertise.

What is customer-facing?

Consider Anthropic’s Claude product: imagine you have a subscription or a spend limit. As you interact with Claude for coding, you can reach your usage limit. This information is time-sensitive and presented to you, the user. There are product and design choices here. How do you see it? Does it warn you? When you reach the limit, does it cut you off or do you incur overage spending? How quickly does it detect that you’ve reached the limit? These are product questions.

The product questions can get hairier. For example, in enterprise agreements you might want to allow centralized spend controls with by-team allotments of credit. How does each user experience that? How is it administered, and how are changes applied?

For products like this, metering is your product.

Ask yourself:

• Do we expect to introduce or evolve our usage-based pricing?
• Does our user expect to see their remaining balance in real time?
• Does our data volume number in the billions of events per month?
• Are we adding features like limits and spend analytics?

The answers to the above can indicate whether or not you should maintain an internal engineering team to stay nimble for product-facing billing needs.

Back office: some recommendations

When it comes to the back office, there are some critical elements to consider.

First, think early about reconciliation. There are four different things that you will need to be able to reconcile and compare: bookings, billings, revenue recognition, and collections. The accounting layer is a merge point for almost everything—you cannot recognize revenue without knowing the usage totals, nor accrue revenue without knowing the billing state, nor allocate transaction price without the contract obligations. So create a feedback loop between accounting and contracting and billing to identify and correct problems.

Second, consider observability. How will you recognize events that didn’t get priced? How will you audit changes to rates? Try to make the system more visible and understandable.

Third, keep an eye on accounting complexity. Your billing engineers are not accounting experts, and the accountants aren’t generally systems experts. Two variables will drive the scale of the concern here:

• Accounting difficulty, driven by the volume, complexity, modification rate, or inconsistency of your contracts.
• The accounting rigor your reporting, audits, and financing plans require.

The former reflects the variety of your products, the scale of your customers, and the nature of your sales operation. The latter reflects the operational sophistication or regulatory needs of your business. If either changes—due, for example, to growth, new business lines, or IPO plans—your existing practices may struggle to keep up.

Keep metering, outsource back office, align contracting

The full stack is often too large to run entirely in-house, while the customer-facing side is too critical to hand over completely. In that case, I recommend dividing the back office from the customer-facing side and owning the latter.

My ideal architecture for most AI businesses is this:

1. Metering: Maintain your own metering: collection, aggregation (or not), pricing, and balance pools. This is the “fast loop” which affects your customers directly, and you should control it.
2. Accounting: Don’t build your own revenue recognition engine. The engineers aren’t familiar with it, and spreadsheets become a nightmare. This becomes a bottleneck to evolving the business model.
3. Invoicing: Ideally keep invoicing and accounting under one roof. If you do this, then the most critical reconciliation (billings vs. revenue) stays in lock-step and you avoid revenue leakage or over-billing.
4. Invoicing (alternative): If you’re keeping your current invoicing provider (perhaps you have too many dependencies to change it any time soon), make sure the integration from invoicing to the accounting backend is carefully coordinated. The contract, rate cards, amendments, credits, and refunds have to be understood across these systems.
5. Contracting: Let the back office own the shared model of customer agreements. Metering needs the terms that govern usage pricing and balances. Accounting needs that and more, including performance obligations, discounts, bundling, non-usage components, and contract modifications. Interpreting those agreements and changes is a concern for finance and accounting, not the billing engineers, so the back-office system should manage it. Metering receives the subset it needs, and neither side has to reconstruct its own version of the contract from the other’s outputs.

This division of responsibilities informs how we’re building Numeric’s billing and revenue product. We manage the shared agreement model and revenue accounting, with invoicing handled in our system or another provider’s. Billing operations and finance can investigate disputes, correct errors, and manage agreement changes in Numeric without needing engineering for each adjustment. Billing engineers own the metering side, and both teams work from the same agreement model as pricing and contracts change.

This doesn’t apply to every business, but technology companies are increasingly going in this direction. When usage pricing and live balances shape your product, you need control over that fast loop. Pricing and contracts will change. You need to be able to adapt your product and scale your back office, and the system decisions you make will be a deciding factor.