When discussing an allocation arrangement, people often start with percentages: how much each person gets, and who gets more or less. Once the percentages are agreed, tables, rules and systems follow.
But there is a more basic question: Which amount is this percentage multiplied by?
“Calculated at 20%” might mean 20% of transaction value for the period, 20% of a particular revenue amount, or 20% of an already allocated budget. The results may differ substantially.
I would define the calculation basis first. Otherwise business staff, finance and developers may be working with different meanings from the outset.
1. Every percentage needs its own base
The following numbers were written solely for teaching. They represent no real enterprise, project or benefit arrangement. The percentages illustrate arithmetic; they are not allocation recommendations.
Assume eligible business value for a collaboration reward has been confirmed at B = 1000 yuan for the period.
The amount has been checked against this example's scope and reporting period, excluding ineligible, cancelled and refunded items. It is only a calculation base. It establishes neither profit of 1000 yuan nor 1000 yuan available for allocation.
Now suppose the proposed rule sets the period's incentive pool, P, at 20% of B.
Incentive pool P = Calculation base B × Pool rate r
Here: 1000 × 20% = 200 yuan.
Three collaboration categories receive 50%, 30% and 20% of the pool. These percentages apply to the 200-yuan pool.
| Category | Share of pool | Calculation | Amount |
|---|---|---|---|
| A | 50% | 200×50% | 100 yuan |
| B | 30% | 200×30% | 60 yuan |
| C | 20% | 200×20% | 40 yuan |
| Total | 100% | 100+60+40 | 200 yuan |
Applying those pool percentages to the original 1000 instead would produce 500, 300 and 200, totaling 1000 yuan.
Each multiplication is correct, but uses the wrong base. An intended pool of 200 has become 1000: an excess of 800 yuan.
Checking that percentages sum to 100% is insufficient. First check what each percentage multiplies.
All amounts, rates and categories in Figure 1 are fictional teaching inputs. The diagram shows calculation relationships; funding sources, available budget and payment conditions require separate confirmation.
2. Two descriptions can be equivalent if conversion is explicit
The example can also say A receives 10% of B, B receives 6%, and C receives 4%, because:
- 20%×50%=10%;
- 20%×30%=6%;
- 20%×20%=4%.
Applied directly to B, these still produce 100, 60 and 40, totaling 200 yuan.
Either base-relative or pool-relative percentages can form a clear rule. Avoid one meaning in the heading, another in the table, and a third base in the formula.
Putting 10%, 6% and 4% under “share of incentive pool” would make readers apply them to 200, producing only 40 yuan in total.
Use explicit headers: “Percentage of eligible business value for this period” or “Percentage of this period's incentive pool”. Formula fields, configuration tables and interface prompts must use that same definition.
Saving a few words can leave a system requiring repeated explanation.
3. A result of 200 does not supply its funding
B×20% is a calculation result. The formula neither secures payment funds nor approves a budget.
Separately establish the source, funds permitted for this arrangement, confirming authority and outstanding conditions.
For this example, assume the organization has confirmed an available budget of 200 yuan for the reward and the corresponding payment conditions are met. The calculated 200 then matches the assumed budget and payment arrangements.
If only 180 is available while the calculation remains 200, a gap requires action.
The system should show the gap and return it to the appropriate person. Whether to reduce the pool, supplement the budget or change the period's arrangement depends on existing authority and agreements. The system must not silently change rates or assume next period will provide the missing money.
Calculation base, proposed pool, available budget and actual payment are distinct. Keeping them separate reveals where the problem occurs.
4. Align time: occurrence, confirmation and payment
A business event may occur without yet qualifying for this period's calculation. Confirmation of an amount does not necessarily permit immediate payment.
If business occurs this month but agreed checks finish next month, which period applies? Does a later refund affect the original or next period? How are amounts already paid handled? The rules need answers.
I would retain at least three dates:
| Date | Question | Record retained |
|---|---|---|
| Business occurrence | When did the event occur? | Original record and unique event ID |
| Calculation confirmation | Under what conditions and in which period is it included? | Applicable rule version, confirmation basis and calculation period |
| Actual payment | When and under what conditions was it paid? | Payment status, amount and corresponding record |
These let subsequent checks trace the same event.
Suppose 200 of the original 1000 is refunded before confirmation. Under this example's rule it is excluded: B becomes 800, P becomes 160, and 50%/30%/20% allocations become 80, 48 and 32 yuan.
This demonstrates recalculation under a specified condition.
A refund after confirmation, or after payment, cannot automatically use the same treatment. Locate the original event, calculation record and applicable rule; review whether and how to adjust under the agreement. Retain reasons and adjustment differences rather than deleting the original record and obscuring what happened.
5. Give business, finance and development one definition
Before a rule enters a system, everyone needs an intelligible definition.
Business owners explain eligibility. Finance or the appropriate owner checks sources, budget and amount definitions. Developers implement confirmed fields, formulas and statuses. Confirmation and approval powers must match the organization's responsibilities.
The definition can be short, but these points must be identifiable:
| Item | Minimum definition |
|---|---|
| Sources and scope | Funding sources, eligible business, participants and explicit exclusions |
| Base B | Meaning, units, period, entry conditions, and effects of refunds/cancellations |
| Pool P | Rate or formation method, budget limits and authority boundaries |
| Pool shares | Each percentage's base; full allocation or a permitted retained balance |
| Confirmation and payment | Separate conditions for entry, confirmation and payment |
| Exceptions | Duplicate records, refunds, reversals, over-allocation and rounding differences |
| Rule version | Confirming role, effective date, applicability, change notices and records |
Pool percentages totaling less than 100% are not necessarily an error.
If rules permit a reserve, define its purpose, custody and later treatment. If they require full allocation, reconcile the allocated total to the pool.
Show any balance. Do not assume unallocated money belongs to someone automatically or increase allocations arbitrarily to reach 100%.
6. Test normal and exceptional cases
A coherent written rule still needs testing with actual inputs.
The following use the same teaching example. Each test has its own input conditions; they are not assumed to occur together.
| Test | Inputs/scenario | Expected result |
|---|---|---|
| Normal | B=1000; pool rate 20%; pool shares 50%,30%,20% | P=200; allocations 100,60,40; total 200 |
| Wrong base | Pool shares mistakenly applied to B | 500,300,200; total 1000; flag an 800 excess, do not pass as normal |
| Over-allocation | Same 200 pool; shares 50%,40%,20% | 100,80,40; total 220; show excess 20 and return for checking |
| Budget shortfall | P=200, available budget 180 | Show gap 20; hold execution of the original arrangement and refer to an authorized owner |
| Pre-confirmation refund | Original B=1000; 200 must be excluded under this rule | B=800; P=160; allocations 80,48,32; retain linked refund evidence |
| Duplicate | Same eligible business event submitted again | Identify the event; prevent duplicate base inclusion/payment; record handling |
| Reversal/later adjustment | Result confirmed before a refund or cancellation arrives | Locate original event/rule; review adjustment under the agreement; retain original and adjustment records |
Rounding is easily overlooked.
A 0.03-yuan pool allocated 50%,30%,20% produces 0.015,0.009,0.006. Rounding each separately to two decimal places gives 0.02,0.01,0.01, totaling 0.04 yuan.
Define precision, rounding order and residual treatment in advance so details reconcile to totals. The applicable rule determines the method; do not put the difference into an arbitrary category at the last moment.
Testing exposes unclear definitions and easily missed conditions before implementation.
Figure 2 is a proposed working process developed for this article. Correct calculation, available budget, approval authority and payment conditions require separate checks.
7. Trace the result back to its inputs
After calculating forward, work backward. Which pool produced this amount? Which base formed that pool? Which business records formed the base? Which rule version applies? Are current-period conditions met? Do budget and payment records correspond?
The trail should reach specific data and confirmation evidence.
When views differ, locate the level of disagreement: scope, base, pool shares, period, refund status or rule version. Concrete fields and records reveal whom to ask and what to check next.
Closing
Rules can be concise, but every percentage needs an explicit base and every amount a clear source.
Work through normal, exceptional and adjustment cases with a small set of numbers before implementation. That gives later roles, business and rules a checkable foundation.
The confidence in an arrangement comes from these details: clear calculations, traceable records and a known way to correct problems.