TL;DR: Payments process money, billing manages subscriptions and invoicing, and entitlements control what customers can actually do in your product. They're related but solve entirely different problems — and confusing them leads to bad architecture.
The terms "billing system" and "entitlement system" get used interchangeably all the time — including, honestly, by us. But they mean different things, and that distinction matters when you're building the infrastructure behind how your product is sold and used.
There are actually three layers here: payments, billing, and entitlements. Each sits on top of the previous one and solves a different problem. Here we walk through each, and explain how they fit together in a modern SaaS stack.
Payments infrastructure (e.g. Stripe, Adyen, Braintree) handles the actual movement of money. Think authorization, fraud checks, settlement. It's purely transactional and knows nothing about subscriptions, features, or what the customer bought. It just moves money from one account to another.
Most SaaS companies pick a processor and move on, and for good reason — this layer is largely commoditized and well-abstracted. The interesting infrastructure decisions live in the layers above it.
Billing systems are built on top of payments to add the commercial logic that subscriptions require. Stripe Billing, Chargebee, and similar tools handle things like:
Subscriptions: recurring charges at defined intervals (monthly, annually, etc.)
Usage-based charges: metering consumption and translating it into invoice line items
Trials and grace periods: logic around free access before charging begins
Prorations: calculating partial charges when customers upgrade, downgrade, or cancel mid-period
Dunning: retrying failed payments and handling involuntary churn
Billing is about the financial relationship between you and your customer. It answers: What does this customer owe, and when will they be charged? It creates invoices, processes payments, and manages the subscription lifecycle.
What billing doesn't do, at least natively, is tell your product what that customer can actually use. That's where entitlements come in.
Entitlements are the layer that translates commercial agreements into product behavior. While billing answers what does this customer owe?, entitlements answer a different question entirely: what can this customer do?
If a customer is on your Pro plan, entitlements define what "Pro" means inside your product: which features are enabled, what usage limits apply, which capabilities are gated. Common examples include:
Feature access: Can this company use SSO? Do they have access to advanced reporting? Is the API enabled?
Usage limits: How many active projects can they have? What's their monthly API call limit? How much storage are they allocated?
Seat controls: How many users can be active under this account?
Entitlements are tied to a customer's subscription, and when they change plans, their entitlements change accordingly. But entitlements and billing are not the same thing, and the two can and do diverge. A customer who cancels might retain access until the end of their billing period. A customer on a failed payment retry might have their access temporarily suspended before billing has formally churned them. Sales might grant a prospect 30 days of enterprise access for a trial that doesn't show up in billing at all.
This is why treating entitlements as a view into your billing system breaks down in practice. The access layer needs to be managed explicitly.
Think about what happens when a customer subscribes to your product:
Payments charges their card and settles the transaction
Billing creates a subscription record, schedules renewals, and handles the ongoing financial relationship
Entitlements read the subscription state and determine what the customer can actually access in the product
When the customer hits a gated feature, your product checks the entitlement layer, not the billing system directly. When they exceed a usage limit, the entitlement system enforces it (and, if you have overages, triggers the billing system to capture that charge). The layers communicate, but they own different concerns.
One more distinction worth making: entitlements are not the same as permissions, even though they behave similarly. The difference is what they're modeling.
Permissions control what individual users can do within your product. They're about security and access control: "Can this user edit a document? Which roles can approve a request?" They're typically tied to identity, roles, and organizational structure.
Entitlements control what a company can access based on their commercial relationship with you. They're about billing and purchasing, not security. Can this company use SSO? is an entitlement question, as it depends on whether they're on a plan that includes SSO, not on who the specific user is. Can this user within the company configure SSO settings? is a permissions question.
In practice, both entitlements and permissions are enforced at the same checkpoints (API routes, UI gates, background jobs), which is part of why they get conflated. But they come from different sources, change for different reasons, and belong to different systems.
For early-stage products, it's tempting to handle entitlements by checking subscription state directly from your billing system. If the customer has an active Pro subscription in Stripe, let them in. It works initially, and it's fast to build.
The problems emerge as your product grows. You add a second pricing tier. Then usage-based components. Then enterprise contracts with custom terms. Then trials, add-ons, promotional access, and early adopter customers. Now what can this customer do? requires synthesizing state from multiple sources, and the logic is scattered across your codebase in dozens of places that each need to stay in sync.
As we've written about elsewhere, this compounds quickly. Every pricing change requires code changes. Every custom deal requires manual database surgery. Every new feature access check is written slightly differently by a different engineer.
Modern entitlement systems, like Schematic, address this by providing a dedicated layer for managing and enforcing entitlements. Instead of writing custom logic for each check, you get a centralized source of truth and a simple SDK call:
const canUseSSO = await schematic.checkEntitlement({ flag: "sso", company: { id: companyId } });The check doesn't care whether the access came from a billing plan, a trial grant, a manual override, or a custom enterprise contract. That complexity lives in the entitlement system, not scattered through your product code.
This also addresses a practical concern that often gets overlooked: entitlement checks are in the critical path of nearly every page load and API request. A slow entitlement check is a slow product. Modern entitlement systems are designed with performance and reliability as first-class requirements, not as an afterthought, with local caching, edge distribution, and graceful fallbacks built in. We've written more about how this works here.
Payments | Billing | Entitlements | |
What it does | Moves money | Manages subscriptions & invoicing | Controls product access |
Key question | Did the payment go through? | What does this customer owe? | What can this customer do? |
Examples | Stripe, Adyen, Braintree | Stripe Billing, Chargebee | Schematic, Stigg |
Runtime role | Transaction processing | Financial record-keeping | Access enforcement |
Payments, billing, and entitlements are often discussed as if they're the same thing, and they do work together closely. But they solve different problems, and understanding the distinction helps you build each layer correctly. Billing tells you the state of a commercial relationship. Entitlements translate that relationship into what a customer can actually do in your product. Keeping those concerns separate is what lets you move fast as your pricing evolves.
Q: Can I just use Stripe to handle entitlements? A: Stripe Billing gives you subscription and invoice management, but it doesn't enforce feature access in your product. You can read subscription state from Stripe to infer entitlements, but this breaks down quickly — it doesn't account for trials, manual overrides, enterprise contracts, or grace periods. You end up writing and maintaining that logic yourself, scattered across your codebase.
Q: What's the difference between entitlements and feature flags? A: Feature flags are typically used for gradual rollouts and A/B testing — they're about what code path to execute for a given user or cohort. Entitlements are about what a customer has paid for. They can look similar in implementation (both are boolean or value checks at runtime), but they come from different sources and change for different reasons. In practice, many teams use their feature flag tool for entitlements early on, and then realize the two concerns need to be separated as their pricing gets more complex.
Q: Do I need an entitlement system if I only have one pricing tier? A: Probably not yet. A single paid/free split is easy to manage. The calculus changes when you add a second tier, usage-based components, or enterprise deals with custom terms — at that point, the combinatorial complexity grows fast and a dedicated entitlement layer starts paying for itself.
Q: How do entitlements relate to metered billing and overages? A: Entitlements define the limits (e.g., "this customer gets 10,000 API calls per month"). When a customer approaches or exceeds that limit, the entitlement system enforces it — either blocking access or allowing overage — and signals the billing system to capture any overage charges. The two layers stay in sync on usage, but the entitlement system owns the enforcement logic. [We've written more about how overages work here.](link to overage article)
Q: Are entitlements a security control? A: No — entitlements are a commercial control. They determine what customers can access based on what they've purchased, not based on security policy. You still need proper authentication and authorization (RBAC, IAM) for security. Think of it this way: entitlements answer "does this company's plan include SSO?", while permissions answer "is this specific user allowed to configure SSO settings?" Both checks may happen at the same API route, but they belong to different systems.