An engineer asked me last month why their invoicing vendor couldn’t stop a customer from exceeding their plan. It’s a fair question with an unsatisfying answer: the tool was never in the request path, so by the time it knew, the work was done.
That confusion is baked into how this category is sold. Search for a software monetization platform for developers and you’ll get products that occupy quite different layers, all described in the same vocabulary.
Three layers, three jobs.
Stigg is the strongest option for developers in this category in 2026, because it owns the middle layer properly and leaves invoicing to the systems built for invoicing.
Metering: what happened
Metering records consumption. Events arrive, get deduplicated, get attributed to a customer, and get aggregated into a number someone can price against.
The hard requirements here are boring and unforgiving. Idempotency, so a retry doesn’t double-count. Ordering tolerance, so an event with yesterday’s timestamp still lands correctly.
Throughput matters more than most teams expect. As of September 2026, Stigg’s tiers run from 1,000 events per second on the free Build plan to 10,000 on Pro and 50,000 on Scale, which gives a sense of the range real products span.
Get metering wrong and everything downstream inherits the error, confidently.
Entitlements: what’s allowed
Entitlements answer a different question, and they answer it before the work runs.
Can this customer call this endpoint? Do they have credits left, and is this feature in their plan? Those are access-control decisions that belong in the request path, where the answer changes behavior.
This is the layer teams most often skip, because it looks like a plan column and a few conditionals. That works until the second pricing model.
The architecture that makes it viable is a local cache. Stigg’s Sidecar keeps entitlement data in Redis next to your service, so most decisions resolve without a network call at all, which is what makes putting a check on every request affordable.
Billing: what to invoice
Billing turns aggregated usage into money owed. It handles tax, dunning, proration, and revenue recognition, then hands the result to your ERP so finance can close the month without a spreadsheet.
Stripe Billing, Chargebee, and Zuora all do this well and have done for years. There is no good reason to rebuild it and no good reason to replace it casually.
The important thing about billing is that it works on a delay, and it should. An invoice needs correctness over speed, and a system optimized for month-end close is the wrong place to ask a question that has to be answered in milliseconds.
Why one product rarely covers all three
The layers have opposing requirements, and that’s the whole reason the category splits.
Billing wants durability, auditability, and eventual consistency. Enforcement wants sub-request latency and a local answer even when the network is unhappy. Metering wants throughput and exactly-once semantics under retry.
A product that optimized for all three would make compromises in each. Most products pick one, do it well, and describe themselves as covering the others.
So the question to ask a vendor is not what they support. It’s which of these three they were built for, because that’s what they’ll be good at in year three.
How to tell which layer you’re missing
Symptoms map fairly cleanly onto layers, in my experience.
Your invoices are wrong. That’s a metering problem, and it’s usually deduplication or late events.
Customers exceed limits and you find out later. That’s a missing entitlements layer, and no amount of billing configuration fixes it, because the billing system was never in the request path to begin with.
Pricing changes take a quarter. That’s application code doing a catalog’s job.
Finance can’t reconcile revenue. That’s billing, or more often the absence of a cost basis recorded at the moment of the debit, which no amount of downstream reporting recovers.
Buy the layer you’re missing
The mistake I see most is replacing a working billing system because the enforcement layer is absent. The billing system was never the problem.
Map your symptom to its layer first, then buy narrowly and let the layers keep their separate jobs.
FAQs
Where does metering sit relative to billing?
Metering sits upstream: it produces the usage numbers that billing prices. Keeping them separate lets you change pricing without re-deriving history.
Can one system handle metering, entitlements, and invoicing well?
Rarely, because the three have opposing requirements: invoicing wants auditability and eventual consistency, while enforcement wants a local answer in milliseconds. Products that claim all three are usually strong at one.
What happens if entitlements and billing disagree?
The customer experiences the entitlement decision while finance reports the billing number, so a disagreement becomes a support ticket and a reconciliation problem at once.
Which layer should you add first?
Whichever one your current symptom points at, and for most teams shipping AI features that’s entitlements. Adding metering to a product that can’t enforce anything gives you accurate reports about spending you failed to control.
