Definition
Commission (commission) refers to the sales commission or rebate earned by Reseller channel partners for selling SIM cards, data packages, value-added services, etc. Commission, together with Reconciliation and Multi-Tier Channel systems, forms the core settlement mechanism of the ICMP channel ecosystem, incentivizing channel expansion and sales conversion.
Types of Commission
Common types of Commission include: Sales Commission — calculated based on card activations, data package sales, and data-plan subscriptions; Usage Commission — rebate based on a percentage of the customer's actual usage (e.g., data consumption); Tiered Commission — commission rate increases as sales or usage reach different tiers; First Order Commission — an extra reward for a new customer's first order. In Multi-Tier Channel, primary, secondary, and tertiary channels can have different commission rates, forming layered incentives.
Settlement Process
Commission settlement is usually done on a monthly or quarterly basis: the platform calculates the commission due to each channel based on sales and usage data; reconciles with Reconciliation to ensure sales and usage data are accurate; generates commission reports, and after verification, pays the channels through Payment Gateway or offline payment. In cross-border scenarios, Multi-Currency Settlement must be supported, settling in the channel's location currency or an agreed currency.
Implementation in ICMP
SimtoLink ICMP supports Commission rule configuration: set commission rates by product, region, and channel level; supports tiered, capped, and guaranteed strategies; linked with Reseller management and Partner Portal, channels can self-query commission details. The platform records commission calculation and distribution in Audit Trail, meeting financial auditing and compliance requirements.
The sales and usage facts a commission accrual depends on
Commission is not a standalone reward. It is a share calculated from a sale or a usage fact that has already been established. Sales commission depends on the order and the enablement result: if the SIM is not enabled, there is no sale to accrue against. Usage commission depends on usage that has already been posted, not on counters the device reported itself. Tiered commission depends on the cumulative value inside the measurement period. The three facts come from different places. One “performance number” cannot serve as the base for all three.
An accrual also has to state which channel tier is paid, in which currency, and under which version of the rules. If the rate changes in the middle of a period, orders already placed use the version in force then, and only new orders use the new version. Keeping only the current rate rewrites historical months when they are recalculated. The detail a partner sees in the channel portal should point back to an order number or a usage record, not only to a total.
When a tier and a cap can be calculated together
A tier and a cap can stack, but the calculation order has to be written down first. A common order is: decide whether the base is enabled count or settled usage, find the rate from the tier, apply the cap, and only then convert currency. Reverse that order and the cap applies to the wrong currency, or the tier uses the converted amount to cross a band. For multi-level channels, also state whether each level’s base is the downstream sales amount or the commission the downstream level has already received. The two bases produce completely different results, and the choice cannot be made at settlement time.
A floor needs conditions too: whether it applies to one channel level, one product, or every product. If that is not written, loss-making products and profitable products are topped up together to the floor, and the channel has no reason to tell them apart. When this is configured with a multi-tier channel, an upstream rate should not count again, in its own base, the part a downstream level has already accrued, unless the contract explicitly says the calculation is repeated. The settlement period should line up with the reconciliation period. Usage not yet reconciled stays an estimate, and becomes payable commission only after reconciliation is complete.
Accruing the original order after a return or a stop following activation
If the customer returns goods after enablement, the SIM is terminated, or the order is cancelled, and the system still accrues from the original enablement event, commission is paid on a sale that no longer exists. The same rule should state the reversal conditions: a full return reverses all of it, usage that has already occurred reverses only the part that did not occur, and the reversal is kept as its own record. Stopping commission in later months, and not touching months already paid, leaves that revenue share on the books.
Another error is accruing on orders placed rather than on SIMs enabled. Cancelled orders and duplicate submissions both generate commission. If usage commission is paid early on estimated traffic, and a month-end detail-record correction has no difference adjustment, channel income and platform cost drift apart. Across currencies, accruing at one rate and paying at another, without recording both points in time, leaves a difference that cannot be explained. A return should find the original accrual and create a negative adjustment, not delete the original record. What the partner sees in the portal should be three columns: accrued, reversed, and payable. An estimate must not look like an amount that can already be withdrawn.
The accrual order for a multi-level channel should be drawn as one chain in the rules, not as each level taking the full sales amount on its own. After a downstream level has accrued on enabled count, an upstream level that accrues the full amount again on the same enabled count splits the same SIM twice. If the contract really requires the upstream level to accrue on the gross amount, say that this is a parallel base, and split it into two columns on the report, so finance does not add the columns and pay once more. On reversal, generate the matching negative at every level of the original chain. Do not reverse only the lowest level and leave the upstream amount already paid. Once estimates and payable amounts are separate, the withdraw button in the portal should open only against the payable balance.