Payroll Eligibility: Why It Should Never Be a Separate Spreadsheet

The problem: two versions of the truth

Ask a payroll admin at most companies where their eligible-employee list comes from, and the honest answer is usually: a spreadsheet someone maintains by hand, updated whenever they remember to reflect a new hire, a termination, or a change in employment status. Meanwhile, HR has its own record of who's actually employed, who's on leave, who just started, and who just left. These are supposed to be the same list. In practice, they drift.

That drift is where payroll mistakes come from — not usually dramatic ones, but the quiet kind: a departed employee still on the payroll run, a new hire missing from it, someone on long-term leave included when they shouldn't be. Each of these is a symptom of the same root problem: payroll eligibility tracked as a separate process from HR data, instead of derived from it.

SAVHN's Payroll module is built around a simple fix — payroll runs against your actual, current eligible-employee list, resolved from the same employee data your HRMS already maintains, not a parallel roster someone updates by hand and hopes stays accurate.

What the Payroll module actually does

• Eligible-employee resolution — the set of employees included in a given payroll run is determined from real, current employee data, not a manually maintained list.
• Payroll runs — the actual cycle of processing payroll for the resolved set of eligible employees.
• Processing history — a record of past runs, so payroll status isn't something someone has to reconstruct from old exports when a question comes up later.

The core idea is that eligibility isn't a separate maintenance task. It's a resolution against employee records that are already being kept current for other reasons — leave status, employment status, the same data your HR team is already responsible for. When HR data changes, the eligible-employee list for the next run reflects that change, instead of requiring someone to remember to also update a second, disconnected list.

Manually maintained list vs. resolved eligibility

Manually maintained payroll list	SAVHN's eligible-employee resolution
Updated by hand whenever someone remembers	Resolved from current employee records at run time
Drifts from HR reality after new hires, exits, leave	Reflects HR data as it actually stands
Errors discovered after the run, often by the employee affected	Eligibility resolved against the same source of truth HR already maintains
No clear history of who was included in a past run and why	Processing history retained per run

How it works

1. Employee data is maintained in HRMS — hires, exits, leave status, and employment changes are recorded there as they happen.
2. When a payroll run is initiated, eligibility is resolved from that data, not from a separately maintained list. The employees included in the run are the employees who are actually, currently eligible.
3. The payroll run processes against that resolved set.
4. The run and its outcome are retained as processing history — a real record of what happened in each cycle, not something reconstructed after the fact from scattered exports.

This doesn't remove judgment from payroll — someone still has to run the cycle and review it — but it removes the specific failure mode where the list being paid against is quietly wrong because two systems fell out of sync.

Who uses this

• Payroll administrators, who need to run payroll against a list they can trust without cross-checking it against HR records manually every cycle.
• HR teams, whose employee record updates now have a direct, automatic effect on payroll eligibility instead of requiring a duplicate update somewhere else.
• Finance leadership, who need payroll processing history to be a real, retrievable record rather than something assembled from memory when an audit question comes up.

Common mistakes and misconceptions

The most common mistake is assuming payroll eligibility is a payroll-team responsibility that lives independently of HR. It isn't, and treating it that way is exactly what causes drift — eligibility should follow from HR data, not be maintained in parallel to it. If an employee's status changes in HRMS, that has to be the update that matters, not a second entry payroll staff maintain separately.

Another misconception is that "the payroll run happened" and "the payroll run was correct" are the same statement. Resolving eligibility from real data reduces one specific class of error — stale or incorrect employee lists — but it doesn't replace the need to actually review a run before it's finalized.

It's also worth being clear about scope: Payroll is not finance's invoicing and GST tracking, and it's not HRMS's leave approvals. It sits between the two — consuming HR data to determine who's in a run, and its outcomes ultimately factor into the broader financial picture tracked in finance.

Where it fits in SAVHN

Payroll's value comes specifically from not being an island. Its eligible-employee resolution depends directly on HRMS staying current, and payroll processing history is part of the same activity picture that feeds into organizational reporting elsewhere on the platform, including reports. That's the practical argument for a single platform over a collection of disconnected tools: the employee record HR updates this morning is the same record payroll resolves eligibility from this afternoon, with nothing manually re-keyed in between.

For details on configuring payroll cycles and reviewing processing history, see the documentation. For more on how employee data flows between modules, browse the Knowledge Center.