Referral bonuses become difficult to administer when the hiring record, employee eligibility, and payroll milestone live in different places. I use a bonus tracker that records the decision at each step and makes the next owner clear. The tracker does not decide eligibility by itself. It gives HR, recruiting, and payroll a shared record to review against the written policy.
Fields for the bonus tracker
My basic row includes:
- Referral ID and candidate record ID
- Candidate name and hired role
- Referrer name, employee ID, department, and employment status
- Referral submission date and ownership decision
- Candidate hire date and start date
- Reward rule or plan version that applies
- Eligibility check and eligibility reviewer
- Retention or other milestone date
- Approved reward amount
- Approval date, payroll submission date, and payout date
- Payment status and exception reason
I keep the plan version because reward rules can change while an older referral is still active. Without that field, it is easy to apply a new amount to an earlier submission by mistake.
Rules to define before tracking
The policy should say whether the referrer must be employed on the payout date, whether the candidate must remain employed through a milestone, and whether a referral is eligible when the candidate was already in the applicant system. It should also explain how shared referrals, rehires, internal transfers, contractors, and roles without a bonus are handled.
I record the rule decision as a value such as Eligible, Ineligible, Pending review, or Exception approved. I add the reason and reviewer rather than relying on a colored cell. A note such as "duplicate candidate record" is more useful than a red flag with no explanation.
Payout workflow
When a referral is submitted, I create the row and assign an owner. At hire, I verify the role and start date. Before the milestone, I place the row in a review queue. HR confirms the employee and candidate conditions, the appropriate approver signs off, and payroll records the submission and payment dates. The final status becomes Paid only after the payment record exists.
I never mark a bonus paid because an approval email was sent. Approval and payment are separate events, and the dates should remain separate in the tracker.
Exception log
I use a small exception section for decisions that do not fit the normal rule. It includes the referral ID, question, decision, approver, date, and policy basis. This keeps the main row readable and gives the team a place to find the answer when a similar case appears later.
Once a month, I reconcile the bonus tracker with hires, employee status, and payroll. I look for missing start dates, passed milestones with no decision, duplicate candidates, and payouts without a referral ID. A dependable tracker protects the employee relationship because the company can explain what happened instead of asking the referrer to reconstruct the process.