Commissions tied to activation and payment

Declare the milestones that pay and the source of each: sale (deal won date), activation (product milestone or onboarding date), first payment (accounts receivable or billing), usage (consumption in the first 30 days after activation). The milestone date is the event date at the source, never the date someone moved the stage in the CRM.

Discard canceled installments, sort the customer's remaining ones by due date and keep the first. It counts when it has a payment date. Second and third boletos follow the same rule for AM targets. A charge declined and then paid is a single payment.

Real example: activation by W+5. The sale week runs Sunday to Saturday and the deadline ends on the Saturday of the fifth following week. Rate per person and sale week = sales activated on time / sales of the week, with a target (for example, 60%) and a stretch target (80%). A sale activated late shows as late, it does not disappear.

The sale's SDR or ISA is the deal owner on the won date. The AM of an account in a past month is the owner valid on the cutoff day (for example, the 5th); the current month uses the current owner. Read from owner history, never from today's owner. An account enters an AM's book only if it was active on the reference date.

Use the CRM user id and a people table with mapped spellings and nicknames, team, role, start and end date. Never join on a name typed in a free field or a spreadsheet.

When variable pay depends on the revenue the customer generates on the platform (transaction volume, platform revenue), measure it in 30-day cycles from the close (cycle 1, 2 and 3) and compare with the 30 days before the close. Real result = cycle 1 minus the previous 30 days, so you do not pay for revenue that already existed.

Targets per person and period and parameters (percentages, bands, deadlines) live in a table with start and end validity, not in code. A month's payout uses the version valid that month. A day-prorated target (monthly target x elapsed days / days in the month) is for tracking, never for paying.

Test deals, internal and duplicate accounts are excluded through a list with a reason, not ids written in code. Manual MRR or credit adjustments go into a table with author, date and reason, added to the payout and visible on the person's statement.

The calculation base has one line per sale (or account) and milestone, with person, dates, status (on time, late, pending, canceled) and the unique key (for example, week plus deal id) the commission tool uses to update without duplicating. The person's total is the sum of those lines, and they can check them one by one.

After payout, the month is stored and not recalculated. A payment or activation that arrives later goes in as an adjustment in the month it was found, with the original month recorded. A cancellation after payout follows the declared clawback rule, without rewriting the past.