Minimum commitment

Concepts

What a minimum commitment guarantees

A minimum commitment says: over this window, the customer pays at least $X, whatever they actually use. If usage clears the commitment on its own, the customer just pays for usage. If it doesn’t, the shortfall gets charged.

The commitment window can outlast the billing period

A commitment’s own window doesn’t have to match the line item’s billing cadence. A common shape: a half-year commitment billed monthly.

$60,000 per half-year, invoiced monthly: $10,000 monthly share

Jan       Feb       Mar       Apr       May       Jun
$10K      $10K      $10K      $10K      $10K      $10K

Once the window outlasts a single invoice, no single invoice can tell on its own whether the commitment will be met. Each period, Zenskar has to decide: charge a shortfall now, or wait and see. The evaluation mode answers that, with two options: greedy and cumulative. If the commitment window and the billing period are the same length, there’s nothing to decide, since every period is both the start and the end of its own window, and the two modes behave identically.

Both modes land on the same total

Over the full window, the customer pays the same total either way: the higher of total usage or the full commitment. Neither mode ever collects more than that. If an earlier invoice charged a shortfall and later usage catches up, a later invoice credits it back. Greedy and cumulative differ only in when a shortfall is charged, never in how much is owed by the end. Each period is tested on its own against its share of the commitment. Fall short, and the gap is charged on that invoice immediately, regardless of how strong an earlier period was. Two things keep this from overcharging: a later strong period credits back an earlier top-up, and a period’s share is capped at whatever is still unpaid on the total commitment. Once the full commitment has been billed, every remaining period is usage only. Example.

60,000 per half-year, invoiced monthly, so a

10,000 share per month. Usage: 14K, 7K, 5K, 22K, 12K, 3K.

January:  usage 14K, share 10K   → billed 14K (above share, no gap)
February: usage 7K,  share 10K   → billed 10K (3K gap charged now)
March:    usage 5K,  share 10K   → billed 10K (5K gap charged now)
April:    usage 22K, share 10K   → billed 14K (8K credited back: Feb + Mar top-ups)
May:      usage 12K, share 10K   → billed 12K (60K now fully billed)
June:     usage 3K,  share 10K   → billed 3K  (commitment already met, usage only)

Total usage: 63K. Total billed: 63K.

January’s strong month didn’t help February or March; each paid its own gap. April’s surplus gave those two top-ups back. By the end of May the full

60,000 had been billed, so June's 3K goes through with no top-up even though it's far below the

10,000 share.

Cumulative: the running total has to stay on pace

Cumulative draws a straight-line pace across the window:

10,000 by the end of January,

20,000 by the end of February, and so on. Each period compares the running total billed so far against that pace. On or ahead of pace, bill usage only. Behind, charge just enough to close the gap. A strong period banks a surplus that can cover a later weak one. This is the default evaluation mode. Example. Same commitment, same usage: 14K, 7K, 5K, 22K, 12K, 3K.

January:  usage 14K → billed 14K   (running 14K vs pace 10K, ahead 4K)
February: usage 7K  → billed 7K    (running 21K vs pace 20K, ahead 1K)
March:    usage 5K  → billed 9K    (running 26K vs pace 30K, 4K charged to catch up)
April:    usage 22K → billed 18K   (running 48K vs pace 40K, 4K credited back)
May:      usage 12K → billed 12K   (running 60K vs pace 50K, ahead)
June:     usage 3K  → billed 3K    (running 63K vs pace 60K, ahead)

Total usage: 63K. Total billed: 63K.

January and February’s surplus covered March, the first period the running total actually fell behind pace. April’s surplus gives that catch-up charge back, and the customer stays ahead of pace for the rest of the window.

Greedy vs. cumulative, side by side

Month	Usage	Greedy billed	Cumulative billed
Jan	14,000	14,000	14,000
Feb	7,000	10,000 (+3K)	7,000
Mar	5,000	10,000 (+5K)	9,000 (+4K)
Apr	22,000	14,000 (-8K credit)	18,000 (-4K credit)
May	12,000	12,000	12,000
Jun	3,000	3,000	3,000
Total	63,000	63,000	63,000

The two modes only diverge when a strong period comes before a weak one. Greedy reacts to every weak period immediately and settles up later; cumulative waits until the running total actually falls behind before charging anything. A weak period followed by a strong one produces identical invoices under either mode.

How this differs from the previous commitment behavior

Before this evaluation-mode model, a commitment’s window was always the same length as the billing period: a monthly commitment on a monthly invoice, checked fresh each time with no memory of prior periods. A strong period could never offset a later weak one, and nothing was ever credited back, so total payments over a stretch of time could run higher than the commitment itself. Put the same usage (14K, 7K, 5K, 22K, 12K, 3K) on a

10,000 monthly commitment under that older behavior, and the customer pays 14K + 10K + 10K + 22K + 12K + 10K =

78,000. The same deal reshaped as a

60,000 half-year commitment under either greedy or cumulative comes to

63,000, since both modes always settle at the higher of total usage or the full commitment across the whole window.

How-to guides

How to set a minimum commitment’s evaluation mode

On the line item, open the minimum commitment.
Set the commitment’s amount or quantity and its window, for example $60,000 per half-year.
Open Advanced and choose an evaluation mode: Cumulative (the default, tracks the running total against a pace line across the window) or Greedy (each period must independently hit its own share).
Set Partial period handling to prorate or full, if the commitment’s window starts or ends partway through a period. This is a separate control from evaluation mode.
Save.

The commitment’s own cadence and the line item’s billing cadence must tile evenly: one has to be a whole multiple of the other. See reference below for the full field list.

Reference