Usage-Based Billing for AI SaaS Products

Key facts, with sources

• Menlo Ventures found enterprise spend on generative AI hit $37 billion in 2025, up 3.2x from $11.5 billion in 2024, making it the fastest-growing software category in history. (Menlo Ventures)
• 76 percent of enterprise AI use cases are now purchased rather than built in-house, up from 53 percent purchased in 2024. (Menlo Ventures)
• AI startups captured 63 percent of the enterprise AI application market in 2025, earning nearly $2 for every $1 earned by incumbents. (GlobeNewswire)
• 47 percent of enterprise AI deals convert from pilot to production versus about 25 percent for traditional SaaS, and enterprise AI now captures about 6 percent of the global SaaS market. (Menlo Ventures)
• The 2025 SaaS Benchmarks report found AI-native startups grow roughly three times faster than traditional SaaS peers, with median growth around 100 to 110 percent below $5 million ARR. (Growth Unhinged)

Pick a billable unit users can predict

The billable unit must pass one test: can a customer estimate next month's bill from their own workload? Contracts reviewed, transcripts processed, generation runs — yes. Tokens, GPU-seconds, API calls — no, because customers cannot see or control them. When the unit is illegible, every invoice becomes a support ticket and every renewal a negotiation about numbers nobody trusts.

Credits are the standard abstraction: each AI action costs a posted number of credits, expensive operations cost more, and your token costs live invisibly inside the credit price. This gives you room to absorb retries and validation passes, and lets efficiency work — caching, cheaper model routing — expand margin instead of triggering repricing. Post the credit costs per action publicly in your docs; hidden meters breed distrust faster than high prices do.

The metering pipeline: one idempotent event per request

The mechanics: every AI request writes exactly one usage event, at response time, keyed by a request id so retries cannot double-bill. The event carries the tenant, the feature, the credits charged, and the raw token counts — tokens are not for billing but for margin analysis, and you will regret not having them the first time finance asks which feature is eating the provider bill. The table is append-only; corrections are new offsetting events, never updates, because when a customer disputes an invoice you want an audit trail, not a mutated row.

Two edge cases worth handling explicitly: streamed responses should meter when the stream completes (with a fallback event on disconnect so abandoned generations are not free), and failed requests that still consumed tokens — a validation retry loop, for instance — should be metered as cost internally even if you choose not to charge the customer for them.

from sqlalchemy.dialects.postgresql import insert

async def record_ai_usage(db, *, tenant_id, feature, request_id, response):
    u = response.usage
    stmt = (
        insert(usage_events)
        .values(
            tenant_id=tenant_id,
            feature=feature,
            request_id=request_id,
            credits=CREDIT_COSTS[feature],
            input_tokens=u.input_tokens,
            output_tokens=u.output_tokens,
            cache_read_tokens=u.cache_read_input_tokens or 0,
        )
        # unique index on request_id makes retries safe
        .on_conflict_do_nothing(index_elements=["request_id"])
    )
    await db.execute(stmt)

Ledger, rollups, and the billing provider boundary

Keep the source of truth in your own database: the usage_events table plus a periodic rollup per tenant per period. Push aggregates to your billing provider on a schedule rather than streaming every event — provider-side meters are convenient but hard to audit, hard to backfill when you find a metering bug, and awkward to reconcile when a customer asks why their bill says what it says.

The rollup job should be boring and re-runnable: sum events for the period, compare against what was previously reported, emit corrections as deltas. I also snapshot each period's rollup immutably at invoice time, because usage disputes arrive weeks later and you need to reproduce the exact number the invoice was built from. This separation — events for truth, provider for collection — has saved every team I have set it up for at least one painful reconciliation.

Prepaid credits versus postpaid metering

Postpaid metering — use freely, invoice monthly — maximizes convenience and revenue capture from engaged customers, but it carries collection risk and produces the surprise bills that generate churn and chargebacks. Prepaid credit packs invert the tradeoffs: revenue arrives up front, spend is capped by design, and the customer consciously decides to buy more — which is a natural expansion touchpoint rather than a billing shock.

My general guidance: self-serve and SMB tiers should lean prepaid or allowance-plus-top-up, because those customers value spend control and you value not chasing invoices. Enterprise contracts lean postpaid with committed minimums, because procurement wants one negotiated number. Whatever the mix, expiry policy matters — aggressive credit expiration feels like theft and shows up in reviews; generous rollover costs little and removes a purchase objection.

Caps, alerts, and abuse prevention

Usage-based billing without limits is an incident waiting to happen — a customer's misconfigured integration or a scripted free-tier farm can burn real model spend in hours. I implement three layers. Per-tenant soft thresholds that notify the customer as they approach their allowance, because informed customers upgrade and surprised ones churn. Per-tenant hard caps that stop service gracefully with a clear upgrade path, applied by default on self-serve tiers. And global anomaly alerts on your own spend, because aggregate provider cost spiking outside business hours is how you discover abuse.

Rate limits belong here too: a cap on requests per minute per tenant bounds how fast anyone can spend, which turns a runaway loop from a five-figure surprise into a support conversation. None of this is exotic engineering — it is a handful of counters — but in code audits it is absent far more often than present.

When to hire senior help

Bring in senior AI engineering help when inference costs threaten margins or reliability issues block enterprise deals, because those are engineering problems solved with caching, routing, and evals rather than product tweaks. Fractional senior involvement at the architecture and pre-scaling stages costs far less than the margin permanently lost to an inefficient inference stack. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — AI SaaS Products projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Pricing per seat when value delivery is usage-based, so AI inference COGS scale with tokens while revenue stays flat and power users invert your margins
• ✕Ignoring gross margin economics; AI-first SaaS typically runs 50 to 60 percent margins versus 80 to 90 for traditional SaaS, and skipping caching and model routing locks in the worst case
• ✕Building a thin model wrapper with no proprietary data, workflow depth, or distribution advantage that the next foundation-model release erases
• ✕Running unpriced pilots without instrumenting value metrics, wasting the AI advantage of a 47 percent pilot-to-production conversion rate

Frequently asked questions

Sources

• Menlo Ventures
• GlobeNewswire
• Menlo Ventures
• Growth Unhinged