Calculate BotMarketing Commission by Payment and Cohort

Affiliate income calculations often mix three amounts: commission on customer payments, rewards marked “To pay”, and cash already received. Add content or advertising costs and “30%” is no longer a complete answer.

This guide helps you build a payment ledger and monthly cohort table for BotMarketing. All examples are fictional and use one currency unit; they are not prices, actual payouts or earnings forecasts. Your account records and applicable terms replace the assumptions.

Start with one payment and the signup date

Each line needs a payment identifier, referred user, signup date, confirmed payment date, amount and currency, applied percentage, reward, status and payout date. Do not substitute invoice creation or plan purchase dates for the payment date.

Standard new BotMarketing partner account terms are 30% before the referred user's registration anniversary and 5% from that point. The applicable rate comes from the referrer's conditions; check your own account and company-specific terms separately. The first year does not restart with the first paid subscription. Exact boundary checks use date and time in UTC.

For an eligible payment: commission = round(payment amount × percentage / 100, 2). Sum the rounded lines while preserving currency. Registrations are not a payment base, and amounts in different currencies cannot simply be multiplied together by 30%. The programme guide explains attribution and terms.

Use BotMarketing to reconcile referral payments

Here the service provides specific reward records. The partner table does not replace your cost ledger or promise a complete cohort-retention report.

1. The partner checks terms and the link. They verify their percentages, select a suitable customer task and use their own friend code. The cookie lasts 30 days; UTM labels do not replace it, and a partner-linked promo code takes priority at company registration.
2. The client registers and pays for the service. This is a business owner for whom BotMarketing fits. A subscription payment and valid attribution matter; another partner signup or an order at the client's shop does not substitute for a service payment.
3. The partner reads the account record. In Referral payments, they see the line ID, referred user, payment amount and currency, reward, percentage, status and payout date. Treat To pay, Paid and Canceled separately. A new reward awaiting payment does not establish cash receipt.
4. The partner reconciles manually. They copy relevant lines and compare them with money received and costs. Ask the operator for missing signup dates, refund explanations or terms; do not assume a ready-made export or automatic cohort table exists.

Accrual requires a confirmed payment with a date and referrer attribution; processing does not establish an instant payout at purchase. If a record is absent or differs, retain its ID or payment details, currency and reconciliation question. Do not create a second assumed reward for the same payment.

Check three illustrative scenarios

For the first two rows, the user registered on 10 March 2025 at 12:00:00 UTC. For the third, signup was 10 January 2026. All listed payments are confirmed and attributed, using standard 30%/5% terms. The table calculates rewards rather than confirming their payout status.

Calculate an annual payment from its actual amount and applicable rate on the payment date. Do not split it into twelve payments absent from the ledger or apply 5% to part of that line because of a future anniversary. A discount may change the amount: use the confirmed payment, not an advertised list price.

Do not handle a refund or cancellation by inventing a reduction to the base. Establish which adjustment the operator confirms and records. An isolated refund message does not establish automatic clawback of paid commission. For personal reconciliation use total = valid recorded rewards − confirmed adjustments; do not subtract a canceled line twice. Keep an unknown adjustment separate pending clarification.

Build monthly cohorts without inventing retention

A cohort groups users by signup period or an agreed acquisition channel. Keep individual payment lines first, then group them. This is a separate fictional example: two users registered in January 2026 and one in February. All payments fall in year one, in one currency, without adjustments.

February contributes 420 units and March 30, totalling 450 for these lines. Zero March payments from an annual customer do not establish churn: the period was prepaid. Check subscription coverage and product use separately before interpreting retention. A paid month and active use are different signals.

Keep next month's payments unknown until observed. A scenario must state payer counts, amounts, dates and rates explicitly; do not add it to accrued totals. The bounded paid-traffic test provides a separate channel-economics example.

Separate accrual, cash and the result after costs

Suppose 360 of the fictional 450 units are confirmed as paid and received, while 90 remain to pay. Channel costs were 250. The period's cash result before taxes and other omitted costs is 360 − 250 = 110. Pending 90 is not cash received; 450 − 250 = 200 answers a different question.

Keep setup and support services separate from commission. Their income and labour do not appear in Referral payments; the freelancer launch package defines work boundaries. Do not combine currencies without an explicit exchange rate and conversion date; confirm the currency and terms applicable to your market.

• Reconcile identifiers so a payment enters the total only once.
• Check signup and confirmed payment dates around the anniversary.
• Exclude canceled lines from valid accrual and avoid repeating an adjustment.
• Total pending rewards, paid records and cash actually received separately.
• Keep unconfirmed payments, refunds and future renewals as open questions.

The result is a reproducible ledger: which payment produced each amount, which rate applied, what was paid and what still needs clarification. That gives a more useful answer than an annual income figure assuming every customer has the same lifetime.