Definition
Traffic billing is the financial accounting capability. It supports plan billing (monthly, quarterly, and annual packs), overage billing, and data pool billing. It produces a bill by card, project, customer, agent, and time, and it reconciles with the carrier, which is what finance closes on. It complements settlement profit sharing, which distributes income.
Billing Mode
- Data plan billing: Prepaid monthly, quarterly, annual packages, costs generated according to data plan cycle.
- Overage billing: After the data plan is used up, billing is based on actual usage, see Overage Billing for details.
- Data pool billing: Total usage within the data pool is billed and then allocated to each card according to rules.
Bills and reconciliation
Traffic billing produces a bill by card, project, customer, agent, and time. That bill is what finance uses, and it is what the platform reconciles with the carrier. It complements settlement profit sharing (income distribution): traffic billing works out cost and revenue, and settlement profit sharing pays that revenue out to the channel. The platform needs more than one billing mode so different businesses can be configured.
Billing Engine and Data Flow
The traffic billing engine usually takes card usage from the carrier or from a usage collector the platform runs itself. It then prices that usage with the data plan, the plan cycle, and the overage billing rules. The plan fee is a fixed charge for the cycle. The overage fee is the amount past the allowance, multiplied by the unit price. In a data pool, the engine first totals usage in the pool, then splits it to each card by an even share, by actual usage, or by weight. The result is written to the bill for carrier reconciliation, customer collection, and settlement profit sharing. If the amount is wrong, the enterprise’s cost and profit figures are wrong with it.
Billing and Data Plan Cycle
Traffic billing generates charges according to the data plan cycle ; monthly packages follow the natural month or 30 days, quarterly packages follow 90 days, and annual packages follow 365 days. The billing cycle is linked to the activation date or the data-plan subscription date. The platform must support billing aggregation by agent , customer, project, etc., for use in profit settlement , billing , and e-invoice . The billing engine must align with carrier mapping and data plan packaging configurations to ensure that during carrier reconciliation , data is traceable and discrepancies are analyzable.
Billing Engine Configuration
The traffic billing engine needs a billing mode (by data volume, by duration, or by data pool), overage billing rules, and data pool allocation rules. Results are written to the bill for carrier reconciliation, customer collection, and settlement profit sharing. A wrong amount goes straight into the enterprise’s cost and profit figures. This is a core accounting function of the IoT Cloud Platform. The engine has to stay aligned with carrier mapping and plan packaging.
Fix the usage unit before it enters a bill
Traffic billing turns a card’s data usage in one cycle into an amount receivable or payable. The input is the usage record, the plan quota, and the unit-price rule. The output is a bill line. The usage unit has to be unified first. A carrier file may be in bytes, kilobytes, or megabytes, while the platform display commonly uses megabytes or gigabytes. The conversion rule has to stay fixed. Do not multiply a displayed value, after it has already been rounded, by the unit price. Otherwise every card has a rounding remainder of a few fen at reconciliation, and the total becomes a gap that cannot be explained. A session that crosses a cycle is placed in the agreed billing period, by start time, by end time, or by the time the usage record is booked. Pick one and use it throughout.
Plan fees and overage fees are listed separately. The plan fee is decided by the cycle and the tier. It does not depend on how much was used this month, unless the rule says unused service can be refunded. The overage fee multiplies only the part beyond the quota. A data pool first obtains the pool’s total fee or total overage, then writes it to cards or projects by the allocation already set. The allocated results must add back to the pool total. A remainder that is allowed to be left needs a collection rule, for example onto the primary card or onto a remainder line of its own.
Which lines may be overwritten when a bill is recalculated
Late usage is normal in traffic billing. If a supplementary usage record arrives after the first bill, generate an adjustment line. Do not quietly change an original line that has already been issued to the user or already used for settlement. Bills that have been collected or invoiced are locked. An estimate that has not been billed can be recalculated. If, after the lock, a rule is found to have been configured wrong, express it with a reversing line and a new line under the correct rule, and keep the wrong line for audit.
The billing rule and the selling price are not the same number. The plan price shown to the user sits in the packaging layer. The settlement price toward the carrier sits in the tariff plan. The agent price toward the channel sits on the price list. All three prices start from the same usage, but the amounts must not overwrite one another. SimtoLink’s traffic billing turns usage, quota, and these three prices into a bill that can be checked, for collection and reconciliation, rather than showing only a remaining-traffic figure on a dashboard.
Put allocation remainders on their own line
When a data-pool charge is split across members, a division that does not come out even leaves a remainder. Quietly adding that remainder to the card with the largest usage distorts that card’s unit price, and the user cannot check it. The clearer method is to calculate member lines by one rounding rule and put the remainder on its own line, collected into an agreed cost center, not disguised as some card’s usage. Remainders on the plan fee and on the overage fee stay separate. They are not mixed into one adjustment amount. A remainder on a bill that is already closed is not allocated again. SimtoLink billing keeps the remainder line on the pool bill, so member amounts plus the remainder return to the total the pool has to pay.