Some allocations need a ceiling. A business unit should not be charged more than its budget for a shared service; a sales rep should not carry more overhead than a set limit. These limits are called receiver caps. They sound simple, but a common way of applying them produces numbers that look right, reconcile to the ledger, and are still wrong.
The example
A pool of 418,000 is shared across three sales reps in proportion to salary:
| Rep | Salary | Cap |
|---|---|---|
| R-101 | 145,000 | 145,000 (its salary) |
| R-102 | 118,000 | 145,000 |
| R-103 | 97,000 | none |
| Total | 360,000 |
Step 1: allocate as if there were no caps
Each rep gets 418,000 × salary / 360,000:
| Rep | Uncapped share |
|---|---|
| R-101 | 168,361.11 |
| R-102 | 137,011.11 |
| R-103 | 112,627.78 |
R-101 is over its cap by 23,361.11.
Step 2: clamp and redistribute the overflow
R-101 is clamped at 145,000. Its overflow of 23,361.11 goes to the receivers that still have room, in the same proportion as before, 118 : 97:
| Rep | Before | Overflow received | After pass 1 |
|---|---|---|---|
| R-101 | 168,361.11 | 145,000.00 | |
| R-102 | 137,011.11 | 12,821.45 | 149,832.56 |
| R-103 | 112,627.78 | 10,539.66 | 123,167.44 |
This is where many implementations stop. Look at R-102: it is now at 149,832.56, over its own cap of 145,000. The total still reconciles to 418,000, so nothing flags the problem.
Step 3: keep going until every cap holds
R-102 is clamped at 145,000 and its overflow of 4,832.56 goes to the only receiver with room left, R-103:
| Rep | Settled |
|---|---|
| R-101 | 145,000.00 |
| R-102 | 145,000.00 |
| R-103 | 128,000.00 |
| Total | 418,000.00 |
Every cap holds, and every cent of the pool is allocated.
Why this matters
The clamp-once answer overcharges R-102 by 4,832.56 and undercharges R-103 by the same amount. Both answers reconcile. Only one of them respects the rules the business set. Errors like this are hard to find in a spreadsheet, because the totals are correct.
Two design rules avoid it:
- Cascade until stable. Apply caps, redistribute the overflow, and repeat until no receiver is over its cap. If every receiver is capped and money is left over, send the remainder to a named overflow pool rather than losing it.
- Converge first, then cap. When an allocation also has services that feed back into each other, solve that first and apply the caps to the settled result. Capping inside each pass can stop the calculation from converging at all.
A test worth having
Because clamp-once still reconciles, a reconciliation check will not catch it. A worked example like this one, with its settled figures written down, makes a good regression test: if R-102 ever comes out at 149,832.56, the cap logic has changed.