DEV Community: Flexprice

Why usage-based billing is an engineering problem

Flexprice — Mon, 21 Sep 2026 16:29:50 +0000

A product manager walks over and says the company is going to stop charging per email sent and start charging per conversion. The price also moves from $1 per unit to $1.50. Existing customers keep the old rate for three months at $1.20. Free-trial credits go from 500 to 1000, and one enterprise account gets a 90-day trial instead of the standard 60.

None of that is a pricing decision by the time it reaches a backend team. It's a schema change, a migration, a set of effective-dated rules, and a new set of failure modes in a system that directly produces revenue.

Short answer: why is usage-based billing an engineering problem?

Because usage-based pricing moves the invoice off a static plan record and onto a live event stream. The amount a customer owes becomes a function of data your product emits, which means billing inherits every hard problem in data engineering: ingestion at volume, deduplication, ordering, time alignment, and correctness under retry. A wrong number here is not a dashboard bug. It's an incorrect invoice.

Below is what that actually decomposes into.

Data ingestion: capturing every billable unit

Every unit you plan to charge for has to be emitted by your product and landed somewhere durable. The event is the source of truth for the invoice, so the ingestion path carries the same correctness requirement as the invoice itself.

An event is usually small. This is the shape Flexprice accepts:

{
  "event_name": "model.usage",
  "external_customer_id": "cust_123",
  "properties": {
    "credits": 2,
    "model": "gpt-4",
    "region": "us-east-1"
  },
  "event_id": "evt_abc123",
  "timestamp": "2025-08-22T07:05:49.441Z",
  "source": "api"
}

The hard parts sit around that payload.

Throughput. A product that bills on API calls or tokens can emit billions of events a month. That pushes you toward a streaming layer such as Kafka, Pulsar, or Kinesis, with a columnar store such as ClickHouse or Druid behind it for aggregation.

Normalization. Usage signals arrive from the application, from gateways, from caches, and from third-party APIs. Each source has its own idea of what a unit is. Getting them into one schema without double counting is a transformation problem, not a config problem.

Latency. If customers can see a usage dashboard, batch processing shows up as a support ticket. Near-real-time ingestion means a distributed path that holds up under burst without dropping events.

Integrity. Duplicate delivery and silent loss both corrupt an invoice, in opposite directions. Dedupe on a client-supplied identifier is the usual defence, which is why event_id is worth populating even though it's optional. Flexprice documents the full payload contract and the bulk endpoint in Sending Events, and gives you a per-event view in the Event Debugger for when a number looks wrong.

Metering and aggregation: turning events into billable quantity

Ingestion gives you rows. Metering turns rows into a number per customer per period, and that step is where most of the ambiguity lives.

Dimensionality. You rarely meter one thing. You meter per workspace, per end user, per model, per region, and sometimes all at once on the same event stream. The aggregation you pick (count, sum, average, max, count unique, latest, sum with multiplier, weighted sum) determines what you can bill for later, so it's a modelling decision made early. The aggregation reference covers the available functions.

Retries. If a customer's client retries a failed call, is that one billable event or two? The answer has to be the same every time, which means idempotency has to be decided at the meter, not left to whichever service happens to emit the event.

Time. Billing periods have edges. Customers sit in different time zones, subscriptions start mid-month, and proration has to agree with the meter about where the boundary is. Timezone handling and proration have to be defined once and applied consistently, or the meter and the invoice will disagree at period boundaries.

Lag. If the meter runs behind, a customer can blow past a quota before anything notices. By the time the aggregate catches up, the usage has already happened and someone has to decide who eats it.

Rating: applying the price to the quantity

Rating takes 12,000 API calls and produces a line item. The complexity is in the pricing rules, not the arithmetic.

Tiers, volume breaks, overage rates, minimum commitments, and segment-specific pricing all compose. A customer on an enterprise agreement may have a negotiated rate on one meter and standard pricing on everything else. That means price is a lookup against plan, customer overrides, and effective date, evaluated per line item.

Precision matters more than speed here. A rounding rule applied at the wrong level of aggregation changes totals across every invoice in the run, and it usually surfaces as a customer email rather than an alert.

Entitlements: enforcing what the plan allows

Metering tells you what happened. Entitlements decide what is allowed to happen next, and they run in the request path.

That means a quota check sits between your gateway and your handler, and it has a latency budget. It also means limits need to be soft or hard depending on plan, and changing a limit for one customer should not require a deploy. In Flexprice the limit lives on an entitlement, which is a feature linked to a plan, so it is data rather than code.

Rolling windows are the harder case. A limit of 1M tokens per 5 hours does not line up with a billing period, so it needs its own window tracking, an exhaustion signal, and a rule for what happens to usage past the quota. Entitlement grants handle that shape, firing a webhook on exhaustion and billing the excess as overage.

Overage behaviour is a product decision that engineering has to implement cleanly: notify and keep serving, charge the payment method, or block until the period resets.

Usage visibility: the dashboards customers expect

Usage-based pricing shifts spend risk onto the customer, so they expect to see the meter. That means a live usage view, threshold alerts before a limit is hit, and spend caps that actually stop consumption.

All three are real-time aggregation problems with high-cardinality dimensions. Alerts also need suppression logic, because a customer who gets six notifications about the same threshold stops reading them.

Revenue recognition: the part finance inherits

Variable revenue is harder to close and harder to forecast. Recognition has to follow actual consumption to satisfy ASC 606 or IFRS 15, which requires usage records retained at a granularity auditors can reconcile against invoices. Forecasting gets harder too, because the input is customer behaviour rather than a contract value.

What this adds up to

Usage-based pricing requires a metering and billing pipeline that handles high event volume accurately and with low latency. You need data engineering for ingestion, a deliberate model for metrics and pricing logic, integration with the product to surface usage, and audit paths rigorous enough to catch a bad number before a customer does. Most teams that build this in-house end up maintaining a second product alongside the one they set out to build.

Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud. Flexprice offers three deployment options, and all three run the same engine. Because Flexprice is open source and self-hostable, usage and revenue data can stay entirely inside your own infrastructure and never reach a vendor's cloud.

The ingestion path is the same one shown above. Post events, define aggregations against them, attach prices, and the invoice is computed from the stream.

curl --request POST \
  --url https://api.cloud.flexprice.io/v1/events/bulk \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: <your_api_key>' \
  --data '{
    "events": [
      { "event_name": "model.usage", "external_customer_id": "cust_123", "properties": { "credits": 2 } },
      { "event_name": "model.usage", "external_customer_id": "cust_456", "properties": { "credits": 5 } }
    ]
  }'

Up to 1,000 events go in a single bulk request. Both regions take the same payload: api.cloud.flexprice.io for India, us.api.flexprice.io for the US, authenticated with an x-api-key header.

If you want to see how the pieces fit before committing to any of it, the architecture overview is the place to start, and the repo is at github.com/flexprice/flexprice.

What changes when your billing system is open source

Flexprice — Mon, 21 Sep 2026 16:22:24 +0000

Billing is one of the few systems in a B2B product where the vendor gets to dictate your architecture. The platform decides how you integrate, how pricing is structured, and in some cases which processor you settle through. Every other critical dependency in a modern stack has a developer-friendly, inspectable option. Authentication does. Analytics does. Payments does. Billing mostly does not.

That gap is what open source billing infrastructure closes, and the difference shows up in specific places rather than as a general philosophy.

What does open source actually change for a billing system?

It changes where the code runs and who can read it. With an open source billing engine you can inspect the rating logic, run the whole system inside your own infrastructure, and extend it when your pricing outgrows what the vendor modelled. With a closed platform, none of those are options, and the workaround is usually a layer of custom code that reimplements part of the billing system anyway.

Integration on your terms

Billing sits in the middle of every B2B stack, and no two stacks are the same. Some teams settle through Stripe, some through Razorpay, some through Paddle, and some keep an internal ledger as the system of record. A billing layer that assumes one of those is the answer will fight the other three.

Flexprice is metering-first infrastructure built for usage-based and hybrid pricing, and it's not tied to any payment gateway. The metering and rating layer produces the amount owed. What collects that amount is a separate decision you keep.

That separation matters most when it changes. Adding a second processor for a new region should be an integration, not a billing migration.

Running it where your data already lives

The strongest argument for self-hosting a billing system is not cost. It's that usage and revenue data is some of the most sensitive data a company holds, and shipping all of it to a vendor's cloud is a decision that's hard to reverse once auditors and customers are involved.

Flexprice offers three deployment options, and all three run the same engine.

Your VPC. Deployed inside your own virtual private cloud on AWS, Azure, or GCP.
On-prem. Deployed inside your own data centre, in any geography.
Flexprice cloud. Fully managed by Flexprice, for teams that do not want to operate it themselves.

Because Flexprice is open source and self-hostable, usage and revenue data can stay entirely inside your own infrastructure and never reach a vendor's cloud. This is what makes Flexprice usable by companies with data residency, sovereignty, and audit requirements that hosted-only billing vendors cannot meet.

The self-hosting guide covers the deployment path, and the architecture page shows what the components are before you commit to running them.

Pricing that does not scale with your revenue

A large share of billing platforms take a percentage of the revenue they process. The logic behind that model is that billing volume tracks value delivered. In practice it means your billing bill grows every time you have a good quarter, for work that does not get harder as the numbers get larger.

Teams that hit this often respond by building billing in-house, which trades a recurring fee for a permanent maintenance cost and an on-call rotation nobody wanted.

Flexprice is open source and free to self-host. The managed cloud is priced per plan rather than as a share of revenue.

Composability, because pricing keeps moving

Flat subscriptions are no longer the default. Most products now run some combination of a base plan, metered usage, prepaid credits, feature gating, and add-ons, often on the same invoice. Closed platforms tend to model one of those well and treat the rest as an extension point.

Flexprice models them as primitives you compose. A metered feature is defined by an event name and an aggregation. A plan attaches prices to features. A wallet holds prepaid or promotional balance and draws down against usage. Whether you are metering GPU seconds, API calls, seats, or a business metric that only exists in your product, the modelling step is the same.

{
  "event_name": "gpu.seconds",
  "external_customer_id": "cust_123",
  "properties": {
    "seconds": 420,
    "instance_type": "a100"
  },
  "source": "worker"
}

That event is the unit of billing. Everything downstream, including aggregation, rating, credit drawdown, and invoicing, is configuration applied to the stream rather than code in your services.

The edge cases are the product

Proration on a mid-cycle upgrade. A downgrade that leaves unused prepaid credit. A refund that has to reverse a partially consumed entitlement. Multi-region tax handling. Retries that must not double bill.

These are the cases that consume the time of every team that builds billing themselves, and they are exactly the cases a closed vendor is least likely to prioritize, because each one affects a minority of customers. Open source changes the economics of that. A fix that matters to you can be read, patched, and contributed rather than filed and waited on. The contributing guide is the entry point if you want to work on the engine itself.

Pricing changes without engineering sprints

Treating billing as a finance system makes pricing static by default, because every change becomes a ticket. Teams that run pricing as an ongoing experiment need the opposite: new plans, packaging changes, and usage-based trials that go out without a deploy.

When plans, prices, and entitlements are data rather than code, changing them is a configuration change. That's the difference between testing a price point this week and scheduling it for next quarter.

Where to start

Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud.

Clone it, run it locally, and send an event through it before deciding anything else: github.com/flexprice/flexprice.

Usage-based or subscription pricing: how to choose

Flexprice — Mon, 21 Sep 2026 16:18:27 +0000

Someone on the team wants usage-based pricing shipped this quarter. Then an enterprise prospect says they can't sign a contract without a number they can budget, and the whole thing stalls. Both positions are correct, which is why the argument goes in circles.

The short version: charge for usage when value and cost rise together. Charge a subscription when value holds steady and your buyer needs a fixed number. When both are true, run both, which is where most AI and SaaS products end up.

What's the difference between usage-based and subscription pricing?

Subscription pricing charges a fixed recurring fee for access, regardless of consumption. Usage-based pricing charges for what a customer actually consumes, metered in units such as API calls, tokens, or compute seconds. That single difference drives everything downstream: revenue predictability, expansion behaviour, who your buyer is, and how much billing infrastructure you need.

Usage-based shows up as pure pay-as-you-go, tiered rates, volume pricing, or an included allowance with overages. AWS is the reference implementation, billing per second, per request, or per GB depending on the service.

Subscription shows up as flat rate, tiered plans, per seat, or per module. Slack is the familiar case: a published per user, per month rate, whether that person sends five messages or five hundred. The gap between the light user and the power user paying the same is where the dissatisfaction starts.

The four differences that decide most of it

Cost predictability. Subscription gives the buyer a number they can budget. Usage moves month to month and can produce a surprise invoice if nobody is watching the meter. Zylo's 2026 SaaS Management Index found that 78% of IT leaders reported unexpected charges tied to AI features or consumption-based pricing in the past year, and 61% cut projects because of unplanned SaaS cost increases. Bill shock kills deals the product had already won.

Value alignment. Usage-based ties cost to what the customer actually got. Subscription leaves light users paying for capacity they never touch.

Barrier to entry. Usage-based lets a customer start at almost nothing and grow into the bill. Subscription asks for commitment before the value is proven.

Revenue predictability. Subscription gives you steady recurring revenue that moves when you upsell. Usage revenue tracks customer activity, which is harder to forecast and expands without a new sale. Bessemer's State of the Cloud 2021 put usage-based companies roughly ten percentage points higher on net dollar retention than subscription-based peers, which is a dated benchmark but the direction has held.

Parameter	Usage-based	Subscription
Charge structure	Variable, based on consumption	Fixed per billing period
Revenue predictability	Moves with customer activity	Steady and recurring
Revenue expansion	Grows as customers use more	Needs an upsell or a new seat
Barrier to entry	Low, start small and scale	Higher, commitment upfront
Implementation	Real-time metering, roll-ups, retry and refund handling	Plan tiers and access control
Technical requirement	A metering and rating layer, built or bought	Payment integration and webhooks
Buyer reaction	Feels fair, but variability worries finance	Feels safe, but light users resent it
Raising prices	Harder, customers watch every bill	Easier to grandfather and raise for new signups
Fits	APIs, inference, compute, developer tools	Workflow tools, steady-usage SaaS

Six factors that place your product

Start with one fast filter: usage-based tends to fit products whose end user is other software, and subscription tends to fit products whose end user is a human. Software-to-software consumption grows without a natural ceiling and arrives with clean telemetry. A person can only watch so many videos, and charging them per action makes them hesitate before using the product.

That filter gets you an answer. The six factors below tell you how much to trust it.

1. Does value scale with usage, or plateau?

A gym charges the same whether you show up three times or thirty. An electricity bill tracks every unit. Software splits the same way.

Ask whether one more API call, workflow, or generated document creates more value for the customer or just more activity. Look at whether your heavy users six months in are clearly getting more out of the product than your light users. Check whether there's a natural ceiling on how much any one account can consume.

Value that climbs with activity points to usage. Value that plateaus after onboarding points to subscription.

2. Is there one clean metric you can meter?

Usage pricing needs a single unit that tracks value and can be measured reliably. If you can't name one, subscription is the more honest structure.

A workable metric correlates with the value different customers get, lets customers start small and scale, rises month over month for the average account, and is feasible to meter without inviting gaming.

Finding one is harder than it looks. A survey tool that charges per survey makes the customer hesitate before launching one. Charging per response is better aligned, except a response from a paying B2B customer is worth nothing like one from a free user. When no single unit is honest, mixing a subscription base with a usage fee usually beats forcing a bad metric.

3. Does your cost to serve rise with usage?

This is the factor AI teams feel most sharply, because model and compute costs move directly with token volume.

If gross margin shrinks when a customer doubles their usage, flat pricing quietly erodes your unit economics, and your most active account becomes your least profitable one. If marginal cost is near zero, flat pricing is safe.

4. Can customers predict their spend?

Usage pricing wins on fairness and loses on predictability, and lost predictability is what stalls deals.

Ask whether a customer could estimate next month's bill within a range they'd sign off on. Ask whether usage spikes unpredictably or follows a monthly pattern. Then ask whether you have caps, alerts, and a usage dashboard, because those are what make variable spend acceptable to a finance team.

Volatile usage points to usage-based only if you can ship the tools that make spend visible before it lands.

5. How does your buyer want to spend?

The mechanics can favour usage while the buyer still wants a fixed number, and the buyer usually wins.

A CFO signing a $50,000 annual contract knows what the year costs, and some will pay a premium for that certainty. A technical buyer optimizing spend wants the opposite and resents paying for capacity they don't use. If procurement requires a fixed contract number to approve the deal, that's your answer, or at least your floor.

6. How do your accounts grow?

Look at how your best accounts expanded in their first six months. This predicts the right model better than any framework.

Horizontal growth adds teammates, so value rises with participation and per-seat pricing fits. Vertical growth runs more workload on the same headcount, so two identical teams generate very different value and volume pricing fits. Dual growth does both, which is the textbook case for hybrid.

Run all six and a pattern shows up. Real conflict between them is itself the answer: if value scales with usage but your buyer needs certainty, or your cost to serve climbs while usage is spiky, that tension is what hybrid resolves.

The infrastructure question that comes first

Before committing to usage-based pricing, answer this: can you meter what customers use, accurately and in real time? If you can't, the model will hurt you regardless of how well it fits on paper.

Usage billing needs more than a payment gateway. It needs an ingestion path that reliably captures events, aggregation that rolls thousands of raw events into one correct total per period, rating logic for tiers, minimums, and overages, and a usage breakdown a customer can check against their own logs.

Idempotency matters more than it sounds. If the same event arrives twice because a network or SDK retried, the system has to count it once. Otherwise every retry is a double charge on a customer's invoice, and you find out when they email you.

{
  "event_name": "api.calls",
  "external_customer_id": "cust_123",
  "event_id": "req_7f31c9",
  "properties": { "endpoint": "/v1/generate" },
  "timestamp": "2026-07-17T10:22:31.004Z"
}

The event_id is the whole defence. A stable identifier from the emitter means the retry resolves to the same billable event. Sending Events covers the contract, and Validating Events covers checking what landed.

Simplismart reclaimed 30% of daily engineering bandwidth after moving billing to Flexprice rather than running metering as a second product. If you can't meter accurately yet, subscription is the honest call until the infrastructure catches up.

Why most teams end up hybrid

A hybrid model pairs a subscription base with usage on top. The customer gets a predictable floor, and revenue still grows with consumption.

A typical shape: $50 a month for platform access plus an allotment of credits, then a per-unit charge for anything beyond it. It gives the seller a revenue floor and the buyer a fair marginal price at the same time.

Hybrid is common, not universal, and it's worth knowing which shape a product you admire actually runs. Twilio, for instance, is explicitly pay as you go with volume discounts and no contract, which is pure usage rather than hybrid. A base fee is something you add when you need the floor, not a default every consumption business lands on.

Hybrid is also the hardest shape to implement, because a single invoice has to carry a recurring charge, metered usage, credit drawdown, and proration on any mid-cycle change. Hybrid pricing works it through end to end on a Resend-style plan, and prepaid and promotional credits covers the wallet side.

Choosing without locking yourself in

Teams rarely get burned by picking the wrong model. They get burned by picking billing infrastructure that makes changing the model expensive, which turns a pricing decision into a migration decision.

Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud. Flexprice offers three deployment options, and all three run the same engine. Because it's open source and self-hostable, usage and revenue data can stay entirely inside your own infrastructure and never reach a vendor's cloud.

Practically, that means the pricing model is configuration rather than code: define the metric, instrument the event once, configure meters and rate cards for usage, subscription, or both, and let invoicing assemble the result. Changing your mind later is a config change rather than a rebuild.

Start from Event Ingestion if you want to test whether you can meter your product before deciding how to price it.

How to track and bill real-time usage metrics in cloud services

Flexprice — Mon, 21 Sep 2026 16:13:00 +0000

Every API call, GPU minute, and gigabyte stored in a cloud product is a unit of value and a unit of accounting. Flat subscriptions let you ignore the second part. Usage-based pricing does not: the events have to be captured as they happen, aggregated with the right function, and converted into an invoice the customer believes.

The gap between "we log requests" and "we can defend this invoice" is where most teams discover they've built a data platform by accident.

What does real-time usage billing actually require?

It requires a pipeline with six stages: a defined billable event, an idempotent ingestion path, an aggregation layer that supports more than summing, a mapping from aggregated usage to prices or credits, invoice generation that draws down entitlements, and a customer-facing view of the meter. Skipping any stage moves the work somewhere worse, usually into a reconciliation script at month-end.

Why the real-time part matters

Customers on consumption pricing carry the spend risk. That changes what they expect from you. They want to see the meter while it runs, get warned before a threshold, and cap spend rather than discover it.

Batch billing breaks all three. A usage dashboard that updates nightly tells a customer what they spent yesterday, which is useless for controlling what they spend today. A quota that's evaluated in a nightly job can be blown through by lunchtime. And a surprise invoice is the most reliable churn trigger in consumption pricing.

Real-time here means the meter is current enough that a customer can act on it. That's a latency requirement on an aggregation path, not a marketing adjective.

The failure modes

Event volume. Cloud and AI workloads produce millions of micro-events a day. Each one has to be logged, attributed to a customer, and counted exactly once.

Aggregation variety. Some metrics sum. Some are unique counts, like monthly active users. Some take the latest value, like concurrent connections. Some need a formula, like tokens weighted by model. A system that only sums forces the rest into application code.

Mapping to price. Prepaid credits, entitlements, and tiers all sit between a quantity and a charge. This is where improvised systems usually break, because each pricing construct gets added as a special case in a different place.

Reconciliation. Events arrive late, arrive twice, or don't arrive. Without idempotency and a retry story, invoices drift and no one can say by how much.

Change. You charge per API call now. Next quarter it's per token, or a hybrid of both with a credit wallet in front. Pricing logic hardcoded into services means every pricing change is a deploy across every service that emits usage.

Most teams meet these with a few scripts and a usage add-on bolted onto a subscription tool. Those patches quietly become the revenue engine.

The pipeline, stage by stage

1. Define the billable event

Decide what counts, and attach enough metadata to bill and to audit: a customer identifier, a timestamp, the unit, and any dimension you might want to price or group by later.

{
  "event_name": "gpu.seconds",
  "external_customer_id": "cust_123",
  "properties": {
    "seconds": 420,
    "instance_type": "a100",
    "region": "us-east-1"
  },
  "event_id": "evt_7c31bd",
  "timestamp": "2025-10-07T11:04:12.001Z",
  "source": "scheduler"
}

Adding a dimension later is cheap. Backfilling one you didn't record is not, because the events are gone. Err toward recording the dimension.

2. Ingest in real time, idempotently

Events flow from your services into the pipeline through direct API calls, an event stream, or a collector. Whatever the transport, the ingestion contract has to be idempotent. A client-supplied event_id is the usual mechanism: the same identifier arriving twice resolves to one billable event.

For high-frequency emitters, batch rather than sending per event.

curl --request POST \
  --url https://api.cloud.flexprice.io/v1/events/bulk \
  --header 'Content-Type: application/json' \
  --header 'x-api-key: <your_api_key>' \
  --data '{
    "events": [
      { "event_name": "gpu.seconds", "external_customer_id": "cust_123", "event_id": "evt_7c31bd", "properties": { "seconds": 420 } },
      { "event_name": "gpu.seconds", "external_customer_id": "cust_456", "event_id": "evt_7c31be", "properties": { "seconds": 95 } }
    ]
  }'

The bulk endpoint accepts up to 1,000 events per request. That host serves the India region; https://us.api.flexprice.io/v1 serves the US. The API key goes in the x-api-key header on both.

If usage already flows through Kafka, a webhook, a database, or files, a collector avoids instrumenting emitters a second time. Flexprice documents that path in Collectors, which is built on Bento and handles retries and delivery guarantees for you.

3. Aggregate

Pick the function per metric rather than per system.

Sum for total requests or compute seconds in a period.
Count unique for distinct users or agents.
Latest for concurrent sessions or seat count.
Max for peak usage in the period.
Sum with multiplier when a summed property needs scaling by a rate, such as tokens weighted by model.
Weighted sum for time-proportional totals, such as capacity held over part of a period.

These belong in configuration on the metered feature, not in a query someone wrote once. The aggregation reference lists what each function does to the event stream.

4. Map usage to pricing

Aggregated quantity becomes a charge through tiers, entitlements, or credits.

Credit models are common in AI products because they decouple the price the customer sees from the unit you meter. A conversion rate turns metered units into credits, and grants add balance on a recurring or one-time basis.

Flexprice models this with wallets. A wallet can be scoped to recurring charges, usage charges, or both, and credits deduct automatically before the default payment method is charged. Prepaid and promotional credits covers how that scoping works.

5. Generate invoices

Usage flows into invoice line items with credits deducted as they're consumed rather than reconciled afterwards. Calendar billing periods are easier to operate than per-customer anniversary cycles, because every customer's period closes on the same boundary and a late event has one obvious home.

Invoices should be previewable before they finalize. A number you can inspect on the 28th is cheaper than a correction issued on the 3rd.

6. Expose the meter to customers

Live usage views, threshold alerts, and spend caps are the customer-facing half of the pipeline, and they're what stop billing disputes before they start.

Alerts need suppression logic. A customer who receives six notifications about the same threshold stops reading the seventh, including the one that matters.

One detail that catches teams out: a credit wallet has two balances, and they answer different questions. The settled balance only moves when a transaction completes, which makes it the right number for accounting and reconciliation. The ongoing balance subtracts in-period usage and pending invoices continuously, which makes it the right number for entitlement checks, low-balance alerts, and auto top-up. Reading the wrong one is how a low-balance alert fires late. Wallet balance types spells out the difference.

What this looks like as infrastructure

Against the pipeline above: ingestion accepts single or bulk events with duplicate handling, aggregation strategies are configuration on a metered feature, wallets handle credit conversion and scoping across recurring and usage charges, invoices assemble from billable records with credit drawdown applied, and usage is queryable for customer-facing views. Because Flexprice is open source and self-hostable, usage and revenue data can stay entirely inside your own infrastructure and never reach a vendor's cloud.

The decision worth making early is not which vendor to use. It's whether pricing logic lives in your services or in a layer you can change without a deploy. The second option stays cheap as pricing evolves.

Start with the architecture overview if you want to see the components before running anything.

How to run pricing experiments without breaking billing

Flexprice — Mon, 21 Sep 2026 16:06:30 +0000

Changing a number on a pricing page is the easy part of a pricing experiment. The hard part is that the number is attached to live subscriptions, invoices that have already been issued, customers who signed under the old terms, and a finance close that has to reconcile both variants in the same month.

That's why most pricing tests either never ship or ship once and never get repeated. The system underneath makes each one expensive.

What does it take to run a pricing experiment safely?

You need four things: a hypothesis with one variable, a clean way to assign customers to a variant, prices stored as versioned data so the old and new rates can coexist on the same billing run, and enough time on the test to see retention rather than only conversion. Miss the third and every experiment becomes a migration. Miss the fourth and you ship a result that reverses in month two.

What you can actually test

Price level. The control group sees $59 a month, the variant sees $49, features and onboarding identical. The only variable is the number. This is the cleanest test to run and the easiest to read.

Packaging and bundling. Combine features into a bundle at a discount to buying separately, or let customers assemble their own. What you learn is which combinations people actually want, which usually differs from how the product is organized internally.

Tier structure. Three plans at different price points with different feature sets. The useful signal is what a customer needs before they move up, which matters more than which tier converts best.

Freemium boundaries. Where the free tier ends is itself a variable. Moving a limit or a feature across that line changes both conversion and the cost of serving free users.

Discounts and promotions. A time-bound offer against a control group tells you whether a discount expands volume or just lowers revenue per sale. Run this one carefully, because the group that got the discount now has an expectation.

Price presentation. How a price is displayed changes response independently of the price itself. It's a real variable, and it's worth isolating rather than mixing into a level test.

The metrics that decide the result

Conversion rate alone will mislead you. A lower price converts better almost every time, and that tells you nothing about whether it was a good idea.

Track the full set:

Trial to paid conversion. The headline number, and the one that moves first.
Monthly churn. Whether the customers a lower price attracted are the ones who stay.
ARPU. Revenue per active customer, which moves against conversion.
LTV. The number that actually settles a price-level question.
Payback period. How long acquisition cost takes to recover under the new price.
Cost to serve. Especially with usage pricing, since a cheaper price can attract heavier accounts and compress margin even as revenue grows.

Revenue per user minus cost to serve is the number that determines whether a variant wins. Everything else is an input to it.

The framework

1. Write the hypothesis and pick the target

Make it specific and measurable, with a deadline. "Increase trial to paid conversion by 12% over four weeks by lowering the entry price to $49" is testable. "See if cheaper works better" is not.

The target should also connect to the company's actual goal. Optimizing ARPU when the strategy is to widen the base produces a local win and a strategic loss.

2. Segment, then assign

Decide which customers are in scope. Usage maturity, company size, geography, and acquisition channel all produce genuinely different price sensitivity, and mixing them adds noise that a small sample cannot absorb.

Assignment should be random within the segment and stable per customer. A customer who sees one price at signup and a different price on their second visit is a bug, not a variant.

Keep segmentation to business characteristics. Usage level, plan, and region are fine. Protected characteristics are not.

3. Design the test

One variable. If price and feature access both move, the result is uninterpretable and you'll run it again.

Give it enough time. Two to four weeks is a practical floor for conversion signal, and longer if you need churn, because a monthly plan produces its first churn data point after a full cycle. Low-volume products need longer still, since the sample accumulates slowly.

Decide up front what you'll do with each outcome. Pre-committing to the decision rule is what stops a marginal result from becoming a post-hoc argument.

4. Run it without forking your billing

This is where the engineering work sits. Two prices for the same product have to coexist, be attributed correctly on every invoice, and be reversible.

If prices are constants in application code, this means a branch in the billing path and a cleanup project afterwards. If prices are versioned data attached to a plan, the variant is a second price record with its own effective dates, and the invoice run resolves whichever applies to that subscription.

The practical requirements:

Versioned prices with history. You need to reproduce any past invoice at the rate that applied then.
Per-customer overrides. So a variant or a negotiated rate doesn't require cloning the whole plan.
Proration on switches. A customer who moves mid-cycle should be billed correctly for both segments without manual adjustment.

Flexprice handles the first two as price overrides on a subscription and plan cloning when you want a full variant, and documents the mid-cycle behaviour in Understanding proration.

5. Monitor for side effects

Watch conversion, usage growth, churn, revenue, ARPU, and cost to serve together. The failure mode is a variant that wins on the metric you were watching and loses on the one you weren't.

Tell your own teams. Support will field questions about why two customers see different prices, and sales needs to know which rate is real before a call.

6. Analyze, then decide grandfathering

Compare against control on every metric, not just the target. Segment the comparison, because a variant can win overall while losing badly in the segment that produces most of your revenue.

Then handle existing customers deliberately. Grandfathering on the old rate indefinitely is the least disruptive option and the one that accumulates pricing debt. A migration with notice is cleaner and costs goodwill. Either is defensible. Doing it quietly is not, because customers compare notes.

7. Feed the result into the next test

One experiment should generate the next hypothesis. If high-usage customers turn out to be sensitive to per-unit increases, the next test is packaging or overage thresholds rather than another level change.

The constraint on iteration speed is almost never analysis. It's how long a pricing change takes to ship.

Common ways experiments fail

Too many variables. Price, bundle, and billing frequency all moving at once produces a number you can't attribute.

Too short a window. Early lifts revert. A test that ends before the first renewal cycle has measured acquisition, not economics.

Ignoring churn. Higher conversion with higher churn is usually a worse business.

Ignoring cost to serve. A cheap price that attracts heavy usage can grow revenue and shrink profit at the same time.

Confusing customers. Different prices are fine. Different prices discovered accidentally are a trust problem.

Teams out of sync. Pricing touches product, sales, support, and finance. One team learning about a change from a customer is how a good experiment becomes an incident.

Products worth studying

A few developer-facing products publish enough of their pricing to learn from. These are five different answers to the same problem, checked in September 2026.

Netlify runs a plan fee plus a monthly credit allowance: 300 credits on Free, 1,000 on Personal at $9, 3,000 on Pro at $20, unlimited on Enterprise. Consumption is priced in credits, at 15 per production deploy, 10 per GB-hour of compute, 20 per GB of bandwidth, and 2 per 10k web requests, with auto-recharge packs when the balance runs down.
Vercel keeps a flat plan fee, $0 on Hobby and $20 on Pro, then meters per resource past a published allowance. Pro includes 10M edge requests a month and charges from $2 per 1M after that, and includes 1TB of fast data transfer then charges from $0.15 per GB.
Supabase splits the bill in two: an organization plan starting at $25 a month on Pro, plus per-project compute billed separately, with $10 of compute credits included. Overage rates are published per resource, such as $0.09 per GB of egress and $0.00325 per monthly active user past 100,000.
RunPod is pure pay as you go on GPU compute, billed per hour or per second with no plan fee. It's the most legible model on this list and the one that puts the most tracking burden on the customer.
ElevenLabs sells subscription tiers that each carry a monthly credit allowance, from 10k credits on Free up to 6M on Business at $990 a month, with Enterprise quoted.

Two things are worth taking from that spread. Credits show up repeatedly as the unit customers see, because they decouple the price on the page from the resource actually being metered. And in every case the allowance and the overage rate are published together, which is what lets a customer estimate the bill before committing. That predictability is what makes usage pricing survivable, and it's the thing an experiment most often breaks.

What makes experiments cheap to repeat

Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud.

For pricing experiments specifically, plans and prices are configuration rather than code, so a variant is a record instead of a release. Usage is metered in real time across both arms, invoices generate from the same engine under either price, and the history is retained so a past invoice can be reproduced at the rate that applied then.

There is also a simulation layer worth knowing about before you touch a live price. Flexprice scenarios let you copy your current pricing into a hypothesis, change the rates or the packaging, and duplicate it to compare variants side by side, with no end-customer consequences. How to evolve pricing covers that workflow. Modelling a variant against your existing price set is the cheapest way to kill a bad hypothesis before it reaches a customer.

How to implement usage-based billing for a SaaS product

Flexprice — Mon, 21 Sep 2026 16:02:14 +0000

One customer logs in twice a month. Another burns through a million API calls a day. Both pay the same, because the plan was priced when every account looked roughly alike. Finance wants the invoice to reflect reality, engineering wants pricing out of the request path, and billing ends up on whoever touched it last.

Usage-based billing fixes the pricing mismatch and introduces metering, aggregation, entitlements, credits, and invoice generation as new systems to get right. Here's the order to build them in.

What does implementing usage-based billing involve?

Five things: choosing a usage metric that tracks the value your product delivers, building a metering pipeline that captures every billable event exactly once, modelling the pricing on top of the aggregated usage, connecting billing to invoicing and payments, and exposing the meter so customers can see what they're spending. Everything after that is edge cases, and there are more of them than the first version assumes.

1. Choose the usage metric

Charge for the action that carries value, not the action that's easiest to count.

A video platform that bills per upload prices a ten-second clip the same as a one-hour recording. Billing per minute rendered tracks both the cost of serving the request and the value the customer got. That alignment is what makes a price defensible when a customer asks why their bill moved.

What this usually looks like by product type:

AI products: tokens processed, inference calls, or model seconds.
Cloud and data platforms: stored gigabyte-months, compute seconds, egress.
API products: requests, often segmented by endpoint class.
Agent platforms: sessions, runs, or distinct agents active in a period.

Then decide the granularity. Discrete counting records each event. Aggregate measurement records a volume over a window, such as GB-months. The two produce different event schemas, so pick before you instrument.

Say the price in the customer's terms. "$1 per 1,000 API calls" is checkable. A composite unit nobody can compute by hand generates support tickets for as long as it exists.

2. Build the metering pipeline

The pipeline has one job: every billable action becomes exactly one event, attributed to the right customer, with the properties needed to price it.

Capture at the source. Emit from the service that performs the work, not from a log parser downstream. Parsing logs for revenue data means a logging change silently becomes a billing change.

Carry an idempotency key. Every event gets a stable identifier from the emitter. A retried request that reuses the identifier resolves to one billable event. Without it, retries inflate invoices in a way that's invisible until a customer complains.

Normalize the timestamp. UTC, ISO 8601, set by the emitter rather than the receiver. Receiver timestamps make late events land in the wrong billing period.

Enrich before storing. Attach customer ID, project or environment tags, and the feature key at emit time. These are the dimensions you'll later want to price by, group by, or show in a customer dashboard.

{
  "event_name": "render.minutes",
  "external_customer_id": "cust_123",
  "properties": {
    "minutes": 42,
    "project": "proj_88a1",
    "resolution": "1080p"
  },
  "event_id": "evt_0b41f7",
  "timestamp": "2025-10-31T09:12:00.000Z",
  "source": "render-worker"
}

Keep raw events. Roll-ups are derived. Keeping the raw stream is what lets you answer a dispute, re-run a period after fixing a bug, and backtest a pricing change against real history.

Handle volume. High-frequency emitters should batch. If usage already flows through Kafka, a webhook, or a database, route from there rather than instrumenting twice.

In Flexprice this side is a metered feature: an event name plus an aggregation, defined once, with the raw events queryable behind it.

3. Model the pricing

Pricing logic converts an aggregated quantity into a charge. The models below cover most SaaS and AI products, and they compose.

Pay as you go

Customers pay per unit consumed with no commitment. Simple to explain, low friction at signup, and revenue that tracks adoption directly. The tradeoff is revenue that's hard to forecast, since there's no floor.

Tiered or volume pricing

The per-unit rate drops as volume grows. For example 0 to 1M calls at $0.002, 1M to 10M at $0.0015, and lower beyond that. This works when your own unit costs fall with scale.

Decide early which of the two tier behaviours you mean, because they bill differently on identical usage. Volume applies a single rate to the entire quantity, chosen by the tier the total lands in. Slab, also called graduated, splits usage at each boundary and prices every slice at its own rate. Against tiers of 0 to 10,000 at $0.0010, 10,001 to 50,000 at $0.0008, and 50,001 to 100,000 at $0.0006, a customer making 65,000 calls owes $39 under volume and $51 under slab.

In Flexprice this is a price with billing_model: TIERED and a tier_mode of VOLUME or SLAB. The volume tiered doc works through the volume case with that same example.

Hybrid

A fixed base fee plus a usage component. A customer pays $100 a month covering 100K calls, then $0.001 per call beyond that.

Hybrid gives you a revenue floor and gives the customer a predictable baseline. It's the most common shape in production SaaS pricing, and the one that puts the most pressure on proration, because a mid-cycle plan change has to split both the fixed and the variable side. Hybrid pricing is a worked example modelled on Resend: one plan carrying a recurring charge, usage charges, and entitlements that gate features per tier.

Credit wallets and prepaid bundles

Customers buy credits up front and consumption draws the balance down. One credit might equal 1,000 tokens or one GPU minute.

Wallets suit workloads where daily consumption swings hard, because the customer controls exposure by controlling top-ups. They also need rules: expiry, auto top-up thresholds, and a priority order when promotional and purchased balances coexist. Prepaid and promotional credits covers the balance types.

Commitments and discounts

Enterprise deals involve negotiated terms: an annual minimum, a volume discount, or bonus credits against a committed spend. These are contract terms the billing system has to hold as data, including the effective dates, because they'll be renegotiated and you'll need to know which version applied to which invoice.

4. Connect billing, invoicing, and payments

An invoice should list each metric, the units consumed, and the resulting cost, with every line traceable to the events behind it. That traceability is what turns a disputed charge into a two-minute answer.

Connect the payment gateway so collection is automatic, and add retry logic for failed payments so recovery doesn't depend on someone noticing. Revenue recognition needs the same care: hybrid models produce overlapping periods where the fixed fee and the usage charge recognize differently.

5. Make the meter visible

Real-time usage views and threshold alerts prevent the surprise invoice, which is the main churn driver in consumption pricing. Alerting at a percentage of typical usage gives a customer time to act rather than time to be annoyed.

Describe units in the customer's language. "100 messages processed" lands better than "100 API calls made" for a non-technical buyer, even when they're the same event.

Internal observability matters just as much. Track events from ingestion through to invoice so you can see where a count dropped, which is how revenue leakage gets found before an auditor finds it.

6. The edge cases that arrive with scale

Late and out-of-order events. Decide a tolerance window and what happens to events that miss it. Both choices have revenue consequences, so make them explicitly.

Duplicates. Covered by idempotency keys if you set them at step 2. Retrofitting them later means a period where you can't fully trust the totals.

Mid-cycle plan changes. Versioned prices with rate history, plus automatic proration. Without stored rate history you can't reproduce an old invoice, which is a problem the first time someone asks you to.

Multi-tenant attribution. One account, several teams or environments. Customers want their own breakdown, so the dimension has to be on the event, not inferred later.

Forecasting. Variable revenue is harder to predict. Usage history is the input, which is another reason to keep the raw stream.

Build, buy, or open source

Building in-house gives full control and costs you the engineers you hired for the core product, permanently. The edge cases above are not a one-quarter project, and they don't stop arriving.

Buying a closed platform is faster and trades flexibility for it. The constraint shows up when your pricing model moves past what the vendor modelled, and the workaround is custom code that reimplements part of the billing system anyway.

Open source sits between them. You start from a working engine and keep the ability to read and change it.

How to roll it out

Prove the chain end to end on one metric before extending it across the product.

Instrument a single billable event and get it flowing. Aggregate it on a period. Simulate pricing against real historical usage before committing to a number. Ship a usage view so customers can see the meter from the first day it runs. Then pilot on one feature or one customer tier, watch how the totals hold up under real volume, and expand from there.

Clone the repo and push your first event through it: github.com/flexprice/flexprice.

How to design tiered pricing for a SaaS product

Flexprice — Mon, 21 Sep 2026 15:58:45 +0000

Most tiered pricing problems show up as engineering problems. Marketing wants to move a feature from Growth to Starter, and that turns into a sprint because the gate is a boolean in three services. Sales wants a limit raised for one account, and that becomes a deploy because the limit is a constant. Meanwhile the entry plan does too much, the top plan does too little, and nobody upgrades.

The structure of the tiers and the system that enforces them are the same design problem. Getting the first right and the second wrong means the pricing page stops matching the product within two quarters.

What makes a tiered pricing model work?

A tier model works when each tier maps to a real customer segment, limits are set from observed usage rather than invented, features are placed by value rather than by what's easy to gate, and the whole thing is stored as data so changing it doesn't require a release. The pricing page is the visible half. The entitlement system is the half that decides whether you can iterate.

The design constraints

A value metric that tracks customer outcomes

The number that separates tiers should be something a customer can predict and something that grows as they get more value from the product. API calls, active users, projects, or messages processed all work. Anything a customer can't estimate before signing up will be estimated wrong, and the correction arrives as a support ticket.

Feature placement that doesn't feel punitive

Do not gate things customers expect at any paid level. Locking a basic capability behind an upgrade reads as a tax rather than a feature, and it produces complaints instead of conversions. Reserve gating for capabilities that genuinely cost more to deliver or that only matter at scale.

A useful split:

Table stakes. Available on every paid plan. Gating these costs more goodwill than it earns revenue.
High impact. Capabilities that matter once a customer is scaling. These belong to the middle and top tiers.
Security, control, and integrations. SSO, audit logs, role-based access, private deployment. These map to the buyer at the top tier and are the usual reason they're there.

Limits derived from actual usage

Set limits from your usage distribution, not from round numbers. A limit that sits where real customers naturally cross it produces upgrades that feel earned. A limit set arbitrarily below where people work produces churn and a reputation for nickel-and-diming.

Whatever you pick, warn before the wall. A customer who gets told at 80% has time to decide. A customer who finds out at 100% has an outage.

Tiers that mirror segments

Three tiers covers most products, because each one should answer a different buyer.

Free or Starter. Limited but genuinely functional. Its job is to let someone succeed once.
Growth or Pro. The default choice and the main revenue line. Priced and packaged for the segment you actually serve.
Advanced or Enterprise. High scale, negotiated terms, security and control requirements.

If a tier can't be described in one sentence with a named buyer, it's an internal artifact rather than a plan.

Price ratios that read at a glance

Simple multiples make progression legible. Starter at 1x, Growth at 2x to 3x, Advanced at 4x to 5x is a common shape because a buyer can compare the steps without doing arithmetic. Random gaps make the page feel arbitrary even when the numbers are well reasoned.

Support as part of the package

Response times and support channels are frequently the reason a larger customer moves up a tier, and they're cheaper to differentiate than features are. Make the difference explicit on the page rather than implied.

Building it: seven steps

1. Name the objective. Higher ARPU, cleaner segmentation, or less sales friction. These pull in different directions, so pick one to optimize. Vague goals produce tiers that are defensible in a meeting and confusing on a pricing page.

2. Segment, then pick the metric. Three or four segments based on real usage maturity. Talk to customers in each about what they rely on and what they'd pay more for.

3. Design three tiers with clear roles. Each needs a target user, a purpose, and an upgrade trigger you can point at in the data.

4. Place features and limits deliberately. Map every feature to table stakes, high impact, or control. Tie limits to the value metric so customers graduate by growing rather than by hitting a wall.

5. Price from value, bounded by cost. Your floor is the unit cost plus the margin you need. Your ceiling is the value the product delivers to your largest customers. Pick inside that range and validate against current accounts before publishing.

6. Ship it as configuration. This is the step that decides how much the next five changes cost. More below.

7. Watch behaviour and iterate. Track signups, upgrades, downgrades, limit hits, and support volume per tier. If Growth takes every upgrade and Advanced sits unused, the feature split is wrong. If customers hit a limit in week one, the limit is wrong.

The implementation that decides whether you can iterate

A tier is two things in the system: a set of prices, and a set of entitlements that the product checks at runtime.

The prices are the easy half. The entitlements are where teams paint themselves into a corner, usually by encoding the plan in application code:

# The version that guarantees a sprint per pricing change
if user.plan == "pro":
    max_projects = 25
elif user.plan == "enterprise":
    max_projects = 500
else:
    max_projects = 3

Every limit change is a deploy. Every new plan touches every service holding one of these blocks. A one-off limit for a negotiated deal is either a hardcoded special case or a fourth plan nobody wanted.

The alternative is to treat entitlements as data the product reads:

curl --request GET \
  --url 'https://api.cloud.flexprice.io/v1/customers/external/cust_123/entitlements' \
  --header 'x-api-key: <your_api_key>'

That is the customer entitlements endpoint, keyed by your own customer identifier so the gate can run at the edge. Swap the host for us.api.flexprice.io on the US region. The plan defines the grant, the customer's subscription resolves to a set of entitlements, and the product asks what this customer is allowed to do rather than inferring it from a plan name. Changing a limit becomes a configuration change that takes effect without a release, and raising a limit for one account is an override rather than a new SKU.

In Flexprice the primitive is an entitlement: a feature linked to a plan with its usage limit configured there rather than in your services. Linking features to plans covers how a tier gets assembled that way, and price overrides handle a negotiated deal at subscription creation without cloning the plan.

If a per-billing-period limit is too coarse, entitlement grants turn it into a quota per window, something like 1M tokens per 5 hours, independent of the billing cycle. Windows can stack, a webhook fires when a quota is exhausted, and usage past it bills as overage.

Usage limits also need real-time enforcement to be worth anything. A quota evaluated by a nightly job can be exceeded all day. That means the check sits in the request path with a latency budget, which is a reason to keep the entitlement lookup a cached read rather than a computation.

Why tiered pricing changed SaaS monetization

Revenue tracks customer growth. Flat pricing charges the same whether a customer barely logs in or runs your product as core infrastructure. Once usage varies widely across the base, one price is wrong for almost everyone.

One model serves both ends. Self-serve buyers want predictability and no surprises. Enterprise buyers want flexibility, control, and security. Tiers serve both without splitting the product into two.

Expansion happens without a sales motion. When tiers match customer maturity, the upgrade happens because the product got more important to their workflow. That's a very different conversation from an upgrade triggered by hitting a wall.

All three depend on the same thing: the ability to change the model without a release cycle. If moving a feature between plans requires engineering time, the pricing stops evolving and the packaging drifts away from the product.

Where Flexprice fits

Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud.

For tiered pricing specifically, that means plans, prices, limits, and entitlements live as configuration the product queries, so a packaging change doesn't touch your services. Tiers also compose with usage-based charges, credit wallets, and negotiated enterprise terms on the same subscription, which matters when the three-tier page stops being enough.

Read Creating a plan to see the shape of a tier before deciding how to model yours.

How to choose enterprise billing software

Flexprice — Mon, 21 Sep 2026 15:31:05 +0000

A billing setup built for self-serve SaaS usually survives until the first real enterprise contract. Then a deal arrives with a multi-period ramp, a custom credit grant, a committed usage floor, and a quarterly true-up, and a clean subscription setup turns into scripts, spreadsheets, and engineering tickets.

The compounding is the problem. Finance ends up in Excel, engineering writes more billing code than product code, and by year two the question stops being whether to switch platforms and becomes how to switch without breaking revenue recognition.

What is enterprise billing software?

Enterprise billing software is a cloud or self-hosted platform that handles invoicing, contract management, usage metering, subscription lifecycle, and revenue recognition at enterprise scale. It's the system of record for every dollar invoiced, every event consumed, and every line item an auditor will read at close.

The difference from a standard billing tool shows up the moment you sign a contract that doesn't look like a credit card checkout. Enterprise billing has to handle high-volume event processing, negotiated contracts with ramps and commitments, audit trails that satisfy ASC 606, IFRS 15, and SOC 2, and role-based access for finance, sales, engineering, and external auditors at the same time.

The features your shortlist has to clear

Skip any of these and your engineers write the missing piece while finance backfills the rest in spreadsheets.

Phased contracts

Enterprise deals aren't monthly subscriptions. The platform has to model ramps across periods, free months at the start, step-up commitments tied to fiscal milestones, mid-term escalators, and scheduled price changes that roll automatically.

A concrete test for any vendor: ask them to model a 24-month contract at $50K in year one, $100K in year two, with the first month free. If that needs a custom script or a professional services engagement, it will need one for every enterprise customer you close afterwards.

Real-time event metering

If you charge for usage, metering is where revenue is either captured or lost. What matters:

Ingestion with a documented throughput profile.
Idempotent event APIs, so retries don't double count.
Deduplication by event ID.
Configurable aggregation including sum, count, max, average, and unique values.
Defined handling for late-arriving events, retroactive corrections, and replay.

Throughput is the easy question and the one every vendor is ready for. The edge cases matter more: if a late event or a replay needs a support ticket each time, you've hired a full-time engineer to babysit billing.

Dunning workflows

Failed payments are a meaningful share of churn at most subscription businesses, and the recoverable portion depends almost entirely on the retry logic.

A real dunning engine lets you configure retry schedules, commonly day 0, 3, 7, and 14, with a tighter cadence for high-value accounts. Smart retries adapt to the decline code, so insufficient funds and a fraud block get handled differently.

Beyond retries, look for pre-dunning notifications such as card-expiring and low-balance warnings, branded sequences segmented by customer tier, account-state thresholds that decide when a failure triggers a pause or a suspension, and webhook events at every state transition so customer success can intervene on the accounts worth intervening on.

The red flag is a global-only setup. If you can't run different recovery flows for a $500K account and a $5K account, you're leaving money on the table every month.

Compliance and security

Your billing platform holds payment details, contract values, usage records, and revenue numbers. Treat security as a first-order buying criterion rather than a procurement checkbox at the end of the cycle.

SOC 2 Type II. A current report, not Type I and not "in progress". Type I confirms the policies exist. Type II confirms an auditor verified the controls operated over a period.
ISO 27001. Often required by EU and APAC procurement alongside SOC 2.
PCI DSS Level 1. Required if the platform touches card data anywhere, including through a tokenization handoff.
HIPAA. Required for healthcare, with a signed BAA rather than a claim of alignment.
GDPR and CCPA. Required for European or California customers, with a DPA available without an enterprise upsell.

The most useful question in a security conversation: can you see the most recent SOC 2 Type II report and the latest pen test executive summary under NDA? Hesitation, a redirect to a marketing page, or a stall until the order form is signed all answer the question.

Audit trails

Every change to a price, plan, invoice, contract, or customer record should leave a timestamped, immutable record of who changed what and when. This is the floor for SOC 2 and the first artifact you reach for when someone asks why a customer was billed $40K more than expected.

Look for separation of duties between price setters and approvers, approval workflows on high-value changes, and log storage that platform admins can't edit.

Entitlements

Pricing decides what a customer pays. Entitlements decide what they can use. They're the same decision, and a platform should treat them that way, with real-time checks the product calls directly rather than the same logic maintained across three services.

Questions worth asking during evaluation:

What happens when a customer hits a hard limit mid-period: block, throttle, queue, or convert to overage?
Can entitlements aggregate across multiple subscriptions under one parent customer?
Can sales grant a per-customer entitlement bump without modifying the plan?

APIs, webhooks, and SDKs

Treat the developer surface as a buying criterion. Every action available in the UI should exist in a versioned, documented API.

Webhooks specifically need at-least-once delivery with retries, signed payloads, documented event schemas, and a test mode that mirrors production. Flexprice documents its webhook behaviour, and also exposes the API through an MCP server if your team works from an editor or agent.

A rate-limited API with partial coverage is the clearest signal that the UI is the real product, and you'll hit that wall within six months of building on it.

Multi-currency

Native multi-currency means the pricing table maps each tier to amounts per currency, version controlled and dated. Enterprise deals usually lock a negotiated currency while self-serve runs on rates that refresh on a schedule.

At the accounting layer, the platform should load FX rates from a trusted source, revalue foreign-currency balances at close, and post unrealized gain or loss automatically. If revaluation isn't part of the close workflow, finance is doing it in Excel and the errors compound quarterly.

Multi-entity

Billing the same customers from a US, UK, and APAC entity means each needs its own tax profile, invoice number sequence, revenue recognition schedule, payment processor, and permissions.

Intercompany is the harder half. Ask for a live demo of one parent customer with subscriptions billed by two entities, with intercompany allocation and a consolidated view. If it can't be shown live, it doesn't exist.

Transparent metering for customers

Surprise invoices are the main escalation trigger on usage-priced products. A metering UI that shows the customer how the bill was calculated is the cheapest support investment available.

Look for a live consumption view with projected end-of-period totals, drill-down from a line item back to the underlying events, alerts at configurable thresholds, and a usage API so you can render the same data inside your own product.

Contract overrides

No two enterprise contracts are identical, so prices, commitments, credits, payment terms, and billing cycles all need contract-level overrides. Cloning an entire plan for every slightly different deal produces a plan catalogue nobody can reason about within a year. Price overrides should be something sales can apply for standard cases without engineering.

Correct invoices

The minimum set: branded templates with multi-language and multi-currency support, attached usage breakdowns, PDF generation tied to the billing cycle, configurable payment terms, sequential numbering with legal integrity, and clean credit note and reissue flows.

For global rollouts, e-invoicing formats matter more every quarter. UBL, Factur-X, Peppol, and country-specific mandates such as Italy's SDI, Mexico's CFDI, and India's IRP are increasingly required by tax authorities.

Integrations

Billing data has to reach the CRM, ERP, warehouse, close tools, and product analytics. The minimum connector list for an enterprise shortlist covers Salesforce and HubSpot, NetSuite, QuickBooks and Sage Intacct, Stripe and other processors, a tax engine, and Snowflake or BigQuery.

Support

At the enterprise tier, expect a named contact, a shared channel, a defined P0 response time, a documented escalation path, and post-incident root cause documents you can forward to finance.

Don't ask whether enterprise support is offered. Ask what happens at 11pm when the automated invoice run fails for 800 customers. The specificity of the answer tells you what you're buying.

Grandfathered pricing

When public pricing rises, existing customers stay on their old terms, and that has to be a first-class concept rather than tags and a spreadsheet. Look for explicit price versioning, the ability to lock a subscription to its start-date pricing, and a clean migration path when you decide to move legacy customers forward.

Credits and wallets

AI and agentic products need first-class credit handling: one-off and recurring grants, scheduled refresh, rollover with caps, auto top-up below a threshold, expiration tied to time or usage, and a unified balance across credit types. This is the largest gap in legacy enterprise billing systems, so it deserves a live demo rather than a slide. Prepaid and promotional credits covers the model.

Parent-child accounts

One parent account with sub-accounts beneath it, shared credits, pooled usage, and a roll-up invoice at the top. This becomes necessary the moment a customer expands across departments, which healthy accounts do inside the first year.

Quotes and renewals

Enterprise sales doesn't start at a checkout page. Built-in quoting needs pricing lock-in from quote to subscription, approval workflows for non-standard terms, and automatic sync from an accepted quote to an active subscription.

Five lenses for evaluating vendors

Stability. Migrating between billing platforms is a multi-quarter project, so vendor longevity is a real risk. Check funding, product velocity, and current reviews rather than the case studies on the homepage. An acquisition also counts here, because a roadmap inside a larger company answers to different priorities.

Regulatory posture. Certifications are the floor. The real test is whether they'll share a pen test summary under NDA, sign your DPA without an upsell, and let your security team talk to theirs before you sign.

Your customers' billing experience. Ask to see a real invoice and a live customer portal in the demo. If your customer can't self-serve usage, payments, and seats without filing a ticket, that cost lands on your support team.

Pricing transparency and total cost. Insist on public tiers, model a month-12 invoice against your projected volume, and build a multi-year total that includes implementation fees, connector add-ons, support tier upgrades, and the engineering hours your team will spend filling product gaps.

Data ownership and extensibility. Self-hosting and open source are the strongest forms of data ownership, and the option has value at renewal even if you never exercise it. Check whether your team can write custom pricing or dunning logic without waiting two quarters for a feature request.

Where Flexprice fits

Your VPC. Deployed inside your own virtual private cloud on AWS, Azure, or GCP.
On-prem. Deployed inside your own data centre, in any geography.
Flexprice cloud. Fully managed by Flexprice, for teams that do not want to operate it themselves.

On the evaluation lenses above, here is the specific detail rather than the claim.

Data ownership. The metering, pricing, and invoicing logic is readable on GitHub before you deploy anything. Self-hosting that build is free, and the stack it runs on is PostgreSQL as the system of record, Kafka as the event backbone, ClickHouse as the event store, and Temporal for durable billing workflows, all inside your own environment.

Pricing transparency. Three tiers carry published prices and one is quoted: Basic is free at 100K events a month, Build is $500 a month at 1M events, Scale is $1,000 a month at 5M events, and Mission Critical is custom. Yearly billing takes 20% off the paid plans. Pricing is flat per plan rather than a share of your revenue, with a separate mechanism worth reading closely: each tier carries a cumulative billing revenue cap, $100K on Basic, $250K or $20K monthly on Build, $1.2M or $100K monthly on Scale, and unlimited on Mission Critical. Model where your own volume lands against both the event count and the revenue cap, because they bind independently.

Compliance. Flexprice holds SOC 2 Type II, GDPR, and ISO 27001 as a company. Read the plan detail before you quote it internally: SOC 2 Type 2, SAML SSO and SCIM, multi-role permissions, and managed VPC or on-premise deployment sit on the Mission Critical tier. A SOC 2 report also certifies Flexprice as an operator, so a build you self-host is not covered by it, and your own auditors will treat that deployment as yours. The contractual SLA is 99.9% with 99.99% HA options from Build upward.

The comparison that matters most at this stage is against closed, vendor-hosted platforms. Metronome, Orb, and m3ter are closed source and vendor-hosted. Flexprice is open source and deploys inside your own VPC or on-prem, so usage and revenue data never has to leave your infrastructure.

Read the self-hosting guide if you want to run it against your own contract structures before talking to anyone.

How to calculate customer usage for billing

Flexprice — Mon, 21 Sep 2026 15:21:23 +0000

A customer opens their invoice and asks why it's higher than last month. Answering that question requires tracing a number on a PDF back through pricing rules, entitlement deductions, an aggregation window, and a stream of raw events your product emitted days ago. If any step in that chain is undocumented or non-deterministic, the honest answer is that you don't know.

Usage calculation is the chain that makes that question answerable. It runs from a raw event to a priced line item, and each step changes the number.

How is customer usage calculated for billing?

Usage is calculated by defining a billable unit, cleaning the raw event stream, aggregating events into a quantity per customer per period, applying plan pricing to that quantity, and writing a billable record that shows the quantity, the rate, and the resulting charge. The invoice is assembled from those records.

Seven steps, in order.

1. Define the billable unit

The billable unit is the thing you count. It decides your pricing, your customer's mental model of the product, and how much explaining an invoice needs.

Common units in AI and infrastructure products:

API calls. One request, one unit. Easy to measure and easy to explain.
Tokens. Works for language model products, but only if customers understand what a token is. If they don't, you inherit that explanation in every support thread.
Compute minutes or GPU hours. Reasonable when cost tracks time on hardware.
Unique agents or sessions. Counts distinct things active in a period rather than total volume.

Pick a unit your team can measure precisely and a customer can predict. A unit that's cheap to compute but abstract to the buyer will cost you more in support than it saves in engineering.

2. Pre-process the raw usage data

Products emit logs, traces, and request records, not billing summaries. Before anything is counted, the stream has to be shaped.

Attribute every event. Group by customer, and tag with product, feature, or SKU so pricing can be applied selectively later.

Resolve account hierarchies. If one contract covers several teams or subsidiaries, usage may need to pool to a parent for billing while still reporting separately per child.

Filter what should not be billed. Internal test traffic, sandbox environments, and failed requests usually shouldn't count. Write those rules down, because they'll be questioned during an audit.

Subtract included allowances. A plan that includes 100,000 tokens a month removes those before charging begins, and the allowance usually resets on the billing period.

Normalize units. You may meter in seconds and bill in minutes, or meter per event and bill in blocks of 10,000. Rounding direction is a pricing decision, so make it explicit rather than inheriting whatever the language does.

This step is unglamorous and it's where most silent revenue leakage starts.

3. Aggregate usage

Aggregation converts many events into one quantity. The function you choose has to match how the product delivers value.

Strategy	Produces	Fits
Sum	Total of a property across events	API calls, tokens, compute seconds
Count	Number of events	Requests, jobs run
Count unique	Distinct values of a property	Active users, agents deployed
Latest	Most recent value in the period	Seat count, concurrent sessions
Max	Highest value seen	Peak concurrency
Sum with multiplier	Summed property scaled by a rate	Tokens weighted by model
Weighted sum	Time-proportional total	Capacity held over a period

Defaulting to sum because it's easy will show up later as a pricing model that doesn't match what customers think they're buying. Flexprice exposes these as configuration on a metered feature rather than code, and the aggregation reference covers the behaviour of each one.

The event carries whatever the aggregation needs to read:

{
  "event_name": "model.usage",
  "external_customer_id": "cust_123",
  "properties": {
    "tokens": 1840,
    "model": "gpt-4"
  },
  "event_id": "evt_9f2c1a",
  "timestamp": "2025-08-22T07:05:49.441Z"
}

event_id is optional in the payload and worth setting anyway. It's what lets a retried request resolve to one billable event instead of two.

4. Apply pricing logic

Pricing is not quantity times rate. It's quantity evaluated against the rules attached to that customer's plan.

Plan rules first. Check what plan the customer is on and what it includes before pricing anything.

Tiers. Say the rate is $0.002 for the first million units and $0.001 after that. There are two legitimate ways to read those tiers, and they produce different invoices.

Under slab (also called graduated) pricing, usage is split at the boundary and each slice is priced at its own rate. Under volume pricing, the total lands in one tier and the whole quantity is priced at that tier's rate. For 1.5M units, slab gives $2,500 and volume gives $1,500. Neither is wrong, but picking one by accident is, and this is where hand-rolled billing code tends to disagree with the pricing page.

Flexprice makes this an explicit flag rather than an assumption. A price with billing_model: TIERED carries a tier_mode of either SLAB or VOLUME. The volume tiered doc walks through the volume case, where 65,000 calls priced against a tier ending at 100,000 at $0.0006 bills as 65,000 x $0.0006 = $39 rather than accumulating the cheaper earlier tiers.

Slab is the mode the function below implements:

def price_tiered(quantity, tiers):
    """Slab/graduated: each slice priced at its own rate.
    tiers: list of (up_to, rate); up_to=None means unbounded."""
    total = 0.0
    remaining = quantity
    previous = 0
    for up_to, rate in tiers:
        span = remaining if up_to is None else min(remaining, up_to - previous)
        if span <= 0:
            break
        total += span * rate
        remaining -= span
        previous = up_to if up_to is not None else previous
    return total

price_tiered(1_500_000, [(1_000_000, 0.002), (None, 0.001)])
# 2500.0

Whichever mode you pick, state it on the pricing page in the customer's terms. "You pay $0.001 on everything once you pass a million" and "the first million stays at $0.002" describe different bills.

Minimums and caps. Some contracts carry a monthly minimum or a spend ceiling. Both are applied after usage is priced, and both change the total.

Time splits. If the plan changed mid-period, the period splits and each segment prices at the rate in effect then. Upgrades, downgrades, and price changes all land here.

Currency and tax. Both belong inside the pricing step. Treating them as post-processing on a finished total tends to produce rounding that doesn't reconcile.

5. Generate billable records

A billable record is the row that explains a line on the invoice. It's what you show a customer who disputes a charge.

Each record should carry the customer identifier, the product or feature, the billing period, the billable quantity after entitlements, the rate or rates applied, and the final charge.

{
  "customer_id": "cust_123",
  "feature": "model.usage",
  "period": { "start": "2025-08-01", "end": "2025-08-31" },
  "billable_quantity": 1500000,
  "unit": "tokens",
  "tier_mode": "SLAB",
  "rates": [
    { "up_to": 1000000, "rate": 0.002 },
    { "up_to": null, "rate": 0.001 }
  ],
  "amount": 2500.00
}

If the record can't reproduce the charge on its own, invoicing, collections, and revenue recognition all become brittle downstream.

6. Store and sync the records

Billable records are ledger data, not scratch output.

Keep them in a durable, auditable store that acts as the single source of truth for usage charges. Invoicing reads from it rather than recomputing. Finance systems sync from it so month-end reconciliation is a comparison rather than an investigation. Customer dashboards read from it so a user can trace a charge to their own activity without opening a ticket. Every adjustment, whether a credit, a correction, or a late-arriving event, gets logged so the number is explainable a year later.

Flexprice documents the order in which credits, discounts, and taxes are applied in Invoice Calculation Order, which is the part most often reverse-engineered from an invoice.

7. Backtest and iterate

A billing cycle closing is the start of the feedback loop, not the end of it.

Re-run past usage against a proposed pricing change before shipping it. You'll see where revenue would have moved and which customers would have been surprised. Investigate invoices that spiked, because those usually expose an aggregation edge case rather than a customer behaviour change. Look for events you're emitting but not billing, which is revenue leakage that no alert will tell you about. Then feed usage patterns back to the people making pricing decisions, since high usage and high revenue are frequently not the same customers.

Where Flexprice fits

Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud.

It implements the chain above as configuration: a metered feature defines the event name and aggregation, prices attach to that feature on a plan, wallets and credit grants draw down against the result, and invoices assemble from the billable records. Because it's open source and self-hostable, usage and revenue data can stay entirely inside your own infrastructure and never reach a vendor's cloud.

Run it locally and push a few events through the chain before deciding whether to build it yourself: github.com/flexprice/flexprice.

How to automate subscription billing workflows

Flexprice — Mon, 21 Sep 2026 15:14:51 +0000

Most billing systems start as a cron job that reads a table and creates invoices. That works until usage enters the picture, then credits, then mid-cycle plan changes, then a webhook that silently fails on a Friday and takes two people a day to unwind.

The fix is not a better cron job. It's making billing deterministic: every state change emits an event, every event is idempotent, and every number on an invoice traces back to a stored record rather than a recomputation.

What does automating subscription billing actually mean?

It means every billing event triggers the next step without a person in the loop, across six layers that each do one job. Subscription management holds plan state and renewal schedules. Metering records consumption. Rating converts usage into money. Invoicing assembles and posts documents. Payments collect and retry. Entitlements keep product access matched to what was paid for.

Each layer runs independently and communicates through events. That separation is what lets you change pricing without touching product code, and replay a bad day without hand-editing invoices.

Here are the thirteen steps, in build order.

1. Map the workflow from signup to renewal

Before building anything, draw the path a customer takes and mark every point where money or access changes.

The events that matter: signup, trial start, plan activation, upgrade, downgrade, pause, cancel at period end, renewal at the anchor, usage thresholds crossed, credit grant, top-up, expiry, invoice finalized, payment succeeded, payment failed, refund, credit note.

Then document where each piece of data originates and where it goes. The product and data pipeline produce usage events. The billing service turns usage into rated lines. Invoicing creates posted documents. The payment provider returns success or failure. Tax and accounting receive posted invoices and settlements.

Two policy decisions save arguments later. Pick your billing anchor, calendar or anniversary. And pick a finalization window for late usage, so invoices close after a short grace period and anything later becomes an adjustment next cycle.

Come out of this step with three artifacts: a swimlane diagram of the event flow, an event catalogue with schemas and sample payloads, and a policy sheet covering anchors, proration, late usage, dunning, refunds, and credit notes.

2. Build on an event-driven backbone

Every meaningful subscription change emits a domain event that other services react to. Flexprice publishes this set for subscriptions: subscription.created, subscription.updated, subscription.paused, subscription.resumed, and subscription.cancelled, alongside invoice events such as invoice.create.drafted and invoice.update.finalized, and payment events such as payment.success and payment.failed. The full list is in the webhooks reference.

Whether you consume those or emit your own, each internal event should carry a globally unique idempotency key, event and delivery timestamps in UTC, resource identifiers, and version metadata so consumers know how to parse it. An internal envelope might look like this. It is your own schema, not a provider's payload format:

{
  "event": "subscription.updated",
  "event_id": "evt_01HQ8K3M",
  "version": "2",
  "occurred_at": "2025-10-27T08:14:02.118Z",
  "data": {
    "customer_id": "cust_123",
    "subscription_id": "sub_998",
    "change": "plan_upgrade",
    "effective_at": "2025-10-27T08:14:02.118Z"
  }
}

Internally, publish to a queue or stream so consumers get replay and backpressure. Use webhooks for external systems, but do not make an external webhook the only path for anything that affects revenue. A webhook that silently fails is an invoice that silently doesn't exist.

Every consumer guards against duplicates with an idempotency store keyed on event ID, and handlers are written to be safely reentrant. Store events durably so you can replay a window after an outage, backfill a downstream system, or reconstruct what happened during an incident. When schemas change, version them and support both formats through a migration window rather than breaking consumers.

3. Meter usage into an append-only ledger

Decide what a unit is: API calls, minutes, storage, messages, GPU seconds. Then define the unit name, the conversion to billing currency, rounding and precision rules, and the measurement window.

Every usage record carries a unique event identifier, customer and subscription IDs, the metric name and quantity, an event timestamp and a received timestamp, and any properties you might price or group by later.

Store it append-only. Never overwrite or delete a usage row. Corrections become compensating entries, which is what makes the ledger auditable and what lets you explain a number six months later.

Late and duplicate data are the two failure modes worth designing for explicitly. Late data is handled by the finalization window from step 1: close the invoice when the window passes and push delayed usage into the next cycle as an adjustment. Duplicates are handled by an idempotency constraint on the event ID.

Validate on the way in. Drop impossible values, flag missing identifiers, and alert on ingestion lag and abnormal spikes. Preventing a missing event is cheaper than rebuilding trust after an overcharge. Event ingestion covers the contract and the debugging path.

4. Rate usage against a versioned price book

Pricing should change without a deploy, which means rates live in data rather than constants.

A price book entry holds the metric and unit, the rate per unit or per tier, currency and region, any discounts or commitments, and a version ID with effective dates.

Rating then matches each usage record to the price book version that was in effect at the event's timestamp. Treat rating as a pure function: the same usage and the same price version always produce the same amount. That property is what prevents billing drift after a price change, and it's what makes a disputed invoice reproducible.

Hybrid pricing runs through the same path. A fixed access fee, metered usage, and credit drawdown all become rated lines, so the invoice assembly logic does not need a special case per pricing model. Apply minimums before overages and deduct credits in a defined order, recording each adjustment in the rated ledger rather than computing it inline.

Keep rated results in their own store, separate from raw usage: customer ID, metric, applied rate, price version, and subtotal. Invoices regenerate from that without touching the usage ledger.

5. Automate recurring billing and proration

Each subscription stores its anchor date, renewal type, and next period. That's the trigger for the bill run.

A scheduled bill run finalizes invoices for every subscription reaching its renewal date, pulling fixed charges, rated usage, and credits within the period. It also handles draft generation, tax and currency calculation, posting the finalized invoice, and creating the payment intent.

Mid-cycle changes need a proration policy, and there are two workable options. Immediate proration bills the adjustment right away. Deferred proration reflects it on the next invoice. Deferred tends to produce fewer refund requests on usage-priced products, because the customer sees one number instead of three. Pick one and apply it consistently. Understanding proration covers the mechanics.

Minimums and overages belong inside the bill run, comparing rated totals against the commitment before finalizing rather than correcting afterwards.

6. Add a credit system customers can follow

Decide what a credit represents and keep the definition stable across plans: money, units, or access. One credit might be one API call or one minute of processing.

Track credits like currency, in an append-only ledger. Every grant, spend, and expiry is its own entry carrying the customer and subscription ID, the credit type, quantity, remaining balance, and a reference to the usage event or invoice that caused it.

Automate the lifecycle: top up when the balance drops below a threshold, expire unused credits on a defined schedule, and notify before expiry rather than after. When an invoice is assembled, credits deduct before usage and recurring fees are charged.

Then show the balance. Customers who can see what they have left open fewer tickets and get fewer surprises. Auto top-up and the wallet balance types cover the configuration side.

7. Generate invoices from the rated ledger

Invoices read from the rated ledger. They do not run live queries and they do not recalculate, because a recalculation at invoice time is a second implementation of your pricing logic that will eventually disagree with the first.

For each cycle, assembly fetches fixed charges and add-ons, aggregates rated usage lines in the window, applies credits, discounts, and minimums, then adds tax and totals. Grouping lines by category keeps the document readable during an audit or a customer review.

Once posted, an invoice is immutable. Corrections appear as credit notes or adjustment lines in the next cycle. Editing a posted invoice is how phantom balances appear in accounting.

Store enough metadata to reconcile later: invoice and customer IDs, period start and end, currency, tax region and exchange rate, payment status and reference, and the price book version used. Invoices covers generation, status handling, and payment tracking.

8. Collect payments with a retry ladder

A finalized invoice creates a payment intent. The system attempts the charge, records success or failure as events, and updates the invoice and customer balance.

Payment failures are not an edge case, so the retry schedule is part of the design. A common ladder retries after 24 hours, again after 72 hours, and a final attempt at day 7, with access paused or downgraded if it's still unpaid.

Pair each retry with a message. First failure is a reminder with the retry schedule. Second includes a link to update the payment method. Final attempt warns about the access change. When a retry succeeds, restore access, mark the invoice paid, and confirm, all automatically, so there's no window where a customer has paid and is still blocked.

Store every payment attempt, gateway reference, and status against the invoice ID. Manual reconciliation stops being feasible somewhere in the low hundreds of accounts.

9. Sync entitlements the moment money or plan state changes

Entitlements are what the customer can use: features, usage caps, and credit-backed access. They have to move the instant billing state moves, or product access and billing data drift apart.

Keep entitlements in their own layer rather than inside billing or product code. That layer subscribes to billing events, maintains the current state per customer, and exposes a fast check the product calls in the request path.

The transitions to automate: payment succeeded activates or extends access, payment failed restricts or pauses, upgrade expands immediately, downgrade or cancellation reduces or revokes. Keep a history of every entitlement change with the triggering event, because that's what you'll need when someone asks why a customer lost access on a Tuesday.

10. Automate lifecycle communication

Billing that works silently still generates support tickets if customers can't see what's happening.

Trigger messages on subscription start and renewal, upcoming renewal, invoice issued, payment receipt, payment failure and retry, low or expiring credit balance, plan change confirmation, and trial expiry.

Send through the channel that fits: email for invoices and receipts, in-app for credit and usage warnings, webhooks for enterprise accounts that want to ingest billing events into their own systems. Keep templates versioned and log delivery status so you can answer what a customer actually received. Webhooks covers the outbound event contract.

11. Close the loop with tax, accounting, and audit

Automate tax calculation so every invoice carries the jurisdiction and rate, the customer's tax ID and exemption status, and the evidence used to determine location.

Push every posted invoice and payment to accounting with totals, taxes, status, and recognition schedule. Recognize revenue progressively against the billing period to stay aligned with ASC 606 and IFRS 15.

Keep immutable logs for every invoice, refund, and adjustment, with timestamps and actor. Reconcile against payment providers on a schedule, matching by invoice ID and posting adjustments for mismatches.

12. Monitor and rehearse failure

Automation without observability is a system that fails quietly.

Track event ingestion lag, rating latency, invoice finalization time, payment success and failure rates, and dunning recovery. Alert on every job failure, retry with exponential backoff, and keep dead-letter queues so failed events can be replayed rather than lost.

Then rehearse. Disable a webhook on purpose, inject a duplicate event, and confirm that idempotency and reconciliation behave the way the design says they do. A billing system that has never been tested under failure is a billing system whose failure behaviour is unknown.

13. Run a shadow bill before going live

Generate invoices as if billing were live, without charging anyone. Compare totals, credits, and taxes against what you expect.

Mismatched totals, missing usage, and double-rated events all show up here. Fix them in metering or rating, not by patching invoice data, because patched data means the bug is still there for next cycle.

Run at least one full cycle in shadow mode, confirm the finalization window behaves correctly, and document the flow for the teams who will operate it.

Where Flexprice fits

Building all thirteen steps yourself is a platform project, and the failures usually come from coordination between layers rather than from any single layer's logic. One missing webhook, one duplicate usage event, or one late credit update breaks the chain.

Against the steps above, it provides real-time event ingestion with deduplication, an append-only usage ledger, rating against versioned prices, recurring billing with proration, credit wallets with grants and expiry, invoices generated from rated records, payment retries, and entitlement state the product can query directly. Because it's open source and self-hostable, usage and revenue data can stay entirely inside your own infrastructure and never reach a vendor's cloud.

Clone it and run a shadow cycle against your own event stream: github.com/flexprice/flexprice.

What Is Metered Billing and How Does It Actually Work?

Flexprice — Tue, 15 Sep 2026 08:20:18 +0000

Metered billing and usage-based billing get used as synonyms. They are two layers of the same system, and separating them makes the architecture much easier to reason about.

Metering is measurement. It counts API calls, GPU seconds, or tokens processed. Usage-based billing is the layer above it that turns those numbers into money. Most billing bugs live at the seam between the two, where an aggregation window disagrees with a billing period or a retried request gets counted twice.

Short answer

Metered billing measures actual product usage as discrete events, then a rating layer converts that measured usage into charges. It runs in four stages: event ingestion with idempotency, aggregation into billable metrics, rating against pricing rules, and invoicing.

The four layers

Event ingestion

Every billable action emits an event. An API call, a token generation, a completed workflow. These flow into the metering pipeline through a queue or an ingest endpoint, and each carries an idempotency key so a retry cannot become a second charge.


{

  "event_id": "evt_9f2c41ba7d",

  "event_name": "tokens_processed",

  "external_customer_id": "cust_4812",

  "timestamp": "2026-09-11T14:22:05Z",

  "properties": {

    "model": "gpt-4o",

    "input_tokens": 1840,

    "output_tokens": 612,

    "region": "eu-west-1"

  }

}

Two things make this layer survivable. The event_id is generated by the caller, not the receiver, so the same event submitted twice collapses into one. And the pipeline needs replay and backfill, because a consumer will eventually fall over and has to resume from the last committed offset rather than from now.

The Flexprice event ingestion overview covers the ingest contract, and there is an event debugger for inspecting what actually arrived, which is the question you want answered when an invoice looks wrong.

Aggregation

Raw events are not billable. A billable metric is an aggregation over a window, and the function you choose changes what the customer sees on the invoice.

-**Sum **totals a numeric property. Total tokens processed in a period.

-**Count **counts events. Number of API requests.

-Count unique counts distinct values of a property. Active users, distinct documents touched.

**Max **takes the highest value in the window. Peak concurrent seats.

-Latest takes the most recent recorded value. Current storage allocated.

-Average takes the mean of a property across events.

-Sum with multiplier sums a property and applies one configured rate to the total, which is how a raw count becomes a currency amount.

-Weighted sum is time-proportional, prorating values by how long they were held. This is the one for capacity billing such as reserved storage measured in GB-hours.

The aggregation reference documents each of these. The window matters as much as the function: hourly, daily, and per billing period each produce different numbers from the same event stream, and a mismatch between the aggregation window and the invoice period is one of the most common sources of disputed charges.

Rating

Rating converts aggregated usage into currency. The standard shapes:

-Per unit. A flat rate for every unit consumed. Easy to predict, easy to explain.

-Tiered. The rate changes as consumption crosses thresholds, with each tier priced separately.

-Volume. The whole quantity is priced at the rate the total volume qualifies for, so unit price falls as volume rises.

-Overage. A quota is included, then per-unit charges apply above it.

-Minimum commitment. A floor the customer pays regardless of consumption, with usage charged above it.

Tiered and volume are frequently confused and produce different invoices for the same usage. Under tiered, the first 10,000 units keep their original rate when the customer reaches 50,000. Under volume, all 50,000 reprice at the higher-volume rate. Flexprice documents volume tiered pricing separately for exactly this reason.

Invoicing

Rated usage becomes line items. This stage combines usage charges with subscription fees and one-off charges, applies credits and discounts, handles proration for mid-cycle changes, and calculates tax and currency conversion.

The requirement that gets underestimated is traceability. Every line item should resolve back to the events that produced it, because the first question on a disputed invoice is always "which requests are these". Invoice calculation describes how charges are assembled.

AI-specific metering choices

Tokens, requests, or GPU time?

Three metrics, three tradeoffs.

**Tokens **are precise and map closely to provider cost. They also confuse buyers who have no intuition for how many tokens a conversation consumes, and they punish the user for iterating on a prompt.

Requests are the easiest to understand and the easiest to forecast. They also hide the fact that one request can be a hundred times more expensive to serve than another.

GPU time tracks actual resource consumption, which lines up with cost for training runs and heavy analysis. It is opaque to a customer who only sees a task complete.

The right choice depends on who reads the invoice. Precision that the buyer cannot interpret creates support tickets, and simplicity that ignores cost variance creates margin problems.

Composite metrics

A composite metric multiplies a base count by coefficients that reflect real cost. Requests times a model coefficient times a latency bucket, for example, so a slow query on a larger model costs more than a fast one on a small model.

This is fairer than a flat per-request rate and it is closer to the underlying cost curve. The tradeoff is that every coefficient has to travel with the event, because the aggregation can only use what the event carries, and a coefficient change has to be versioned so historical invoices stay reproducible.

The primitive for this is a custom expression, a CEL formula evaluated per event that computes the quantity to aggregate. input_tokens + output_tokens combines two fields, ceil(duration_ms / 1000) converts and rounds, and gpu_seconds * device_weight applies a coefficient sent as a property. It works with Sum, Average, Max, and Latest. Missing properties evaluate to zero and nested paths are not supported, so flatten anything the formula reads to a top-level property.

What customers need to see

Live usage visibility has moved from a differentiator to an expectation. Customers want current-period consumption, remaining quota, and enough history to predict next month.

Alerts do the rest of the work. A notification at 75% of quota costs nothing and prevents the support conversation that starts with a surprise invoice. Flexprice supports spend alerts at the subscription and line item level.

Prepaid credits and postpaid billing solve the predictability problem from opposite directions. Credits are bought up front and drawn down, with optional auto top-up and rollover, which caps exposure by construction. Postpaid gives full flexibility and defers the number to the end of the cycle, which is where bill shock comes from.

Finance alignment

Raw meters become unit economics when usage per customer is joined against cost to serve. That is what tells you which accounts are profitable and which are subsidised, and it is the number that decides whether a pricing model works.

Inside organisations, two patterns handle internal accountability. Showback gives teams visibility into their consumption and its cost without moving money. Chargeback bills internal teams for what they consume. Both depend on consistent resource tagging and normalised unit costs, which is standard FinOps practice.

Reliability and reconciliation

Design for failure. Queues, retries, and dead-letter queues for events that cannot be processed. A dropped event is unbilled revenue and a duplicated event is an angry customer, so the pipeline needs both directions covered.

Keep usage logs immutable. Once recorded, a usage event should never be altered or deleted. That gives both sides a single source of truth during a dispute, and it is what makes an audit possible.

Let customers export raw usage. A customer who can check the arithmetic themselves stops needing to trust the invoice.

Common failure modes

Silent overages. Usage passes the limit with no warning and the invoice arrives at four times the expected amount. Alerts and spending caps fix this, and they have to exist before the pricing launches, not after the first complaint.

Aggregation mismatches. One meter rolls up in minutes, another in hours, timezones differ between the ingest layer and the billing period. The result is double counting or missed charges. Standardise the window and the timezone across every meter.

Meter drift and duplicate events. Without idempotency keys and deduplication before the pipeline, retries inflate bills. This is the failure that erodes trust fastest, because it is invisible until a customer audits their own logs.

Build or integrate

Four questions decide it.

Scale. Events per second at peak, not average. High volume changes the storage and aggregation architecture completely.

Metric complexity. Counting API calls is straightforward. Combining model type, duration, and latency into a composite metric with versioned coefficients is a system.

Financial alignment. If billing has to reconcile against CRM, ERP, tax, and accounting systems, most of the work is integration rather than metering.

Visibility. Dashboards and exports for both developers and finance are a product in themselves.

The integration pattern splits into four components that can be one stack or separate services: a metering pipeline for ingestion, a rating engine for pricing logic, a billing engine for invoices, and a payment gateway for collection. Keeping them separable is what lets you replace one without replacing all four.

A starting checklist

Choose the value metric. It should represent value to the customer and correlate with your cost. These are not always the same unit, and the customer's version usually wins.

Fix the windows and aggregation functions. Pick them once and apply them consistently across every meter.

Prevent bill shock before launch. Invoice previews, threshold alerts, and either credit wallets or capped plans.

Plan reconciliation up front. Immutable logs, export tooling, and a documented dispute workflow.

Getting started

Ingest is the layer to prove first. The sending events guide covers the payload contract and idempotency handling, and the implementation is on GitHubif you want to read how aggregation and rating are wired together.

What a No-Code Usage-Based Pricing Layer Actually Has to Do

Flexprice — Tue, 15 Sep 2026 07:53:29 +0000

Pricing that depends on API calls, tokens, compute minutes, or storage consumed breaks the assumption every subscription billing system is built on: that a customer's charge is knowable at the start of the period. Once that assumption goes, the billing system has to meter, aggregate, price, apply credits, enforce quotas, and produce an invoice a customer will believe.

Teams usually discover this after the fact, when a product engineer is maintaining a spreadsheet reconciliation and pricing changes need a deploy.

This is what the layer between your product and your payment provider has to do, and how to evaluate whether a given platform actually does it.

Short answer

A no-code usage-based pricing tool meters consumption events, applies pricing rules, tracks credits and entitlements, and generates invoices without billing logic living in application code. The capabilities that matter are real-time metering, a credit wallet with expiry and top-up rules, entitlement enforcement tied to that metering, gateway independence, and configuration that product and finance can change without a deploy.

What is a no-code usage-based pricing tool?

It is a billing infrastructure layer that sits between the product and the payment provider. The application emits usage events. The platform meters them, applies pricing logic, accounts for credits and discounts, and generates an invoice. The payment provider only collects the money.

The no-code part means product and finance configure plans, tiers, entitlements, and experiments through an interface rather than by writing queries or shipping code. The distinction matters more than it sounds, because it decides whether a pricing change takes an afternoon or a sprint.

The six capabilities that decide the choice

Real-time metering that holds under volatile load

AI workloads are not smooth. A customer processes 100 API calls today and 100,000 tomorrow, and the metering path has to absorb that without dropping events or falling behind. Batch-based billing systems that aggregate nightly cannot support mid-cycle usage reporting, quota enforcement, or a dashboard the customer trusts.

What to check: how usage is ingested (API, SDK, stream, warehouse), whether aggregation happens continuously or on a schedule, and which aggregation functions are available. Count, sum, unique count, max, and weighted sum cover most metering patterns. If the platform only counts, complex metrics end up back in your code.

Credit wallets as a primitive, not an add-on

Credits solve a specific problem for AI products: normalising several capabilities with very different unit costs into one number the customer can reason about. Image generation, text summarisation, and data analysis all cost different amounts to serve, and no customer wants three meters.

A real wallet implementation has a ledger per customer recording issuance, consumption, expiry, and every balance change. It supports prepaid, promotional, and subscription-included balances with different priorities, expiry rules per grant, and automatic top-ups when the balance crosses a threshold. Flexprice supports prepaid and promotional balances with per-grant expiry and auto top-up.

Credits bolted on top of subscription logic tend to fail at the edges: mid-cycle grants, partial expiry, and refunds against consumed credits.

Entitlements wired to the meter

Entitlement management is what stops usage rather than what records it. Three kinds are needed. Boolean entitlements are on or off by plan, like SSO or priority support. Metered entitlements track consumption against a quota. Static entitlements define what is included without counting, such as which models or regions are available.

The part that gets missed is enforcement. When a customer hits 100% of quota, the system has to do something specific: continue and bill the overage, block, throttle, or prompt for a top-up. If enforcement lives in application code, every pricing change becomes a product change. Flexprice keeps this in entitlement grants linked to plans.

Hybrid pricing without SKU explosion

Very few companies run pure pay as you go. The common shapes are a base fee with included usage and overages, prepaid credit drawdown, minimum commitments with true-up, and per-seat charges combined with consumption. A platform that models these as separate plan duplicates rather than composable charges will produce a catalogue nobody can maintain after the third experiment.

Check whether billing models like volume tiering, package pricing, and flat fees can coexist on one subscription and whether prices can be overridden per customer without cloning the plan.

Environment isolation

Pricing changes are financial changes, and a mistake is a customer-visible one. Being able to configure and replay pricing in a sandbox before promoting it to production is the difference between an iteration cadence you can sustain and one you avoid.

Gateway and deployment independence

Two forms of lock-in matter here. The first is payment gateway coupling: if the billing layer only settles through one processor, you inherit that processor's fees, regional coverage, and roadmap. The second is data location: whether usage and revenue records have to sit in a vendor's cloud.

How the landscape splits

The tools in this category are solving related but different problems, and the useful way to read them is by which problem they lead with.

Metering-first infrastructure. Flexprice and Lago both sit in this group, and both are open source and self-hostable. The difference is enterprise scale: Flexprice is built for real-time metering at high event volume, with deployment across any VPC and any geography.

Merchant of record platforms. Polar handles global tax compliance by acting as the seller, which removes VAT and GST work for teams selling internationally. Transaction pricing at 4% plus $0.40 with no monthly fee is straightforward, and the tradeoff is depth: card payments through Stripe Connect only, and no hierarchical billing or contract management for enterprise workflows.

Metering inside a payments company. Metronome is now part of Stripe. The metering itself is strong and proven on large AI and infrastructure workloads. The consideration is scope: the billing layer and the payment layer are now the same vendor, so payment strategy and billing strategy stop being separable decisions.

Order to cash platforms. Zenskar extends past billing into revenue recognition, collections, and financial reporting, with contract ingestion and ASC 606 support built in. That suits finance-led enterprises with complex sales contracts. It is sales-led with no self-serve entry, so evaluation starts with a demo rather than an integration.

Compared with Chargebee, Recurly, and Maxio, which are subscription management software built for plan-based and per-seat billing, hosted only, Flexprice is metering-first infrastructure built for usage-based and hybrid pricing. Compared with Stripe Billing, which is built around subscriptions and payments and is usually paired with a separate metering vendor for usage-based products, Flexprice is the metering and billing layer itself, and is not tied to any payment gateway.

How to evaluate one for your case

Start from pricing complexity, not feature lists. Subscription with usage overages is a solved problem and most platforms handle it. Credits, multi-tier usage, and entitlement enforcement narrow the field quickly. Enterprise commits with minimums and custom terms narrow it again.

Price the lock-in explicitly. Ask whether the platform forces a payment provider, whether usage data and billing history can be exported in full, and what happens to your roadmap if the vendor is acquired. Open source answers the first two by construction.

Match the tool to who will operate it. A platform that needs SQL to define a billable metric will route every pricing question through engineering, whatever the marketing says. If finance and product are meant to own pricing, verify they can define a metric and launch a plan without a ticket.

Count how often pricing will change. AI products adjust pricing as models and costs move, sometimes several times a year. That cadence is the real requirement, and it is the one that decides whether a platform is workable in eighteen months.

Check the compliance gap. Metering-only tools leave ASC 606 and IFRS 15 revenue recognition to you or to your accounting system. That is fine if the integration exists and unpleasant if it does not.

Why this shift happened

63% of SaaS companies now use or are actively testing usage-based pricing, up from 45% in 2021. The drivers are structural rather than fashionable.

AI workloads are non-linear, so seat counts stopped correlating with cost or value. Product-led motions need a single billing path that carries a user from free trial through team usage to an enterprise contract without a migration. Finance teams need consumption and margin visible during the month rather than after it. And engineering teams that built billing in-house discovered the maintenance cost compounds, which is why several well-known companies later replaced their internal systems with dedicated ones.

Getting started

The fastest way to evaluate a metering layer is to send it real events and see what the invoice looks like. The event ingestion overview covers the ingestion path, and the MCP server exposes the same operations to an editor if you would rather drive the setup from there. The source is on GitHub.