How pay is set up in finance and ERP systems

Pay is usually run in a dedicated payroll engine, either a module inside the ERP or a separate service, fed by the HR record and a time system. The engine calculates gross to net, posts a summarised journal to the ledger and sends payment files to the bank.

Where the data comes from

Three sources feed a pay run. The HR system holds the employee master: hire date, position, cost centre, pay group, bank details. A time and attendance tool captures hours worked, overtime, shift premiums and absence. The payroll engine itself stores pay rules and tax tables.

Time usually arrives through a scheduled interface or a file upload before each cut-off. Hourly staff depend on it completely. Salaried staff often pay by default unless an exception is keyed. Where no time system exists, managers submit timesheets and a payroll clerk enters them by hand, which is where most errors start.

How earnings and deductions are held

Each type of pay is set up as an earnings code. Base salary, overtime, bonus, commission and allowances each get their own code, and every code carries rules: whether it is taxable, whether it counts toward pension, which ledger account it maps to.

Deductions work the same way on the other side. Statutory items such as income tax and social contributions are calculated by the engine from tax tables. Voluntary items such as pension, union dues, benefits and salary sacrifice are configured per employee, often with start and stop dates. Court orders and garnishments sit here too, and they need careful priority rules so the right amount is taken in the right order.

Good setups keep earnings and deduction codes few and well named. Poor ones accumulate codes nobody can explain.

Tax status and statutory changes

Employee tax status changes through life events, new tax codes from the authority, or a move between jurisdictions. Most systems receive electronic notices from the tax authority and apply them automatically. Others rely on someone reading a portal and keying the update. Annual table changes are normally delivered by the software vendor and tested before go-live.

Multi-country organisations often run a different engine per country, glued together with a common reporting layer.

The pay run and payment

A typical cycle opens the period, locks inputs at cut-off, runs a trial calculation, reviews exception reports, then finalises. Reviewers compare gross and net totals against the prior period and chase large swings.

Once approved, the engine produces a bank file for net pay, payslips for employees, and remittance files for tax authorities, pension providers and other third parties. The bank file usually passes through the treasury or payments platform so it falls under the same approval and signing controls as supplier payments.

Manual checks and off-cycle payments

Mistakes, missed hours and final pay for leavers create demand for payments outside the main run. Mature setups handle these as off-cycle runs inside the engine so tax and ledger postings stay correct. Weaker ones issue a manual check or a one-off bank transfer and fix the payroll record later. That gap is a common audit finding, so it is worth knowing which route is actually used.

Period-end adjustments and the ledger

The engine posts a journal after each run, typically summarised by cost centre and account. Finance then reconciles payroll liability accounts, clearing them as tax, pension and net pay leave the bank.

At month end, accruals cover pay earned but not yet paid when a pay period straddles the close. Corrections from prior periods, retro pay and reversed payments all flow through as adjustments. Year-end brings its own work: statutory filings, employee tax statements and reconciliation of annual totals to what was remitted.

Handling employee questions

Queries about pay arrive by email, through an HR service desk or via a self-service portal where staff view payslips. Many organisations route them through a case tool with categories, so recurring issues show up. A query often reveals an upstream problem, such as a late time entry or a bank detail change that never reached payroll.

Questions to ask the people who run it

What is documented and what happens on pay day tend to drift apart. These questions surface the difference:

• Which inputs arrive after cut-off, and what happens to them?
• How many spreadsheets sit between the time system and the payroll engine?
• Who can change bank details, and does anyone check the change before the next run?
• When a manual check goes out, how and when does the payroll record catch up?
• Which earnings or deduction codes are no longer used but still active?
• How are tax notices received, and who confirms they were applied?
• What does the pre-approval review actually look at, and who signs it off?
• Which payroll liability accounts carry old balances nobody can explain?
• What do employees ask about most, and where does that problem originate?
• If the usual payroll person is away, who can run the cycle end to end?

The answers usually point to the handoffs, not the engine, as the place where change will pay off.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.