Entitlement

An entitlement is the bridge between the commercial agreement and the running software. The contract says “Enterprise plan, 500 seats, SSO, 10M API calls”; the entitlement is what makes the application actually enforce that.

Entitlements come in three shapes:

• Boolean — the feature is on or off. SSO, audit logs, custom domains.
• Quantitative — a numeric limit. Seats, projects, storage, API calls.
• Tiered — a level of a feature rather than its presence. Standard versus priority support.

The drift problem

The commonest failure in B2B SaaS is not that entitlements are missing — it is that they drift from the contract. A customer downgrades and keeps enterprise features because nobody flipped the flag. A customer upgrades and does not get what they paid for until they raise a ticket. A sales rep grants a feature manually during a trial and it is never revoked.

Each instance is small; in aggregate they are a persistent revenue leak on one side and a support burden on the other. Companies that discover a meaningful share of their base is using features they do not pay for usually discover it years in.

Derive entitlements, do not maintain them

The structural fix is that entitlements should be derived from the subscription rather than maintained alongside it. When the plan is the source of truth and the application reads entitlements from it, a downgrade takes effect because the subscription changed — not because someone remembered to change a second system.

That requires the billing platform to expose entitlements to the application at runtime, which is why entitlement APIs and tenant provisioning sit next to each other in most B2B SaaS architectures.