How to Implement Event Based Billing Without Rebuilding It Twice

The first invoice is where you find out whether your metering works.

A customer counts their own API calls, compares their total to yours, and the two numbers disagree by four percent. Now you’re in a support thread arguing about arithmetic, and you will probably lose it, because they have their logs and you have a pipeline you can’t replay.

That argument is what you’re designing against when you implement event based billing.

Short answer up front: event based billing works when every event carries an idempotency key, the aggregation is settled before launch, and enforcement runs separately from the billing pipeline. Those three decisions are why infrastructure like Stigg exists as its own layer.

Start by naming the billable event

A billable event is the smallest unit of value your customer would recognize on an invoice.

Most teams skip this step and meter whatever is easiest to log, which is usually the HTTP request. It’s a reasonable first instinct and it produces invoices nobody can explain.

The better question is what your customer would count if they were auditing you. For a document API that’s pages processed. For an AI product it’s closer to a completed task than a model call, because one task might make nine calls and the customer only asked for one thing.

There’s a real cost to going granular. Every event you emit is an event you store, aggregate, and eventually explain, so the finest-grained option is rarely the right one.

Pick the unit your customer can count without your help. That single choice removes most future billing disputes.

Design the event schema you’ll regret changing

Six fields carry almost all the weight here.

An idempotency key. A stable, deterministic ID that the caller generates and the receiver trusts. Without it, everything downstream is guesswork.

The account it belongs to. Customer, subscription, and where relevant the individual user or agent, because enterprise buyers will eventually ask you to break a bill down by team.

Two timestamps. When the event happened and when you received it. Collapsing these into one field is the mistake that makes late events unresolvable.

An event type and its dimensions. Model name, region, tier, whatever you might price on differently later.

A quantity. Explicit, in a documented unit, even when it’s always 1 today.

The dimensions deserve care, because every one you add becomes a dimension you can’t remove without breaking historical reports, and a seventh field added after launch means backfilling every row you already have. Add the ones you can imagine pricing on, and resist the rest.

Why does event based billing break under retries?

Every event pipeline delivers at least once, which is a polite way of saying it sometimes delivers twice.

A network timeout fires, your client retries, and the same usage lands in the ledger again. That’s the four percent from the opening paragraph, and it usually surfaces as a customer complaint before any alert fires.

Idempotency keys solve it, with one caveat worth knowing before you rely on them: deduplication needs a window, and a retry arriving after that window closes gets counted twice anyway.

Late events are the same problem wearing a different hat. An event with yesterday’s timestamp, arriving after you’ve closed the billing period, forces a choice: reopen a finalized invoice, or credit the difference next cycle. Decide that now, because deciding it at month-end close goes badly.

Pick your aggregation before you write the meter

The aggregation method is a pricing decision disguised as an engineering one, and changing it after launch changes what customers owe.

Count and sum cover most cases. Count unique is what you want for monthly active users, and it costs meaningfully more to compute at scale because you can’t just add numbers as they arrive. Max and average show up in storage and concurrency pricing.

Rounding is where the arguments happen. A customer who used 0.02 GB and got billed for a full gigabyte will write to you about it, and they’ll be right that it feels arbitrary.

So document the rule, including your unit conversion. If a gigabyte means 1,000,000,000 bytes in your system, say so somewhere a customer can find it.

Decide what happens when a customer hits the limit

Metering tells you what happened. Enforcement decides what’s allowed to happen next, and the two need separate paths.

A billing pipeline optimized for correctness runs on a delay of seconds or minutes, which is completely fine for an invoice and useless as a gate. If a customer’s cap has to hold, something has to check it in the request path before the work runs.

That check needs a local cache to stay fast, and it needs a documented stance on what happens when the cache is cold and the upstream is unreachable. Fail open and you give away compute. Fail closed and you break a paying customer’s product during your outage.

Neither answer is universally right. Pick per feature: fail closed on the expensive model call, fail open on the dashboard read.

Volume is what forces the issue. An AI agent workload can push thousands of events a minute from a single customer, so a nightly job that reconciles usage has no way to stop anything.

What to build and what to buy

Build the first version. A table, an insert with a unique constraint on the idempotency key, and a nightly aggregation query will carry you a long way, and any competent backend engineer ships it in a sprint.

Buying makes sense at a specific moment: when enforcement has to be real-time, when finance needs a cost basis on every line, and when the schema has to change without a migration. Stigg occupies that window, running alongside whatever billing system you already have.

Miro’s team went looking for infrastructure at roughly that point and, as of September 2026, puts the saving at about 5,000 engineering hours, with pricing changes dropping from six-month projects to a matter of days. Those are the numbers to take to your CFO.

The honest cost of buying is a dependency in your request path, which is the least forgiving place to add one. Ask about latency budgets, cache behavior during an outage, and where the event data lives.

The invoice is the only test that counts

Here’s the check I’d run before launch.

Give a customer their own usage export and ask them to reconstruct their bill from it. If they land on your number, your implementation works.

If they can’t, you have a support problem that no amount of pricing-page copy will fix, and you’ll find out about it one invoice at a time.

Most teams discover this in production. Running it once in staging, with a real customer’s real data and a real spreadsheet, is a cheap afternoon that saves a quarter of awkward emails.

FAQs

How long should you keep raw usage events?

Keep raw events for at least as long as a customer can dispute an invoice, which for most contracts means 12 to 24 months. Aggregates alone can’t answer “which requests made up this charge,” and that’s the only question that matters in a billing dispute.

What happens when a usage event arrives late?

Late events force a choice between reopening a closed invoice and crediting the difference on the next one, and you should pick your policy before launch. Storing event time and ingest time as separate fields is what makes the late event resolvable at all.

Should you meter every event or pre-aggregate before sending?

Send raw events when you can afford the volume, because pre-aggregation destroys the detail you need to answer disputes. Batching them is the middle path: same fidelity, fewer round trips.

How do you test event based billing before launch?

Replay a week of production traffic through the pipeline twice and confirm the totals are identical. If a double-replay changes the number, your idempotency isn’t working, which is the failure mode runtime layers like Stigg are built to remove.