Almost every binary plan document we are sent describes capping in a single line. Something like: "Daily capping of Rs 10,000 per member." It reads as though it settles the question. It does not, and the gap between that sentence and working software is where most binary platforms develop their first serious bug.
What the pairing actually calculates
In a binary plan each member has a left leg and a right leg. Income is paid on matched business volume — the weaker leg drives the payout, and the stronger leg is carried forward to the next cycle.
So if a member's left leg accumulates 12,000 BV and the right leg accumulates 20,000 BV:
- Matched volume is 12,000
- Payout is calculated on that 12,000
- The left leg resets to zero
- The right leg carries 8,000 forward
That much is uncontroversial. The questions start immediately afterwards.
The four questions the one-liner does not answer
Does capping apply before or after the match? If a member matches 30,000 BV against a daily cap of 10,000, do you pay on 10,000 and carry 20,000 of matched volume forward, or do you pay on 10,000 and discard the rest? These produce very different lifetime payouts, and members notice within a week.
Does the carry-forward survive a flush? Many plans flush unmatched volume at the end of a cycle or when a member goes inactive. If your weaker leg was capped rather than fully paid, is the unpaid remainder flushed with everything else, or protected?
What resets, and when? A "daily" cap needs a day boundary. Midnight in which timezone? Does a member who joins at 11:50pm get a full first day? If your payout run executes at 2am, which day does it attribute volume to?
Does capping scale with rank? Most plans raise the cap as members advance. That means the cap applied to a historical payout is the cap that was in force at the time, not today's. If you recalculate a past cycle with current caps, your figures will not reconcile with what members were actually paid.
A capping rule is not a number. It is a number, a boundary, a precedence order and a decision about what happens to the remainder.
Why this bites later rather than sooner
None of this surfaces during a demo. With fifty test members and a shallow tree, capping rarely triggers and carry-forward balances stay small. The plan looks correct.
It surfaces at scale, on a real payout day, when a few hundred members hit the cap simultaneously and the carried-forward balances start compounding differently from what the plan document implied. By then money has moved. You are not fixing a bug; you are deciding whether to claw back payments from members who have already seen the number in their wallet.
What the software has to do
Three things, and the third is the one most platforms skip.
Store the rule, not just the result. Every payout row should record the cap that applied, the matched volume before capping, the amount paid and the amount carried. A wallet credit of Rs 10,000 with no context is unauditable six months later.
Make the boundary explicit. Cycle boundaries belong in configuration with a stated timezone, not implied by whenever a cron job happens to run.
Reconcile against expected figures before launch. Build a test network that deliberately triggers every branch — members under the cap, at the cap, far over it, going inactive mid-cycle, advancing rank mid-cycle — and check the output against figures you calculated independently. If the two disagree, you want to find out in a staging environment rather than from a member on WhatsApp.
The practical takeaway
When you write your plan document, write the capping rule as a worked example rather than a sentence. Take a member with specific left and right volumes, apply your cap, and state exactly what they are paid and what remains. One worked example resolves more ambiguity than a page of description, and it gives whoever builds your platform something concrete to test against.
If you already have a platform running, the check is simple: pick a member who hit their cap last cycle, and ask your software to show you the matched volume, the cap applied, the amount paid and the carried balance. If it cannot show you all four, you do not have an audit trail — you have a number.