What are Entitlements? How feature access works in modern billing

An entitlement is a customer's right to access a specific feature or product within a given plan. That sounds simple until you try to change a plan, grandfather an existing customer, launch in a new market, or offer a free trial of a premium feature. At that point, the gap between "we hardcoded the plan check" and "we have a proper entitlement system" becomes very expensive to close.

Most SaaS companies start with the hardcoded approach, which tends to break later on.

How Entitlements Work

A customer's entitlement state is the intersection of several inputs:

1. Plan level: which tier the customer is on (starter, growth, enterprise, etc.)

2. Payment terms: monthly vs. annual, though this rarely changes the feature set

3. Feature set: which specific features are included in that plan

4. Entitlement limits: caps on usage within a feature (e.g., up to 5 users, up to 1,000 API calls per month)

5. Geographic variations: features available in some markets but not others

6. Entitlement variations: service-level differences within a feature (basic support vs. dedicated account manager)

In the early days, a single conditional handles most of this:

if plan == 'gold' then show_feature() else do_nothing()

if plan == 'gold' then show_feature() else do_nothing()

if plan == 'gold' then show_feature() else do_nothing()

It works. Then someone wants to remove a feature from the basic plan. Or add a regional restriction. Or let a churned customer retain access for 30 days. Or grandfather three accounts who were on an old plan that no longer exists. The conditional becomes a tangle, the tangle gets copied across the codebase, and now changing anything requires a deployment.

Why splitting entitlements from billing makes sense logically

Your billing system answers one question: has this customer paid, and for what? Your entitlement system answers a different question: given everything we know about this customer, what should they be able to do right now?

They overlap, but they're not the same. A customer can be delinquent on payment and still need temporary access. A customer can be on a paid plan and still be blocked from a feature due to geography. A trial customer can have access to a premium feature you're testing with a specific cohort. None of these states fit cleanly into a billing record.

If you find yourself in any of these situations, you need a separate entitlement subsystem:

• You want to change what features are included in a plan without forcing existing customers onto a new plan

• Some features are optional add-ons, not plan-level inclusions

• You're expanding to new geographies where feature availability differs

• You want to trial features for specific customers without changing their billing relationship

• You need to grandfather customers into a plan state that new customers can't select

The last one is the clearest signal. Grandfathered plans that can't be selected are a maintenance nightmare in any codebase that doesn't separate entitlement logic from plan logic.

What an entitlement system knows

A well-designed entitlement service can answer questions that a billing system can't:

• For a specific user on a specific plan, what are their feature limits?

• For a specific user, what features should they have regardless of plan (overrides)?

• For a user on a plan in a specific country, which features are available and which upgrades are possible?

• Is this customer in a trial phase or an evergreen phase?

• For a grandfathered account on a discontinued plan in a specific market, what exactly are they entitled to?

The entitlement service becomes the single source of truth for access decisions. Applications stop querying the billing system to decide what to show. They query the entitlement service, which has already resolved the billing state, the plan, the geography, and any overrides into a clean answer.

Entitlements in the AI era

AI products have pushed entitlement complexity further than traditional SaaS ever did. A customer using an AI platform isn't just accessing a feature. They're consuming compute in real time, often in ways that vary by model, context window, or output type. Entitlements here aren't binary (can/can't access). They're metered, tiered, and sometimes dynamic.

An AI agent that runs autonomously across sessions creates questions a plan-level check can't answer: Is this agent authorized to take this action? Has the customer's token budget for this task been exhausted? Does this agent have access to the premium model or only the standard one? These are entitlement questions. They need a system that can resolve them in milliseconds at the point of consumption, not at billing time.

The separation between billing and entitlements is even more critical for usage-based pricing models, where the billing event and the access event can be separated by hours or billing cycles. You need the entitlement layer to enforce access in real time, independently of when the invoice is generated.

Entitlement system design: Key considerations

Overrides deserve specific attention. The ability to grant a customer access to a feature outside their plan (for a trial, a retention gesture, or a support resolution) without touching their billing record or plan definition is one of the most operationally useful things an entitlement system provides. Without it, the workaround is either a manual code change or an awkward plan migration. Solvimon's entitlements support this natively.

Scheduled changes are equally important. If you know a feature is going live for a specific market on a specific date, you want to set that in the entitlement system ahead of time, not deploy a code change at midnight. This is what replaces feature flag tools for many teams: the entitlement system handles the timing logic, the application just asks whether the feature is on.

Common Challenges

Hardcoded plan checks spread silently. The first check feels harmless. By the time you have 40 of them scattered across frontend, backend, and API layers, changing a plan definition requires a cross-team audit. The fix isn't glamorous: it requires centralizing the logic before it spreads further.

Grandfathered plans become undocumented. A customer retained on an old plan that no longer exists in the product catalog is a support ticket waiting to happen. The sales team doesn't know about it. The billing team isn't sure what to charge at renewal. The entitlement system should be the record of what that customer actually has, not a note in a CRM.

Trial-to-paid transitions need careful state management. A customer whose trial expires should lose access to premium features. But when exactly? At the moment of expiry? After a grace period? Only for features they didn't use? These transitions are entitlement state changes, and if they're handled ad hoc in application code, they'll be inconsistent. Some customers will keep access too long; others will lose it before they've had a chance to convert.

Downtime defaults matter more than most teams plan for. If your entitlement service goes down, applications need a fallback. Defaulting to "deny all" protects against unauthorized access but also locks out paying customers. Defaulting to "allow all" keeps the product running but opens access to features customers haven't paid for. The right default depends on the feature and the customer's current state, which means the fallback logic needs to be deliberate, not an afterthought.

FAQ

Q: What's the difference between an entitlement and a feature flag?

Feature flags control whether a feature is deployed and visible. Entitlements control whether a specific customer can access it based on their commercial relationship. A feature can be flagged on globally but entitlement-restricted to paid plans. In practice, many teams use feature flag tools for entitlement decisions early on. It works until the commercial logic gets complex. See PLG billing for how this plays out in product-led growth contexts where free-tier enforcement is critical.

Q: Should the entitlement system be built in-house or bought?

Depends on complexity. If your pricing has three clean tiers and no geographic variations, a billing platform with plan-level feature flags is probably enough. Once you have add-ons, grandfathered plans, per-customer overrides, or market-specific feature availability, the business logic is specific enough that either a purpose-built entitlement service or a very configurable platform becomes worth the investment.

Q: How do entitlements interact with usage-based billing?

In usage-based pricing, the entitlement layer enforces access in real time (is this customer allowed to make this API call?) while the billing layer aggregates consumption for invoicing. They run on different clocks. A customer can be within their entitlement at the time of access and then see those events aggregated into a bill at the end of the month. The two systems need to share a consistent view of the customer's state, but they don't need to be the same system.

Q: What's the right fallback when the entitlement service is unavailable?

It depends on the risk profile of the feature. For features that could cause irreversible actions (a customer making changes they can't undo), a conservative deny-access fallback is safer. For read-only or informational features, allowing cached entitlement state is usually fine. The key is making the fallback explicit and tested, not discovering it for the first time during an outage.

Q: How do entitlements handle customers mid-billing cycle?

Entitlement changes (upgrades, downgrades, plan modifications) should take effect at a defined point: immediately, at the next billing cycle, or at a scheduled date. Your entitlement system should support all three, and your billing system needs to know which rule applied so proration is calculated correctly. When these two systems aren't in sync on the effective date, you get customers with access they haven't paid for or customers paying for access they don't have.