Payroll is the largest expense at most organizations and the one whose data is handled most carefully, which is why it is analyzed least. The ghost employee, the terminated employee still being paid, the overtime that no supervisor saw, the rate change entered by the person it benefits: each leaves a pattern in the payroll register and the HR master that a set of joins will find in an afternoon, provided the auditor can get the data and is allowed to keep it long enough to run the tests. This catalog sets out thirty tests in five families, ghost employees, lifecycle and terminated-but-paid, rate and overtime outliers, off-cycle runs and adjustments, and cross-file matches, each with its logic, data, threshold, what a hit usually means and what produces false positives. It then covers the data and the handling rules the tests depend on, how to run the catalog, a test record template, a worked first run at a distributor with 1,400 employees and an outsourced payroll provider, and the path to a continuous program.
This guide was rewritten in September 2026 from a shorter version published in August 2026. The tests are stated in fields rather than tools. The ACFE’s Occupational Fraud 2026: A Report to the Nations, drawn from 2,402 cases across 143 countries, puts the median occupational fraud loss at $104,000 and reports that schemes lasting five years or more had median losses above $1.1 million; payroll schemes are among the longest-running because the payments look like every other payment, and the tests here are designed to shorten them.
In this guide
- The data you need first, and how to handle it
- Family 1: Ghost employees (8 tests)
- Family 2: Lifecycle and terminated-but-paid (6 tests)
- Family 3: Rate and overtime outliers (6 tests)
- Family 4: Off-cycle runs and adjustments (5 tests)
- Family 5: Cross-file matches (5 tests)
- Building the three hardest joins
- When payroll is outsourced
- Segregation of duties in payroll, tested from the data
- Running the catalog: thresholds, triage and corroboration
- The payroll analytics test record
- Worked example: MidState Beverage’s first payroll run
- From one-off run to continuous program
- Common mistakes
- Related guides
The data you need first, and how to handle it
Five datasets carry the catalog. The HR master: employee ID, name, date of birth, tax ID, addresses, hire date, termination date and reason, status, department, cost center, manager, job and grade, pay band. The payroll register, per pay period: employee ID, gross by earnings code (regular, overtime, bonus, one-time), deductions, net, bank account paid to, pay date, run type (regular, off-cycle, manual). The time data: hours by day, entry source (clock, timesheet, manual), approver, approval timestamp. The change history for HR and payroll master data: rate changes, bank changes, status changes, each with date, user and old and new values. And the vendor master and the active directory or badge system, for the cross-file family. Completeness is proved before anything runs: register totals reconciled to the general ledger payroll expense and to the bank payment files by period; headcount by period reconciled to HR’s own report; time hours reconciled to the register’s paid hours by period. The reconciliations are the population record, following the IPE testing guide.
Handling is the part that distinguishes payroll analytics from every other catalog. The data contains bank accounts, tax identifiers, dates of birth, home addresses, pay and sometimes health-related deductions, and the run is subject to the organization’s data protection obligations and, in many jurisdictions, to statutory rules on employee data. The working rules are: obtain the data under a documented arrangement with HR and legal that names the purpose, the fields, the retention and the people; pseudonymize what can be pseudonymized before analysis, keeping the key with HR; hold the working files in a restricted location with access logged; destroy the identified data at the end of the engagement and keep only the results at the level of the findings; and never copy the HR file into a general analytics workbook. The data privacy audit guide sets out the obligations the audit function is itself subject to here, and an auditor who cannot describe the handling arrangement should not have the file.
One further rule applies to every family: the drivers, plant staff, contractors and seasonal workers who sit outside the office systems are in the population, not outside it. The populations that are hardest to join are the ones where ghosts and terminated-but-paid records survive longest, because no directory logon or badge record ever contradicts the register, and the first run at any organization should say explicitly which populations each test covered and which it could not.
Family 1: Ghost employees (8 tests)
A ghost is a record in the register that does not correspond to a person doing work: a fabricated employee, a terminated one kept alive, or a real person paid for a job they do not perform. The tests look for the attributes a fabricated record cannot easily have, a unique bank account, a unique address, a physical presence, time recorded, and for the attributes it usually shares with its creator.
| Test | Logic | Data and threshold | A hit usually means | False positives |
|---|---|---|---|---|
| G1 Shared bank accounts | Two or more active employees paid to the same normalized bank account | Register bank fields | A ghost paid to a real employee’s account; or a payroll clerk’s own account attached to several records | Spouses or relatives who both work for the organization and share an account |
| G2 Shared addresses | Multiple employees at one standardized address beyond a household threshold (for example more than three), or an address matching a payroll or HR user’s | HR addresses | Fabricated records using a controlled address | Shared housing, family members, employer-provided accommodation |
| G3 Duplicate tax IDs | Same tax identifier on more than one employee record, or an identifier failing the jurisdiction’s format or check-digit rule | HR tax ID field | Recycled identity or an invented number | Data entry errors; legitimate rehires with two records |
| G4 Paid with no time | Hourly employees with pay in periods where no time was recorded, or salaried employees with no clock, badge or system activity for the period | Register joined to time data; badge or system logs where available | A record being paid without work; or time recorded outside the system | Paid leave; salaried exempt staff in roles without time capture |
| G5 Register-to-HR orphans | Employee IDs in the register with no matching active HR record, or HR records with no register entry (reverse orphans) | Register and HR master | A record created in payroll without HR’s knowledge, the purest ghost pattern; reverse orphans are usually unpaid leave | Timing differences between HR and payroll updates |
| G6 Thin-profile employees | Records missing attributes real employees have: no emergency contact, no benefits elections, no manager, no email or directory account, no performance record | HR master attributes; directory | A fabricated record that was created with the minimum fields | Casual and seasonal workers set up quickly |
| G7 Paid but never present | Employees with no badge entries, no directory logon and no expense claims over a period, while paid | Badge, directory and expense systems | Ghost, or a remote worker outside every system, which the organization should know | Fully remote roles; field staff who never enter a building |
| G8 Cluster affinity | Groups of records sharing a creator, a creation date range, a department and one of the attributes above | HR change history; clustering on shared attributes | A batch of ghosts created by one person | Genuine bulk hires (a new site, an acquisition) |
Family 2: Lifecycle and terminated-but-paid (6 tests)
The lifecycle family tests the joiner-mover-leaver process from the payroll side, and the terminated-but-paid test is the single highest-yield test in the catalog at organizations with high turnover, because the failure is procedural (HR told payroll late, or not at all) and the money is recoverable when found quickly.
| Test | Logic | Data and threshold | A hit usually means | False positives |
|---|---|---|---|---|
| L1 Paid after termination | Regular pay in a period starting after the HR termination date, excluding final pay and approved post-termination amounts | Register and HR termination dates | Termination not communicated to payroll; or a terminated record kept alive deliberately | Severance and retention payments coded as regular pay; termination dates recorded late |
| L2 Final-pay overshoot | Final payment exceeding the pro-rated regular pay plus documented leave payout and severance by more than a tolerance | Register final pay; leave balances; severance agreements | Error in final pay calculation; manipulated leave balance; unauthorized severance | Contractual entitlements not visible in the payroll data |
| L3 Term-rehire churn | Employees terminated and rehired more than once in a window, or rehired within days of termination | HR status history | Manipulation of final-pay entitlements, benefits eligibility or probation; or record recycling | Seasonal patterns; genuine rehires |
| L4 Paid before start | Pay in a period ending before the HR hire date, or a rate effective before the hire date | Register and HR hire dates | Hire date manipulated for entitlements; record created before the person existed | Signing bonuses paid on offer acceptance; date entry errors |
| L5 Leave-balance manipulation | Leave balances increased by adjustment rather than accrual, balances above the policy cap, or payouts of balances that were adjusted upward shortly before | Leave accrual and adjustment history | Self-granted or granted leave converted to cash | Corrections of genuine accrual errors, which should be documented |
| L6 Retro-adjustment concentration | Retroactive pay adjustments by processor, by employee and by period, against the population norm; adjustments reversing and re-posting | Register adjustment codes; change history | Errors being fixed by adjustment instead of at source; or a channel for unauthorized pay | Legitimate back pay after late rate approvals |
Family 3: Rate and overtime outliers (6 tests)
Rate and overtime tests find the payroll equivalents of the AP catalog’s approval and threshold patterns: the change entered by the beneficiary, the overtime nobody reviewed, the pay above the band. They need the pay bands and the delegation for rate changes as inputs, taken from HR policy rather than from memory.
| Test | Logic | Data and threshold | A hit usually means | False positives |
|---|---|---|---|---|
| R1 Rate-change velocity | More than N rate changes for one employee in a window (for example three in twelve months), or changes reversed within a period | Rate change history | Temporary uplifts used to inflate a period’s pay; errors and corrections that hide a pattern | Progression steps; acting-up allowances properly approved |
| R2 Self-serving rate changes | Rate or allowance change entered by the employee it affects, by their direct report, or approved by the same user who entered it | Change history users; org hierarchy | Segregation failure in HR or payroll administration; the highest-risk hit in the family | None; every hit is at least a control finding |
| R3 Overtime outliers | Overtime hours per employee per period above a plausibility cap (for example hours implying more than 16 hours a day), or above the department’s 99th percentile for consecutive periods; overtime approved by one supervisor for one employee repeatedly | Time data; register overtime codes | Fictitious hours; a supervisor-employee arrangement; or an understaffed operation that should be visible to management | Genuine peak periods; on-call roles |
| R4 Approval loops | Time or overtime approved by the employee, by a subordinate, or by a supervisor who is themselves the employee’s subordinate elsewhere in the hierarchy; approvals within seconds of submission | Time approval log; org hierarchy | Approval routing that does not enforce independence; rubber-stamping | Small teams with legitimate delegated approval, which is the finding |
| R5 Above-band pay | Base rate outside the pay band for the job and grade; allowances outside policy | Register rates; pay band table | Unapproved exception, or grade and job mismatched in HR | Grandfathered rates; approved exceptions not flagged in the data |
| R6 Adjustment digit patterns | Manual adjustments and one-time payments concentrated at round amounts or just below an approval limit; first-digit deviation for a processor’s adjustments | Register adjustment amounts; limits | Structuring of manual payments below review thresholds | Policy amounts (fixed bonuses, allowances) that are round by design |
Family 4: Off-cycle runs and adjustments (5 tests)
The regular payroll run is heavily controlled; the off-cycle run, the manual payment and the one-time code are the side doors, and the family looks at whether they are used more than a well-run payroll needs.
| Test | Logic | Data and threshold | A hit usually means | False positives |
|---|---|---|---|---|
| O1 Off-cycle concentration | Off-cycle runs and payments by processor, by employee and by month against the norm; employees paid off-cycle repeatedly | Register run type | A process that cannot get pay right in the regular run, or a channel being used for unauthorized amounts | Legitimate corrections after a system change |
| O2 Outside-system payments | Payments to employees from AP, treasury or expense systems coded as pay, awards or advances | AP and treasury payments to employee IDs or bank accounts | Pay bypassing payroll controls and withholding; advances never recovered | Genuine expense reimbursements, which should be excluded by code |
| O3 Gross-to-net anomalies | Net pay not reconciling to gross less statutory and voluntary deductions within tolerance; deductions of zero where statutory deductions are expected | Register components | Withholding manipulated or bypassed; a record set up outside statutory rules, which ghosts often are | Legitimate exemptions properly documented |
| O4 Duplicate pay in period | Two regular payments to one employee in one period, or the same net amount to one account twice within days | Register | Duplicate run or re-issued payment not reversed | Split payments by employee election |
| O5 One-time code concentration | One-time earnings codes (bonus, award, correction) by processor and by employee against the norm; codes with no supporting approval record | Register earnings codes; approval records | Discretionary payments outside governance | Legitimate bonus cycles, which cluster by design |
Family 5: Cross-file matches (5 tests)
| Test | Logic | Data and threshold | A hit usually means | False positives |
|---|---|---|---|---|
| X1 Employee bank equals vendor bank | Employee payroll account matching a vendor master bank account | Register bank fields; vendor master | An employee-owned vendor, disclosed or not; the AP catalog’s V1 seen from the other side | Employees legitimately set up as vendors for reimbursement |
| X2 Dual-status double dip | Individuals paid both as employees and as contractors or vendors in overlapping periods | Register; AP payments; tax ID or name match | Misclassification with tax consequences, or double payment for one role | Legitimate transitions with a short overlap |
| X3 Payday-adjacent bank changes | Employee bank account changed within days before a pay date, especially by a payroll user rather than through self-service, and changed back after | Bank change history; pay calendar | Diversion of one pay run, the payroll version of business email compromise | Genuine changes that happen to precede payday |
| X4 Deduction routing changes | Voluntary deductions (garnishments, savings, charitable) redirected to new payee accounts, or new deduction payees created and used once | Deduction master and change history | Diversion through the deduction channel, which few organizations monitor | Legitimate new payees (a new benefits provider) |
| X5 Recycled identities | Terminated employees’ tax IDs, bank accounts or addresses reappearing on new records with different names | HR history; new hires | A ghost built from a real former employee’s data | Rehires with a name change |
Building the three hardest joins
Three joins account for most of the build effort. The register-to-HR orphan test (G5) is a full outer join of the register’s distinct employee IDs per period against the HR master’s active records per period, with the period boundaries taken from the pay calendar rather than the calendar month, and a tolerance of one period for the timing differences between a hire or termination and its first or last pay; records that survive the tolerance are the hits, and the join has to be run per period rather than once, because a ghost active for three periods in the middle of the year disappears from a year-end snapshot. The paid-with-no-time test (G4) joins the register’s hourly earnings by employee and period to the sum of approved hours from the time sources for the same period, and its difficulty is that the time sources differ by population: drivers’ hours come from the route settlement system, warehouse hours from clocks, office hours from timesheets, and the join needs a population map that says which source is authoritative for whom, which is itself a finding when nobody can produce it. The overtime plausibility test (R3) computes hours per employee per day from the time detail, flags days above the cap (16 hours is a common starting point; the labor law limit where one applies) and counts consecutive periods above the department’s 99th percentile; it needs day-level detail, and where the provider extract carries only period totals the test runs at reduced strength and the record says so. Parameters live in a configuration table, and the pseudonymization key never enters the analytics environment.
When payroll is outsourced
Most mid-sized organizations run payroll on a provider’s platform, and two consequences follow for the catalog. The data comes from the provider’s reports and extracts, so the population reconciliation has to prove the extract’s completeness against the provider’s own control totals and the organization’s ledger, and the provider’s SOC 1 report has to be read for the controls over report generation and for the complementary user entity controls the organization is assumed to perform, as the SOC 1 review guide sets out; MidState’s review of its provider’s report found two of four complementary controls not operating, which is typical. And the change history may be thinner than an in-house system’s: some platforms log who changed a bank account and when, some log only that it changed, and the tests in the rate and cross-file families degrade accordingly. The audit asks for the provider’s audit trail export early, tests what it contains, and states in the report which tests could not be run at full strength because the provider does not retain the field. Where the provider offers its own anomaly reports, they are inputs to the catalog, not substitutes for it, because the provider tests what it is paid to test.
Segregation of duties in payroll, tested from the data
Several tests in the catalog (G8, R2, R4, X3, X4) are segregation tests in disguise, and the program should read their results together as evidence about the payroll and HR administration model rather than as isolated hits. The four functions that have to be separated are record creation and maintenance (creating employees, changing rates and bank accounts), time approval, payroll processing and release, and reconciliation and review. The data says who actually did what: the change history names the user who created each record and changed each rate and bank account, the time log names the approvers, the run log names who processed and released, and a matrix of users against the four functions, built from the logs rather than from the role design, shows every user who touched more than one. At small organizations the matrix will show the payroll administrator in three of the four columns, and the finding is then about the compensating review, who performs it, at what precision and with what evidence, which the segregation of duties framework calls the ladder of alternatives. At larger ones the matrix usually shows a handful of HR super-users and a payroll manager whose backup role was never removed, and the user access review guide covers the review that should have caught them. Either way, the data-built matrix is the evidence, and it is far more persuasive than the role design document, because it shows what happened rather than what was intended.
Running the catalog: thresholds, triage and corroboration
Thirty tests on a year of payroll data produce hundreds to a few thousand hits, fewer than the AP catalog because the population is smaller, and the triage is more sensitive because every hit is a person. The first run sets parameters so that each test’s list is reviewable, records them, and tunes them in later runs. Scoring across tests orders the queue: a record that hits G1, G4 and G6 together is the ghost pattern and goes to the top; a record that hits R3 alone is an overtime question for the supervisor. The triage passes are the same three as for AP, mechanical, desk and corroboration, with one addition: before any hit is discussed with a manager or a supervisor, the auditor considers whether that manager could be the counterparty, because the person who created a ghost is usually the person who would be asked to explain it. Collusion-pattern hits and anything in the ghost family go to the fraud response protocol described in the fraud risk management guide before anyone in the line is told.
Corroboration for payroll has one technique the other catalogs lack: physical or digital existence. A suspected ghost is corroborated by finding the person, through the badge system, the directory, the manager’s confirmation in an unannounced check, the benefits enrollment, the tax authority’s records where the organization can lawfully use them, or, in the classic method, by having pay slips or a small manual check collected in person. A terminated-but-paid hit is corroborated by the HR termination record and the bank return or the recovery correspondence. A self-serving rate change by the change log and the absence of an approval. The payroll audit guide covers the control tests corroboration leads into, and the fraud red flags guide the behavioral indicators, present in 84 percent of the 2026 report’s cases, that the data patterns often accompany.
The payroll analytics test record
Payroll analytics test record
1. Test. Catalog reference and name; family; run date; periods covered; analyst; data handling arrangement reference.
2. Population. Datasets and extraction method (in-house system or provider export); record counts; reconciliation of register totals to the ledger and to bank payment files; headcount reconciliation; time-to-pay reconciliation; pseudonymization applied and key custodian.
3. Parameters. Thresholds, windows, caps and bands used; sources for pay bands, delegation and policy limits.
4. Results. Raw hits; hits after the mechanical pass with systematic causes listed; hits after the desk pass by explanation category; hits to corroboration; composite-score ranking used.
5. Corroboration. Per hit: evidence, conclusion (error, control failure, policy breach, suspected fraud, false positive), amount, recovery, referral; fraud protocol invocation where applicable, with the date and who was informed.
6. Findings. Control failures with counts and amounts; finding references; process and system changes agreed; provider issues raised.
7. Tuning and limitations. False-positive causes to remove; parameter changes; tests not run at full strength because of missing fields, with the field named.
8. Close-out. Identified data destroyed (date, method); results retained at finding level; analyst and reviewer sign-off.
Worked example: MidState Beverage’s first payroll run
MidState Beverage, the illustrative distributor used across this site, has about 1,400 employees, 300 of them drivers paid on route-based hours, twelve depots with their own timekeeping practices, and payroll on a cloud provider whose SOC 1 Type 2 report covers 1 October to 30 September. The analytics auditor ran the catalog on fourteen months of provider extracts, 37,800 pay records, reconciled to the ledger’s payroll expense within $900 and to the bank files exactly, with an HR file of 1,400 current and 312 terminated employees and the time data from the route settlement system and the depot timesheets. The handling arrangement, agreed with HR and counsel, pseudonymized the file at extraction with HR holding the key, and the run took 140 hours including the corroboration.
| Family | Raw hits | After triage | What was found |
|---|---|---|---|
| Ghost employees | 168 | 9 | Six shared bank accounts (G1), five of them married couples and one a driver paid to a depot clerk’s account for four periods, corroborated as a stopgap for a lost card and reversed, written up as a control failure; no fabricated records; 22 thin-profile seasonal hires (G6) confirmed present at depots |
| Lifecycle | 91 | 14 | Eleven employees paid after termination (L1), $19,400 in total, all from terminations the depots reported to HR between eight and thirty days late; nine recovered; three term-rehire cycles (L3) at one depot used to reset probation, a policy breach |
| Rates and overtime | 430 | 38 | Overtime at two depots where four drivers recorded hours implying more than 15 hours a day for eleven consecutive periods (R3), approved by a supervisor who was the brother-in-law of two of them (R4), referred; 17 rate changes entered and approved by the same HR administrator (R2), a segregation finding; six above-band rates (R5) with approved exceptions on file |
| Off-cycle | 210 | 12 | Off-cycle runs concentrated in the two acquired distributors’ first months on the platform (O1), explained by migration errors; 40 payments to employees through AP coded as awards (O2), $31,000, bypassing withholding, a tax compliance finding |
| Cross-file | 27 | 4 | One employee bank account matching a vendor (X1), the depot manager’s trucking vendor already referred from the AP run; two bank changes made by a payroll user two days before payday and reversed after (X3), corroborated as a diverted pay run of $4,100 recovered from a former payroll clerk |
Eight findings resulted: the depot termination reporting delay (High, with a fix in the route settlement system that locks a driver’s route on the termination date), the overtime and approval loop at the two depots (referred, then High), the HR administrator’s self-approved rate changes (High), the payroll clerk’s diverted run (referred and recovered; the bank-change verification control that should have caught it did not exist and became a High), the AP awards channel (Medium), the probation reset pattern (Medium), the stopgap bank account practice (Medium) and the migration off-cycle errors (Low, closed). The provider’s audit trail did not capture who entered time adjustments before approval, so R6 and L6 ran at reduced strength and the report said so. The recoveries totaled $27,600, modest against the AP run, but the overtime and rate findings closed an annual leakage the CFO estimated above $200,000.
From one-off run to continuous program
The transition follows the same four steps as the AP catalog, with two payroll-specific adjustments. The terminated-but-paid test and the payday-adjacent bank change test move to management as pre-run controls, executed by payroll before each run on the current period’s data and evidenced, and internal audit then tests them as controls; the ghost and collusion families stay with internal audit and run quarterly on pseudonymized data. And the data handling arrangement becomes a standing agreement with HR rather than a per-engagement negotiation, with a retention rule that identified data exists only for the duration of each run. The continuous auditing versus continuous monitoring guide draws the line between what the function keeps and what it hands over, and the internal audit risk assessment guide shows how a run’s results move payroll’s rating in the next plan.
Common mistakes
Taking the HR file without a handling arrangement, or keeping it after the run. Reconciling the register to nothing and discovering later that the extract excluded a company code or a pay group. Discussing a ghost hit with the supervisor who created it. Treating spouses with a shared bank account as a finding and a driver paid to a clerk’s account as a false positive, when it is the other way round. Running overtime tests without a plausibility cap and reviewing three thousand hits. Ignoring the deduction channel. Accepting the provider’s anomaly report as the catalog. Reporting hits as anomalies rather than as the control failures behind them. Skipping the physical-existence corroboration because the directory says the person exists, when the directory record was created by the same person who created the payroll record. And forgetting that the audit function’s own handling of the data is itself subject to the controls the data privacy audit guide would test. The accounts payable analytics catalog and the journal entry analytics catalog share this structure and the same triage discipline.
Related guides
- How to audit payroll
- The accounts payable analytics catalog
- The journal entry analytics catalog
- How to review a SOC 1 report
- How to audit data privacy compliance
- IPE testing
- Fraud risk management
- Fraud red flags
- How to perform a user access review
- Continuous auditing versus continuous monitoring
- Internal audit risk assessment
Leave a Reply