Skip to main content
Scope: PIT and POT, all quantity strategies.

​
The six configuration decisions

#QuestionPhase 1 statusNotes
1How many discounted units?Availablee.g., 1,000 discounted API calls
2How often are they refreshed?AvailableMonthly, daily, quarterly
3What happens to unused units?Not availableAlways use-it-or-lose-it in Phase 1
4When do you pay for overages?AvailablePrepaid or postpaid
5When do discounted units become available?Not availableFollows the line item’s lifecycle; no independent start/end date
6Total lifetime cap?Availablee.g., max 1,000 discounted units ever

​
Configuration fields

FieldDescriptionRequiredDefault
valueDiscounted units per cadence cycleYes—
cadenceRefresh frequency (P1M, P1D, P3M, etc.)NoNone (per-period)
max_per_periodCap on discounted units within a cadence windowNoUnlimited
max_lifetimeCumulative cap on discounted units ever consumedNoUnlimited
prorate_stubReduce pool for partial cadence windowsNofalse
roundingRounding for prorated pool (floor/ceil/half_up)No—
labelDisplay label on invoiceNo—
orderExecution order when stacking multiple discountsNo—

​
Core calculation

  1. Pool created — fresh pool of value discounted units at each cadence boundary.
  2. Deplete chronologically — periods within the cadence window consume from the pool in order.
  3. Bill the remainder — usage beyond the pool is billable.
Resolution formula: discounted_units = min(value, remaining_pool, max_per_period_remaining, remaining_lifetime).

​
Cadence behavior

RelationshipExampleBehavior
Cadence = billing periodMonthly cadence, monthly billEach billing period gets its own pool
Cadence > billing periodQuarterly cadence, monthly billSingle pool shared across months; depletes chronologically
Cadence < billing periodDaily cadence, monthly billEach day gets its own pool; month-end is the sum of daily overages
No cadence (cadence=None)—Functionally the same as cadence = billing period: each billing period gets value discounted units, but prorate_stub doesn’t apply

​
Proration

ScenarioProration?
Contract starts or ends mid-windowYes, if prorate_stub=true
prorate_stub=false (default)No — full pool for partial windows
Full cadence windowNo — full pool
cadence=NoneNot applicable — no cadence window to prorate
pool = value × (window_days / full_cadence_days)
1,000 discounted/month, contract starts Jan 15 (17 of 31 days):
Prorated pool = 1,000 × (17/31) = 548.39
Rounding548.39 →Use case
floor548Favors the business
ceil549Favors the customer
half_up548Standard rounding
For POT, pricing proration operates on the dollar amount for a partial period, while discount proration (prorate_stub) operates on the quantity pool — these are different axes and aren’t expected to interact. (Open question: needs eng confirmation.)

​
Lifetime caps

Caps total discounted units ever consumed, not pool size. Unused or wasted units don’t count toward the cap. 
100 discounted/month, max 1,000 ever
Month 1:  500 calls. Discounted: 100. Lifetime: 100.
Month 2:  80 calls.  Discounted: 80.  Lifetime: 180. (20 unused ≠ counted)
...
Month 10: 150 calls. Discounted: 100. Lifetime: 980.
Month 11: 200 calls. Discounted: 20 (only 20 left). Lifetime: 1,000.
Month 12+: All billable.
MechanismAxisControls
Cadence resetTimeWhen the pool refreshes
max_lifetimeConsumptionTotal discounted units ever
These are orthogonal and can be combined.

​
Discount stacking

Multiple discounts coexist via the order field. Quantity discounts reduce units first; dollar and percent discounts apply to the resulting amount afterward. 
50 discounted (order=1) + 20% off (order=2), 200 calls @ $0.01
Step 1: 200 − 50 = 150 billable units
Step 2: 150 × $0.01 = $1.50
Step 3: $1.50 × 80% = $1.20

​
Interaction with pricing models

ModelQuantity discount applicable?Notes
Per-unit (linear)YesStraightforward — discount reduces units, remainder priced at flat rate
Volume (non-linear)YesDiscounted units can shift which bracket the customer lands in, sometimes raising the total
Tiered (non-linear)YesFewer units fill fewer tiers; total is always less than or equal to without the discount
PackageYesFewer units means fewer packages
Flat feeNoFixed amount regardless of quantity
PercentNoBased on monetary input, not units
StepYesFewer units means fewer steps triggered

​
Invoice presentation

API Calls (Jan 1–31, 2026)
  Usage:              3,500 calls
  Quantity Discount:  −1,000 calls (First 1,000 discounted)
  Billable:           2,500 calls
  Rate:               $0.001/call
  Amount:             $2.50
With a lifetime cap shown: 
API Calls (Nov 1–30, 2026)
  Usage:              200 calls
  Quantity Discount:  −20 calls (20 of 1,000 lifetime remaining)
  Billable:           180 calls
  Rate:               $0.001/call
  Amount:             $0.18
  Lifetime discounted: 1,000 / 1,000 (exhausted)
Each period produces a breakdown record with: quantity before and after discount, discount applied, pool before and after, lifetime used, and whether any cap was hit.

​
Risks and edge cases

ScenarioHandling
Cadence > billing period = budget depletion”500/quarter” depletes across 3 months, not 500/month
Discount orderQuantity discounts reduce units first, then dollar discounts apply

​
Glossary

TermDefinition
Quantity discountDiscounted units that offset billable consumption or allocation
PoolDiscounted units available within a cadence window; depletes chronologically
CadenceRefresh frequency for the pool (daily, monthly, quarterly)
Cadence windowTime span covered by one pool instance
max_per_periodCap on discounted units within a single cadence window
max_lifetimeCumulative cap on discounted units ever consumed
Prorate stubProportional pool reduction for partial cadence windows
Discount stackingMultiple discounts on one product, ordered by the order field
BreakdownPer-period audit record: pool state, discount applied, cap status

​
Out of scope / deferred

FeatureDescription
Carryoverpercentage, all, fixed strategies with max_balance caps
Expiry modelsend_of_grant_period, end_of_billing_period, end_of_contract, custom
Grant timingon_purchase/on_payment triggers; delay for trials
Per-event scopescope="per_event" — “5 discounted per purchase”
max_per_eventPer-event cap (requires event-level data)
Prepaid entitlementsGrant records, dashboard balance, real-time tracking
Batch-based expiryIndependent batches with FIFO consumption
Faucet-and-bucketSeparate grant cadence from expiry boundary
Cross-product discountsShared pool across multiple products

​
Open questions

#QuestionStatus
1Does the discount need an independent validity period, or does it always follow the line item’s lifecycle?Needs clarification
2Is cadence=None meant to be identical to cadence = billing period, or a distinct one-time discount concept?Needs clarification
3For POT amendments mid-period, is the full discount value applied independently to each segment?Needs eng validation
4Does POT need a time-limited discount concept (e.g., “50 discounted seats for 6 months, then full price”)?Needs clarification
5Can it be confirmed that POT pricing proration (dollar amount) and discount proration (pool quantity) never interact?Needs eng validation
(Placeholder: status of open questions should be confirmed before this doc is published externally.)