By Mokscha Haack and Deborah Piacitelli, CPP, MBA
Many vendors offer integrated payroll solutions that can streamline processing, statutory filings, payments, reporting, and employee-facing outputs. A good solution can reduce manual work, improve consistency, and make the payroll cycle more controlled.
Yet a familiar “crime scene” occurs: “Go-live” was six months ago; the implementation team has already packed up and moved on. The company-wide announcement said the new system would bring stability and control.
The logic seemed straightforward. Payroll was the victim, the new tool was supposed to be the prime suspect's replacement, and the case looked like it was solved before the investigation had even begun.
A budget was requested, challenged, defended, and eventually approved. Vendor selection began, requirements were gathered, and implementation started. The organisation celebrated go-live with enthusiasm and relief.
A few loose ends in the evidence were expected, of course, but the hope was that after a few cycles, the process would become more predictable, stable, and calmer. Except it has not.
The evidence keeps piling up. Incorrect payments still happen, overtime is still missed, and general ledger (GL) postings still fail. Employee bank account changes still cause rejected payments and stakeholders still escalate.
The new process is faster, but the weakness is still there. Not exactly the return on investment everyone had in mind.
However, the system may simply be the scene where the “crime” was discovered, not where it was committed. The real problem sits earlier in the process, and a good investigator reads the scene before they propose changes.
Fixing the Wrong Part of the Process
So, what went wrong? The short answer is that the organisation tried to fix the part of the payroll process that was not broken. The investigation started at the wrong scene.
In payroll, the first location where an issue is discovered is rarely the scene of the crime. Before solving a payroll issue, establish the chain of evidence and identify where it originated. The payroll process can broadly be divided into the following four parts:
- Pre-Payroll—This is where the organisation collects, validates, prepares, and submits payroll input such as joiners, leavers, transfers, salary changes, one-time payments, overtime, absence data, time and attendance data, bank details, cost centres, and other data needed to calculate payroll correctly.
- Run Payroll—The calculation itself, where gross pay, deductions, taxes, social security, employer contributions, net pay, and other payroll elements are processed.
- Payments—These cover net payments to employees and payments to third parties such as tax authorities, social security institutions, benefits providers, and pension funds.
- Reporting—This includes all payroll outputs: payslips, statutory filings, GL files, audit reports, management reports, data extracts, and internal or external reporting.
Payroll systems and vendor platforms usually support run payroll, payments, and a significant part of reporting—good ones do this very well. However, there is an important caveat: they don’t control pre-payroll data.
The quality of payroll output is only as strong as the quality of payroll input. Garbage in, garbage out.
Pre-Payroll Is Not Magically Solved by Payroll Technology
Payroll solutions can support pre-payroll through workflows, integrations, validation rules, input templates, dashboards, and automated checks.
Those capabilities can be valuable, but they do not own the upstream data. They also do not do the following:
- They do not make managers approve overtime on time
- They do not ensure finance communicates cost centre changes before cut-off
- They do not make employees update bank details before payroll closes
- They do not resolve the ambiguity between HR, finance, payroll, and local teams about who owns each input
Technology can support discipline. It cannot replace it. Even the best forensic tools cannot compensate for missing evidence or unreliable witnesses.
Ask These Three Questions
That is why payroll teams need to distinguish between the following three different questions:
- Where was the error noticed?
- Where did it originate?
- Who owns the corrective action?
These are not always the same. An incorrect one-time payment may be noticed on the payslip, but that does not mean the payroll calculation was wrong.
Unpaid overtime may appear as a payroll issue, but the root cause may sit in manager approval behaviour. A rejected bank payment may surface after payroll runs, but the root cause may be late employee data.
The payslip, general ledger (GL) file, bank statement, or employee query may identify the scene, but not the perpetrator. Once payroll follows the evidence rather than assumptions, the findings often look very different (see table).
Symptom | Root Cause | Solution |
| Incorrect one-time payment | - Vendor Output: Correct amount submitted, but payroll output was wrong
- Payroll Input: Stakeholder sent the correct amount, but payroll submitted the wrong input
- Stakeholder Data: Stakeholder sent the wrong amount or missed cut-off
| - Review calculation, configuration, mapping, or vendor processing
- Strengthen input checks and four-eye review
- Improve stakeholder ownership, validation, and deadline discipline
|
| Unpaid overtime | - Vendor Output: Overtime was submitted to payroll but did not appear in output
- Payroll Input: Overtime was available in the source system but missed from payroll input
- Stakeholder Data: Overtime was not entered or approved before cut-off
| - Review interface, configuration, or vendor processing
- Strengthen extraction, reconciliation, and input preparation
- Improve employee and manager time and attendance approval discipline
|
| Closed or incorrect cost centre/GL account | - Vendor Output: Correct cost centre submitted, but output mapping was wrong
- Payroll Input: Finance sent the correct data, but payroll used old or incorrect input
- Stakeholder Data: Finance did not communicate the change or communicated it after cut-off
| - Review configuration and GL mapping
- Strengthen payroll input controls and change tracking
- Improve finance-to-payroll governance and deadlines
|
| Payment to closed employee bank account | - Vendor Output: New bank account submitted, but payment file used old details
- Payroll Input: Employee sent new bank details, but payroll did not include them in input
- Stakeholder Data: Employee did not update bank details or updated them after cut-off
| - Review vendor processing and payment file controls
- Strengthen payroll input checks and audit trail
- Improve employee data process and cut-off communication
|
The investigation changes everything, and it re-frames the issue. It moves the conversation away from “payroll made a mistake,” “the vendor is bad,” or “we need a new tool” and toward a more useful conclusion: this specific issue originated at this specific point, under this specific ownership, because this specific control was missing, weak, or bypassed. That is how payroll becomes controllable.
Opening the Case File
For most recurring payroll issues, a practical investigation can stay within the payroll team. It does not need to become a workshop with six people, three flipcharts, and someone saying "let's take this offline" every 12 minutes.
The following 10 investigative questions are usually enough to establish the facts, identify ownership, and close the case:
- What was wrong?
- Where/When was it first detected?
- What data was expected?
- What data was received?
- Was it correct when payroll received it?
- Was it correct when payroll submitted it?
- Was it correct in the payroll output?
- Who owned the step where the error was introduced?
- What control should have caught it?
- What needs to change to prevent recurrence?
Over time, they can change the conversation and the culture.
The New Tool May Still Be Needed
None of this means that technology does not matter. Sometimes the payroll solution really is the problem. Sometimes the vendor is underperforming, the architecture is fragmented, the integrations are weak, the reporting is too manual, or the controls depend too much on human memory and heroic effort.
In those cases, a new tool may be justified. Even then, the investigation should come before the verdict; otherwise, the organisation risks investing heavily pursuing the wrong suspect.
A new platform may make a good process faster. It may make a controlled process more scalable and a mature process easier to monitor. However, it will not turn unclear ownership, late approvals, poor data quality, weak cut-off discipline, and informal workarounds into a controlled payroll operation.
In fact, automation can make upstream weakness more visible, and sometimes more dangerous. A more automated process removes some informal safety nets, which is a good outcome when formal controls replace them but a risk when they do not.
Before You Buy, Investigate
Before replacing a payroll solution, changing vendors, or launching a major transformation programme, payroll leaders should investigate the recurring issues they are trying to solve. Not just where they feel the hurt, but where the issues begin, as in the following:
- If most issues originate in vendor output, then vendor performance, system configuration, and output controls deserve attention
- If most issues originate in payroll input preparation, then the payroll team needs stronger internal controls, before or alongside any technology change
- If most issues originate in stakeholder data, then the organisation needs better upstream ownership, clearer deadlines, and stronger accountability
The answer may still be a new system, but that should be a conclusion based on the evidence, not an assumption.
Even the best payroll vendor cannot compensate for unclear ownership, weak upstream controls, poor stakeholder data discipline, or a process that relies on payroll to catch everyone else's mistakes at the last possible moment.
Before investing in a new tool, follow the evidence and ask a simpler question: Where does the problem begin? In payroll, the most expensive mistake is often not choosing the wrong system; it is solving the wrong problem.