PLG OS

Implementation worksheet · 5 min read

A Referral Reward Reconciliation Worksheet

Reconcile five numbers monthly: rewards promised (qualifying events that met the published criteria), rewards granted (records created in your system), rewards paid (money or credit actually delivered by the payout provider), claims blocked (with reasons), and the unresolved difference. Promised should equal granted plus blocked; granted should equal paid plus pending. Any other result is drift, and drift is what ends referral programs — not poor performance, but finance losing confidence that the number is knowable. Investigate the difference monthly while it is small enough to explain.

Referral programs are funded on trust between growth and finance, and that trust is spent by unexplained variances rather than by weak results. A one-page monthly reconciliation keeps the conversation about performance instead of about bookkeeping.

Put it into practice

1. Pull the five numbers from their own sources

Promised from the qualifying-event log, granted from your rewards table, paid from the payout provider, blocked from the eligibility checks, pending from both. Never derive one from another — that hides the very gap you are looking for.

2. Check the two identities

promised = granted + blocked, and granted = paid + pending. These should hold exactly. When they do not, the difference is a defect with a location, not a rounding issue.

3. Categorise every blocked claim

Duplicate, ineligible, expired, suspected self-referral, reversed. A rising duplicate count usually means an idempotency gap rather than fraud; a rising self-referral count may mean your rule is too broad and is catching households.

4. Age the pending bucket

Payouts that have been pending for more than a few days are usually failing silently at the provider — wrong email, unsupported country, expired card. Pending is where a program's reputation degrades without anyone noticing.

5. Report one page monthly

Five numbers, two identities, the blocked breakdown, and one line explaining any variance. This is what keeps the budget, and it takes fifteen minutes once the queries exist.

Monthly reconciliation

Copy this structure into your review document and record your observed result for each row.

Monthly reconciliation
NumberSourceThis monthVariance note
Promisedqualifying-event log
Grantedrewards table
Blockedeligibility checks
Paidpayout provider
Pending > 7 dayspayout provider

A failure worth checking

The silent pending pile: rewards are granted, the dashboard shows the program working, and 12% of payouts have been stuck for six weeks because the provider cannot pay that country. The referrers believe you did not pay them, they say so publicly, and the first anyone internally hears of it is a support thread. Ageing the pending bucket is the one check that surfaces it before your users do.

Common questions

Who should own this?

Whoever owns the program, with finance receiving it rather than producing it. A reconciliation produced by finance becomes an audit; produced by growth it stays a management tool.

What variance is acceptable?

Zero on the identities — they are arithmetic, not estimates. Timing differences at month boundaries are legitimate and should be stated in the variance note rather than absorbed silently.

Basis and scope

This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.

Continue with PLG OS

Explore onboarding →