The contract says 2,500 reports. The product stops at 1,000.
July 10, 2026
Sales closes a Growth contract with a simple exception: this customer gets 2,500 AI reports a month instead of the standard 1,000.
The proposal says 2,500. The invoice reflects the negotiated price. But two weeks later, the product stops the customer at report 1,001.
Nothing is wrong with the contract or the payment. The promise simply never reached the product.
A sale creates a promise, not just an invoice
When a customer buys a plan, they are not buying its name. They are buying what that plan lets them do: use SSO, create three workspaces, generate a number of reports, or continue past a limit at an agreed rate.
Those promises are entitlements.
An entitlement is the current answer to: what has this customer paid for and what should they receive now?
That answer must remain consistent across the proposal, product, invoice, and support conversation. If each team keeps its own version, the customer eventually finds the disagreement for you.
The contract must appear the same everywhere
In our example, the entitlement record says:
- AI reports are available;
- 2,500 reports are included each month;
- additional reports cost the negotiated rate;
- SSO is available;
- up to three workspaces are available.
The plan is still Growth. The customer’s promise is more specific than the plan.
The standard plan is only the starting point
Pricing pages make businesses look tidy. Real customers are not.
One customer negotiates more usage. Another buys an add-on. A third keeps an older price after you update the catalog. A fourth receives temporary access while a contract amendment is signed.
These are not edge cases to hide in notes. They are normal commercial decisions, and each one changes what the customer should experience.
| Commercial decision | What must stay true |
|---|---|
| Larger included amount | The product must not stop at the standard plan limit |
| Add-on purchased | The feature appears without moving the customer to another plan |
| Temporary access | The feature ends on the agreed date |
| Grandfathered contract | New catalog changes do not rewrite the old agreement |
An entitlement gives each decision one home. Without it, exceptions become Slack messages, CRM notes, support macros, and conditions buried in code.
The promise changes over time
Entitlements are not a permanent label attached to a customer. They have a history.
Suppose the same customer upgrades halfway through the month. Today they have 2,500 reports and three workspaces. After the upgrade, they receive 5,000 reports and ten workspaces. The new promise starts on the effective date; it should not rewrite what they had last month.
That history matters when someone asks:
- Why was this report allowed on June 18?
- Which limit applied when the invoice was created?
- Was SSO part of the original agreement or added later?
- Did the customer exceed 1,000 or 2,500 reports?
If the only answer is “this is what the plan says today,” you have lost the agreement that produced yesterday’s invoice.
A denied action is a commercial statement
When the product says “you cannot use this feature,” it is making a claim about the customer’s contract.
That claim needs more care than a normal feature flag. A stale flag causes a bug. A stale entitlement can deny something the customer paid for—or give away something they did not.
The same is true at a limit. Stopping the 1,001st report is not merely a product behavior. It says the customer’s included amount has ended. If their signed agreement says 2,500, the product is wrong even if the standard Growth plan says 1,000.
The invoice and product need the same answer
The worst version of this problem is inconsistency: the product allows 2,500 reports, but billing charges overage after 1,000. Or billing recognizes the exception, but support sees only the public plan.
In Tirdad, the plan supplies the standard promise and customer-level changes refine it. The product, usage meter, and invoice resolve the same entitlement record. When the agreement changes, the effective date preserves what applied before and what applies now.
An entitlement is not a feature gate. It is the product’s copy of the promise your company made to the customer.
Want to design a feature and package it into plans? That practical work belongs in From feature to priced entitlement.
Next in this series: A mid-month upgrade. What should you charge?
Eight connected decisions—from the first usage event to recurring revenue.
Set the rule once. Tirdad applies it every time.
Keep the policy, effective date, customer agreement, and invoice calculation in one billing system instead of rebuilding the decision in every product surface.