---
title: "How to bill AI agents: identity, budgets and reconciliation"
url: https://getlago.com/blog/how-to-bill-ai-agents
description: "Agent identity, spend caps, wallet balances and marketplace reconciliation: the six layers a billing system has to keep apart once agents spend money."
authors: ["Anh-Tho Chuong"]
tags: ["AI", "Pricing & Monetization", "Billing"]
published: 2026-09-21
reading_time_minutes: 5
---

# How to bill AI agents: identity, budgets and reconciliation

An agent is not a user with a payment method. It is launched by an employee, serves a team, draws on a budget a parent company funded, and may settle on an invoice a cloud marketplace sends. One request, five different owners.

Billing systems built for human subscribers collapse all of that into a single customer record. Under agent traffic that record stops answering the questions the business actually needs: who spent this, who approved it, who pays, and which contract applies.

Six things have to come apart before any of those questions has an answer.

### The six layers

| Layer | Question |
| --- | --- |
| **Identity** | What human, agent, service account or key made the request? |
| **Entitlement** | What is that principal allowed to use? |
| **Policy** | Which rate limit, spend cap or approval rule applies? |
| **Funding** | Which allowance, wallet, commitment or credit line pays? |
| **Contract** | Which price and commercial terms apply? |
| **Invoice** | Who receives and settles the charge? |

One request passes through all six. Collapsing any two of them holds until the first concurrency spike, refund, or parent and subsidiary contract split.

### Give the agent its own identity

The common shortcut is to treat an agent as an extension of the employee who created it. That breaks in three ordinary cases: the agent outlives the employee, the agent serves several teams, or the agent runs work no single person approved.

A workload identity avoids all three. The agent gets its own record, that record points to an accountable owner, and its entitlement and budget come from the workspace or project sponsoring each run. When one agent serves several teams, each invocation carries an explicit billing scope.

The same care applies to account trees. A parent funds a commitment, subsidiaries draw against it, usage is attributed to the child and settled against the parent. That model holds until a subsidiary signs its own contract, bills in another currency, or needs separate tax treatment. The financial hierarchy is not the org chart, and modelling it as one is expensive to undo.

### Three controls that are not the same thing

- A **rate limit** controls throughput.
- A **spending cap** controls consumption over a period.
- A **credit limit** controls financial exposure.

Each can exist at the key, agent, user, team, workspace or parent level. Teams routinely ship one and describe it as the other two. Before adding any of them, write down the precedence and inheritance rules: what happens when a team is blocked but its parent still has budget, and which limit wins when two apply to the same call.

### "Real time" is four different promises

Most disagreements about real-time billing are really four separate requirements wearing one name.

| Promise | Useful latency | What it is for |
| --- | --- | --- |
| Usage dashboard | Minutes | Visibility |
| Budget alert | Seconds or minutes | Time to act |
| Spend cap | Before the next request | Enforcement under concurrency |
| Invoice | Slower is acceptable | Completeness and auditability |

The fourth row is the one teams underestimate. An invoice has to be reproducible months later, after a mid-period discount and a refund that landed once the period had closed. The first three can be approximate. That one cannot.

### Where enforcement actually happens

Suppose twenty agents start work against a $100 remaining balance. A strict cap means reserving budget before each request begins, then consuming the reservation and releasing the remainder once real usage lands.

Reservation buys precision and costs two things. It adds latency to every call, and it turns authorization into an availability dependency: if the service that answers "may this run" is slow, your product is slow, and if it is down, your product is down. Long-running agents make it worse, because many have no useful maximum cost to reserve against.

The alternatives are all trade-offs rather than solutions. Bounded overshoot accepts a known amount of unbilled usage. Queuing converts a spend problem into a latency problem. Model downgrade preserves throughput and changes the product. An overdraft policy lets in-flight work finish and settles afterwards. Each is defensible. None is free, and the choice belongs to whoever owns the customer promise.

This is also where the boundary between systems sits, and it is worth being exact about it. A monetization platform supplies commercial state: current usage, entitlements, ongoing balances and alerts. The application or gateway in the request path performs the enforcement. Anything that promises to do both from outside the request path is describing a dependency, not a feature.

That split is how Lago is built. Lago ingests event-based usage and retrieves current usage for the open billing period. It creates prepaid-credit wallets, scopes credits to usage, traces wallet movements and returns an ongoing balance that accounts for current usage in real time. An ongoing balance is not hard synchronous authorization before every model call, and treating it as one is the mistake this section exists to prevent. Entitlements are defined by plan, overridden per subscription and retrieved through the API; the application or gateway enforces what comes back. Thresholds on usage and balances raise [alerts](https://getlago.com/docs/guide/alerts/credits-consumption-alerts) that the application uses to top up, throttle, reroute or block.

Underneath, the two paths are separated on purpose. Events flow through Kafka into ClickHouse for metering, while invoices and credits stay in Postgres, which is [documented in the open](https://github.com/getlago/lago/wiki/Using-Clickhouse-to-scale-an-events-engine) along with the rest of the engine. Fast ingestion and a durable financial record answer different questions, and they will disagree. Reconciliation between them is part of the design, not a defect in it.

### One call, five records

Selling through a cloud marketplace multiplies the problem, because a single request now leaves a trail across two companies.

The usage is recorded at the API call. It is rated into a contractual charge once model rates, discounts and terms are applied. It is converted into whatever billing unit the marketplace accepts and submitted there. It appears as a line on the customer's cloud invoice. It is booked as revenue and a receivable. Five records, two owners, and no guarantee that any two agree at a given moment.

Then add the ordinary failures. A marketplace submission times out after the usage was recorded. A discount takes effect mid-period. A refund is approved after one side has closed the period. A customer disputes a line that nobody can reproduce from the original call.

Surviving that requires two things most billing models leave out. Pricing inputs have to be versioned across model, feature, metric, tier, channel, currency, effective date and contractual override, so that any charge can be recomputed exactly as it was first calculated. And every record needs an explicit reconciliation state: matched, pending, rejected, corrected, written off. A record with no state is a record nobody can answer a dispute with.

Commercial terms need the same precision. "The partner receives 20%" is not something you can implement. Twenty percent of list price, net revenue or collected cash? Before or after credits, refunds, tax and marketplace fees? Measured at event time, invoice time or settlement? The contract is not operational the day the PDF is signed. It becomes operational when those answers exist as versioned rules.

### What to build first

The smallest useful version of this is narrower than most teams expect:

1. Separate identity from funding. Every usage event names the principal that made the call and the balance that pays for it.
2. Pick one enforcement promise and state its guarantee honestly, including the overshoot you accept.
3. Version pricing inputs from the first charge, because retrofitting them means recomputing history you no longer have.
4. Give every financial record a reconciliation state before you have anything to reconcile.

The layers that are cheap to separate on day one are the ones that are expensive to separate after the first enterprise contract.

Lago serves AI-native companies including Mistral AI and Groq, and developer platforms including Laravel. It is open source, so the metering path, the wallet model and the invoice records are all inspectable before you commit to any of this. The [wallet documentation](https://getlago.com/docs/guide/wallet-and-prepaid-credits/overview) is the fastest way to see how the funding layer behaves, and we read a live version of this whole problem in [Anthropic's New Markets and Monetization role](https://getlago.com/blog/anthropic-new-markets-monetization-applicant-cheat-sheet).