# Entitlement Management for SaaS: How to Gate Features by Plan > Entitlement management explained for SaaS - what entitlements are, how they map plans to feature access, common architecture patterns, and how to keep billing and access in sync. - **Author**: Ayush Agarwal - **Published**: 2026-07-10 - **Category**: Billing, SaaS - **URL**: https://dodopayments.com/blogs/entitlement-management-saas --- Entitlement management is how a SaaS product decides what each customer is allowed to use. It is the layer that translates a plan the customer paid for into concrete access: which features unlock, how many seats they get, how many API calls they can make, and when those limits reset. Get it right and billing and product stay perfectly aligned. Get it wrong and you either give away product for free or charge for things customers cannot reach. Most teams start with entitlements hardcoded as `if plan == 'pro'` checks scattered through the codebase. That works until you add a second plan, a custom enterprise deal, a usage limit, or a promotional bundle. Then the checks multiply, drift out of sync with billing, and become the source of subtle revenue leaks that are hard to trace. This post explains what entitlements are, how they connect billing to feature access, the architecture patterns that scale, and how to keep entitlements and billing in sync as your plans grow. It is written for founders and engineers building the access layer of a SaaS product. ## What an Entitlement Actually Is An entitlement is a record that says a specific customer is allowed to do a specific thing, usually because of the plan they are on. It is the answer to the question "can this customer use this feature right now?" Entitlements come in a few shapes. A boolean entitlement is on or off: the customer either has access to the analytics dashboard or does not. A quantity entitlement is a number: five team seats, three projects, ten thousand API calls. A metered entitlement tracks consumption against a limit that resets on a cycle, which is the foundation of [usage-based billing](https://dodopayments.com/billing/usage-based-billing). The key idea is that entitlements are data, not code. Instead of hardcoding "pro users get advanced reports," you store an entitlement that grants the advanced-reports capability, and your product reads that entitlement at runtime. This separation is what lets you change plans without redeploying and lets billing changes flow to access automatically. ## Why Hardcoded Plan Checks Break The naive approach is to check the plan name directly in your product code. It looks clean at first and fails predictably as you grow. When you scatter `if plan == 'pro'` throughout your codebase, every new plan means touching every check. A custom enterprise deal that grants one pro feature but not another has no clean representation, so you invent special cases. A limited-time bundle that gives free users one premium feature forces yet another exception. Over time nobody can answer "what exactly does the Growth plan include?" without grepping the code. Worse, these checks drift from billing. Sales closes a deal with a custom limit, but the code only knows named plans, so the customer either gets too much or opens a support ticket because they got too little. Every drift is a revenue leak or a support burden. The fix is to stop encoding access as plan names and start encoding it as entitlements that billing controls. ## The Entitlement Architecture Pattern A scalable entitlement system separates three concerns: what plans grant, what a customer is entitled to, and what your product checks at runtime. ```mermaid flowchart LR A[Plan / Subscription] -->|grants| B[Entitlements] B -->|read by| C[Product Access Check] D[Usage Events] -->|counted against| B C -->|allow or deny| E[Feature / API Response] ``` The flow works like this. A plan or subscription grants a set of entitlements when the customer subscribes. Those entitlements are stored as data attached to the customer. Your product, whenever it needs to gate a feature, asks the entitlement layer "is this customer entitled to X?" rather than checking the plan name. For metered entitlements, usage events decrement a counter against the entitlement's limit. This pattern means adding a plan is a data change, not a code change. A custom enterprise deal is just a custom set of entitlements. A bundle is an extra entitlement grant. The product code never changes because it only ever asks about capabilities, never about plans. ## Keeping Entitlements in Sync With Billing The hardest part of entitlement management is not the initial grant. It is keeping entitlements accurate as subscriptions change. Upgrades, downgrades, cancellations, failed payments, and plan migrations all need to update entitlements in real time. When a customer upgrades, their new entitlements should apply immediately, often with [proration](https://dodopayments.com/blogs/subscription-upgrade-downgrade-proration) on the billing side. When they downgrade, access to the removed features should revoke at the right moment, usually at the end of the paid period rather than instantly. When a payment fails and the subscription lapses, entitlements should downgrade to the free tier, not vanish entirely, so the customer can recover. The clean way to handle this is event-driven. Your billing system emits an event on every subscription change, and your entitlement layer updates in response. This is exactly what [webhooks](https://docs.dodopayments.com/developer-resources/webhooks/intents/webhook-events-guide) are for: a subscription-updated event triggers an entitlement recalculation. When billing and entitlements are wired together this way, they cannot drift, because every billing change automatically propagates to access. ## Entitlements and Usage-Based Billing Metered entitlements are where entitlement management and billing become inseparable. If you charge per API call, per credit, or per unit of consumption, the entitlement is the limit and the usage counter is what you bill against. This is the model behind [credit-based billing](https://dodopayments.com/billing/credit-based-billing), where a customer buys a balance of credits that deducts as they consume. The entitlement is the credit balance, the usage events are the deductions, and billing tops up or charges overages when the balance runs low. Companies like the ones we analyze in our breakdown of the [OpenAI billing model](https://dodopayments.com/blogs/openai-billing-model) run exactly this pattern at scale: prepaid credits as entitlements, token usage as the meter. Getting this right requires the entitlement layer and the metering layer to share state. When a customer hits their limit, the product must know instantly to either block, throttle, or trigger an overage charge. That real-time link is what separates a clean usage product from one that overspends its own margin. ## Building It Yourself vs Using a Platform You can build entitlement management yourself. Many teams do, and for a single simple plan it is straightforward. The cost shows up as your plan catalog and pricing complexity grow. A homegrown system means you own the plan-to-entitlement mapping, the sync logic on every subscription change, the metering counters, and the real-time access checks. Each of these is a place where billing and access can drift. As you add usage tiers, enterprise deals, and bundles, this becomes a meaningful engineering surface to maintain. A billing platform that includes entitlements handles the mapping and sync for you. Dodo Payments ties [subscriptions](https://dodopayments.com/billing/subscriptions), usage metering, and entitlements together, so a plan change automatically updates what the customer can access, and usage counts against the right limits without you building the plumbing. The developer [integration guide](https://docs.dodopayments.com/developer-resources/integration-guide) shows how to read entitlements in your product, and [agent skills](https://docs.dodopayments.com/developer-resources/agent-skills) include patterns for credit-based and usage-based setups. ## FAQ ### What is entitlement management in SaaS? Entitlement management is the layer that decides what each customer is allowed to use based on the plan they paid for. It translates a subscription into concrete access: which features unlock, how many seats or projects are allowed, and what usage limits apply. It is what keeps billing and product access aligned. ### Why not just check the plan name in code? Hardcoded plan checks like `if plan == 'pro'` break as you add plans, custom deals, and bundles, because every new case means touching every check. They also drift from billing, so a custom limit sold by sales does not match what the code enforces. Storing entitlements as data avoids both problems. ### How do you keep entitlements in sync with billing? Use an event-driven approach where your billing system emits an event on every subscription change, and your entitlement layer updates in response. A subscription-updated webhook triggers an entitlement recalculation, so upgrades, downgrades, and lapses automatically propagate to access without manual work. ### What is the difference between entitlements and usage-based billing? Entitlements define what a customer is allowed to use, while usage-based billing charges for what they actually consume. For metered products the two merge: the entitlement is the limit, and the usage counter is what you bill against. They must share state so the product knows instantly when a customer hits a limit. ### Should I build entitlement management myself or use a platform? Building it yourself is fine for a single simple plan but becomes a growing engineering burden as you add usage tiers, enterprise deals, and bundles, each a place where billing and access can drift. A billing platform that includes entitlements handles the plan-to-access mapping and keeps it synced automatically. ## Conclusion Entitlement management is the access layer that turns a paid plan into concrete product permissions. Done as data rather than hardcoded plan checks, it lets you add plans and custom deals without touching product code, and keeps billing and access from drifting apart. The two hard parts are keeping entitlements synced with every subscription change and linking metered entitlements to real-time usage. Solve both with an event-driven design, or use a billing platform that ties subscriptions, usage, and entitlements together so the sync is automatic. Either way, the payoff is a product where what customers can do always matches what they paid for. --- - [More Billing articles](https://dodopayments.com/blogs/category/billing) - [All articles](https://dodopayments.com/blogs)