HR and Payroll in One System: The Hidden Cost of Running People Data Apart From Operations

The finance manager of a nine-outlet retailer with 140 staff has five files open on the 29th, and payroll must go to the bank tomorrow: an attendance export from the punch clocks, a leave tracker kept by HR, a sales report for commissions, a payroll spreadsheet and the accounting package where the salary journal still has to be typed in. Two outlet managers have messaged that their overtime is missing. One employee on unpaid leave appears at full pay.

None of these files is wrong on its own. The trouble is the seams between them, because every seam is a person copying numbers by hand under a deadline.

This article argues that attendance, leave, payroll and accounting should share one record of the employee, and that the cost of keeping them apart is paid in errors, late nights and exposed salary data. It walks through where the cost comes from, what a joined-up flow looks like, a worked month with real arithmetic, and how to move there without a big-bang switch.

What goes wrong when people data lives apart from operations

Separate tools rarely fail loudly. They fail as small, believable discrepancies that someone has to chase every month.

• Retyped numbers. Hours leave one system as a CSV and enter another through a spreadsheet. Each hop is a chance for a shifted column or an outdated file.
• Stale rules. A pay change approved on the 10th reaches the payroll sheet on the 28th, so an employee is underpaid and a correction follows next month.
• Commissions argued from screenshots. Sales live in the order and POS data, but commission is calculated somewhere else from an export nobody can reproduce.
• Costs without a home. A salary total is booked as one lump, so no one can say what each outlet or department really costs to staff.
• A journal typed by hand. The accountant rebuilds the payroll result in the ledger, and a transposed digit is found weeks later during reconciliation.
• Salaries in too many inboxes. Every export and spreadsheet copy is another place where pay data can leak.

Published payroll error rates vary widely by source and method, so this article quotes none. The pattern matters more than the percentage: errors cluster at the hand-offs.

Why it happens: the same fact is stored in four places

An employee's pay depends on facts that originate in different departments. Hours come from the shop floor. Leave comes from the manager's approval. Sales come from the tills. Pay terms come from HR. The ledger needs the total, split by account and cost centre.

When each fact lives in its own tool, the payroll run has to collect them, and collecting means exporting. The mechanism behind most payroll errors is therefore not arithmetic. It is stale or duplicated input: the figure used in the run is a copy, and the original changed afterwards.

What an integrated flow looks like

In a joined-up system the employee record is the spine. Every other module reads from it and writes back to it, and nothing is copied.

1. Employee record. Pay terms, outlet, manager, bank account and overtime rules sit in one place with a history of changes.
2. Attendance and shifts. Punches or timesheets are matched to the rostered shift, and the difference becomes regular hours, overtime or absence.
3. Leave. A request is approved by the manager, carries its type (paid or unpaid) and updates the balance. Approved unpaid days flow into the run on their own.
4. Sales. Orders and counter sales are already attributed to a person or outlet, so commission is a query over real transactions.
5. Payroll run. Rules are applied to the locked inputs, producing earnings, deductions and net pay per person.
6. Approval, payslips, journal, bank file. One approval releases all three outputs.

The main rule is that the run reads locked data. Attendance and leave have a cut-off date, after which edits need a reason and leave a trace. That single rule removes most of the "which file is current" arguments.

A worked month: one employee, one journal entry

The numbers below are an illustrative example. Rates and percentages are invented, and your local tax and social security rules decide the real ones.

An outlet sales associate has a base salary of 3,000.00 a month. The company counts 160 contracted hours and 25 working days in the month. In July the associate worked 10 overtime hours, took 2 days of unpaid leave and sold 40,000.00 of goods at the counter, which earns a 2% commission.

Line	Calculation	Amount
Base salary	Contract	3,000.00
Overtime	10 h × (3,000 ÷ 160 = 18.75) × 1.5	+281.25
Commission	2% × 40,000.00 in sales	+800.00
Unpaid leave	2 days × (3,000 ÷ 25 = 120.00)	-240.00
Gross pay	3,000.00 + 281.25 + 800.00 - 240.00	3,841.25
Income tax withheld	Illustrative 10% of gross	-384.13
Employee contribution	Illustrative 5% of gross	-192.06
Net pay	3,841.25 - 384.13 - 192.06	3,265.06
Employer contribution	Illustrative 8% of gross	307.30

The company's total cost for this person is 3,841.25 plus 307.30, which is 4,148.55. When the run is approved, the system writes one journal entry. The expense is split across accounts and tagged with the associate's outlet as cost centre:

Account	Debit	Credit
Salaries expense, basic (3,000.00 - 240.00)	2,760.00
Salaries expense, overtime	281.25
Salaries expense, commission	800.00
Employer contribution expense	307.30
Salaries payable (net pay)		3,265.06
Income tax withheld payable		384.13
Employee contributions payable		192.06
Employer contributions payable		307.30
Total	4,148.55	4,148.55

The debits and credits match, and no one typed them. Paying the bank file later is a second, smaller entry: debit salaries payable, credit bank, 3,265.06 for this person. The tax and contribution liabilities stay open until they are remitted, so the ledger always shows what the company still owes.

The run as a flowchart

A good run is not a button that always produces a result. It is a sequence of checks that refuse to continue when an input is not ready.

Two points deserve attention. First, the exceptions list is the review. Reviewers should not read 140 payslips; they should read the dozen that changed by more than a set percentage, include a new joiner or leaver, or carry a manual adjustment. Second, release is one action. If payslips go out before the journal posts, the books and the people disagree from day one.

Approvals, timing and who signs

Segregation of duties is the oldest control in payroll: the person who changes pay terms should not be the person who approves the run, and neither should be the person who releases the payment. In a connected system this is a permission setting, not a policy document.

Corrections found after approval should not reopen the run. They become adjustment lines in the next month, with a reason and an approver. That keeps every released run reproducible and every payslip final.

Salary data needs access control, not trust

Pay data is among the most sensitive records a business holds. Integration makes this easier to protect, because there are fewer copies, but only if access follows the role.

• Staff see their own payslips, attendance and leave, and nothing else. Self-service pages must filter by the signed-in person on the server, never by an identifier sent from the browser.
• Managers see their team's hours and leave requests, not salaries, unless their role needs them.
• Finance sees run totals and journals. Only a small payroll role sees individual pay lines.
• Exports are permissioned and logged, and bank files are generated on demand rather than kept in shared folders.

Test this deliberately. Sign in as an ordinary employee, change the identifier in the address bar to a colleague's, and confirm the system refuses. A self-service screen that returns someone else's payslip is a data breach, even if it was built to be helpful.

What each module should feed

Module	Feeds the payroll run with	Receives back
Employee record	Pay terms, outlet, bank details, overtime rules	Pay history
Attendance and shifts	Regular, overtime and absent hours	Lock status
Leave	Paid and unpaid days, balances	Leave taken and balance
Sales and POS	Sales per person or outlet for commission	Commission paid
Accounting	Account mapping and cost centres	Posted journal, remittance status
Banking	Payment file format	Paid or failed per person

How to get there without a big-bang switch

You do not need to migrate everything in one month. A sequence that works for most growing businesses:

1. Clean the employee master. One record per person, with outlet, manager and a correct pay structure.
2. Move attendance and leave first. They have the most daily volume and the clearest cut-off dates.
3. Map payroll components to ledger accounts and cost centres before the first run.
4. Run in parallel for one month. Compare net pay per person against the old process and explain every difference.
5. Turn on approvals and roles, then retire the spreadsheet.
6. Add commission from sales data once the base run is stable.

When you evaluate software for this, check that attendance, leave and the payroll journal live in one product with one employee record. StoreConsole's payroll module follows that model, and the short tour below shows one run from start to payslips.

What to measure

Metric	How to calculate	Direction
Payslip corrections	Adjustments next month ÷ payslips issued	Falling toward zero
Close time	Working days from cut-off to payment	Shorter and predictable
Manual journal lines	Payroll lines typed by hand each month	Zero
Late timesheets	Records changed after the lock ÷ all records	Falling
Cost per outlet	Payroll cost by cost centre ÷ outlet sales	Visible for every outlet

Set your own baseline in the first parallel month. The point is that each number comes out of the system, not out of someone's reconstruction.

Back to the 29th

Return to the finance manager. In the joined-up version, attendance locked on the 24th and leave closed on the 25th. The calculation on the 26th listed eleven exceptions, including the two outlets with overtime, and HR cleared them on the 27th. The employee on unpaid leave was never at full pay, because the approved leave fed the run directly.

On the 29th she approves one run. Payslips go out, the journal posts with outlet cost centres, and the bank file is ready. Her evening goes to reading the exceptions that changed since last month, which is the part of the job that needs judgment.

Key takeaways

• Payroll errors cluster at hand-offs, where hours, leave and sales are copied between tools.
• Keep one employee record and let attendance, leave, sales and accounting read from it.
• Lock attendance and leave before the run, and handle later corrections as next-month adjustments.
• Release payslips, journal and bank file in one approved action, with separate people for changing terms, approving and paying.
• Filter salary data by role on the server, and test self-service pages by trying to read a colleague's payslip.
• Run in parallel for one month before retiring the spreadsheet.

Anichur Rahaman is a software architect and the creator of StoreConsole. He designs commerce and ERP systems for growing businesses, with a focus on event-driven architecture, data integrity and self-hosted operations.