7 Metering Mistakes That Cost AI Companies Six Figures a Year

Every AI company past $2M in ARR loses money to metering mistakes it cannot see. The invoices look correct because the same wrong code generates the invoices, the customer reports, and the internal dashboards. Nobody catches it until someone reconciles the meter against a separate source of truth.

These are the seven mistakes that show up on almost every audit. Each looks small. Together they cost six figures a year, minimum.

Mistake 1: Why does missing an idempotency key on ingest leak money?

The pattern: your product emits a usage event by calling meter.record(customer, event) with no unique key. The metering layer accepts whatever arrives.

Why it leaks: any retry, from a queue, from a client SDK, from a Kubernetes restart, produces a duplicate event. Duplicates inflate the meter. Customers get double-billed for the same call. Support processes credits. Revenue disappears into refunds.

The fix: every event carries an idempotency key you control. Usually your request ID, sometimes a hash of the event payload plus timestamp. The metering layer deduplicates on that key over a rolling window of at least 7 days.

Typical leakage: 0.5 to 1.0% of billed revenue.

Mistake 2: How much do you lose to at-most-once delivery?

The pattern: your product calls the metering API in the request path. If the metering call fails or times out, the event is dropped. You do not want request latency to depend on meter uptime, so you never retry.

Why it leaks: every meter outage, every deploy that briefly rejects writes, every network blip, drops events. Under normal operating conditions, this is 0.1 to 0.3% of events. Under a bad quarter, it is much more.

The fix: at-least-once delivery from the producer to the meter, backed by a durable queue. Kafka, SQS, or a lightweight in-process buffer that persists to disk. The meter receives every event that entered the queue, exactly once (thanks to Mistake 1's idempotency key).

Typical leakage: 0.3 to 1.0% of billed revenue.

Mistake 3: Why does rounding at the event level destroy revenue?

The pattern: your product charges $0.00013 per 1,000 tokens. Per event, you round to the nearest cent, which is zero. The meter stores rounded values. The invoice sums the rounded values.

Why it leaks: rounding-to-zero, at scale, moves real money. A single event rounds to 0 cents. A million events rounds to 0 cents. The correct number is $130. All of it, gone.

The fix: store exact values, in the smallest unit the pricing model uses, all the way through the pipeline. Round once, at the invoice level, on the final total per line item. Tokens, milliseconds, and bytes should never lose precision at ingest.

Typical leakage: 0.3 to 0.8% of billed revenue on token-priced products. Higher on tokens, lower on requests.

Mistake 4: What breaks when you roll up on the wrong period boundary?

The pattern: your billing cycle runs calendar months in the customer's timezone. Your rollup job runs in UTC.

Why it leaks: an event at 11:45 PM Pacific on the last day of the month is 6:45 AM UTC the following day. Under a UTC rollup, that event lands on the next month's invoice. Under a Pacific rollup, it lands on this month's. A tier boundary crossed midnight in the wrong direction can cost thousands of dollars per customer.

The fix: rollup runs in the customer's contractual timezone, not the metering layer's convenience timezone. Store event timestamps in UTC, always. Compute period boundaries per customer.

Typical leakage: 0.2 to 0.6% of billed revenue, concentrated in the largest customers.

Mistake 5: How does missing dedup on retries inflate the meter?

The pattern: your data pipeline has at-least-once delivery from producer to broker to meter. Somewhere along the way, a Kafka consumer restart causes it to re-read the last 30 seconds of events. Or an SDK client retries a failed HTTP call.

Why it leaks: retries and re-reads inflate the meter. This is Mistake 1 in a different disguise, but it happens even to teams that have idempotency keys, because dedup only works over a defined window.

The fix: verify the dedup window is longer than the longest possible retry loop. Seven days is standard. Anything shorter fails during major incidents, which is precisely when you cannot afford to lose data integrity.

Typical leakage: 0.4 to 1.2% of billed revenue.

Mistake 6: Why does applying credits before tiering create audit findings?

The pattern: your customer has 100,000 credits for the month. You debit credits from usage first, then price the remainder against tiered pricing.

Why it leaks: tiered pricing has volume discounts. If the customer's total usage is 1,000,000 units, they get the tier-3 rate. If you subtract 100,000 credits first and price 900,000, they still get tier-3, but the calculation is off in subtle ways. If you then re-add credits back at the top rate for reporting, the invoice does not tie out.

The fix: price the full usage against the tier structure first, apply credits against the final price as a monetary discount. This aligns with how commitments are contractually specified in almost every enterprise MSA, and makes the invoice traceable line by line.

Typical leakage: 0.2 to 0.5% of billed revenue, plus a much larger cost in audit findings.

Mistake 7: Why is reconciling meters against the warehouse non-optional?

The pattern: the metering layer is the source of truth. Nothing checks it.

Why it leaks: every one of the six mistakes above is invisible without an independent count. When the meter says a customer used 2,400,000 requests, and the warehouse says 2,410,000, that 10,000 delta is money. Nobody sees it because nobody diffs the two numbers.

The fix: nightly, per customer, per meter, diff the metering-layer count against the data warehouse count. Alert on any delta over 0.1%. Investigate. Every delta is either a bug you can fix or a legitimate difference (event dropped in the warehouse pipe, not the meter) that you can document.

Typical leakage: whatever the other six add up to, uncaught.

What is the cumulative cost of all seven?

Add them up and the typical AI company at $10M ARR is leaking 3 to 5% of billed revenue.

Not all seven are present in every system. Three or four usually are. A single audit that fixes them will recover $200K to $400K in the first year at that scale.

The mistake to avoid

Metering mistakes look like edge cases individually and like structural failures collectively. Teams that fix one at a time never get the compounding benefit of a clean pipeline. Do the audit end-to-end. Instrument every stage of the pipe with a checksum. Diff the checksums against the warehouse nightly. Fix all seven in a single quarter, not one per quarter, and the leakage stops. Then, and only then, look at pricing changes. Trying to raise prices on top of a leaky meter is worse than either problem alone, because customers can smell inconsistency and it destroys trust in the invoice.