When a small business shops for payroll software, the comparison runs on three things. Price per employee per month. Whether it files the taxes and handles the year-end forms. Whether it has a mobile app. Those are reasonable questions, and every serious product answers them well, which is why they do not help you choose.
The errors that cost small businesses money in payroll almost never come from a wrong tax calculation. They come from what goes into the pay run: an hour that was approved after the cutoff, a raise that was entered a week late, a deduction that nobody turned off. The software calculated correctly on the inputs it was given, and the inputs were wrong.
A pay run is a calculation with a deadline. Before the deadline, a set of facts is collected: hours worked, leave taken, rates, bonuses, deductions, new starters and leavers. After the deadline the run happens, and money moves. Everything that matters happens in the gap between "a fact is true" and "the fact is in the run".
A person works eight overtime hours on the last day of the period. The manager approves the timesheet on Monday. The pay run closed on Friday. The hours are not in the run, and the employee is short. Next period the correction is made by hand, as an extra line, and the ledger now has a payment that does not match any period's hours.
A raise takes effect on the first of the month and is entered on the tenth. The run on the fifteenth pays the new rate for the half-month, and nobody remembers the back pay from the first to the fifteenth, until the employee asks.
A leaver is removed from the system after the run. The next run includes them, or the final pay was calculated from stale data.
None of these is exotic. Each is the same problem: a change that arrives after the cutoff, in a process where the rule for late changes is a habit rather than a design.
It helps to see payroll as three inbound feeds and one outbound.
Hours in. From timesheets, a clock, a schedule or a manager's email. The questions: who enters them, who approves them, by when, and what happens to hours approved after the cutoff?
Rate changes in. Raises, new hires, role changes, bonuses. The questions: where is the effective date recorded, does the software back-calculate for a change that is entered late, and who is told when it does?
Deductions in. Benefits, garnishments, loans, expense reimbursements. The questions: when a deduction ends, what turns it off, and what reminds anyone?
The ledger out. After the run, the totals go to the accounting system. The question is whether the entries are by employee, by cost centre, by liability type, and whether anyone reconciles the accrual for unpaid hours at the period end. We covered the mismatch that accumulates when no one does in payroll reconciliation.
You can ask these of any product, in any order, and the answers will tell you more than the feature grid.
1. What is the default cutoff for hours, and who can change it?
2. If an approved hour arrives after the cutoff, what does the system do: add it to the next run, create an off-cycle payment, or refuse?
3. Can a rate change carry an effective date in the past, and does it calculate the back pay?
4. Is there a report of changes made after the cutoff for each run?
5. Who is warned when a deduction reaches its end date?
6. How does a new starter appear in the run, and from where does the system learn about them?
7. How is a leaver's final pay handled, and what stops them appearing in the next run?
8. Can managers approve time from their phones, and what happens if they do not?
9. What does the accounting entry look like, and can it be split by cost centre?
10. Who in your business owns the checklist that runs before each pay run?
The last question is not for the vendor. It is for you, and it is the one that most determines whether the software will work.
The vendor cannot supply this one, because it belongs to your business. It is a short page, run two working days before the pay date by one named person, with a second named person covering absence.
It asks six things. Are all timesheets for the period submitted, and which are not approved? Which rate changes, starters and leavers have been entered since the last run, and are their dates right? Which deductions are due to end? Which hours were approved after the last cutoff and handled by an adjustment? What does the preview total look like against the last run, and is any difference explained by a known change? And who signs the run off?
None of these takes long. Together they catch most of the errors the software could never see, because they are about the facts it was fed. A firm that runs the page for three months usually finds that the same two or three items are always late, and the fix is a rule about who enters what by when.
Take a company of sixty paying twice a month. Two managers approve timesheets in bulk on the Monday after a period closes, and the run is on the Friday before. Every period, four or five people have overtime approved after the cutoff. Nobody designed this; it is how the managers' weeks fall.
The software has an off-cycle payment feature, so each period an administrator pays the shortfall by hand, and the ledger shows an extra line for each. After a quarter, the accounting team cannot reconcile hours to pay without a separate sheet. The fix is not a better product. It is moving the approval deadline to Thursday, giving the managers a reminder on Wednesday and a rule that late approvals roll to the next run by default. The off-cycle payments stop, and the sheet becomes unnecessary.
A pay error is more expensive than its amount. An employee paid short loses trust, and someone spends an afternoon correcting it. An employee paid over has to be asked to pay it back. Both leave a trail in the ledger. A business that hits two or three such cases in a quarter starts adding manual checks, and the time saved by the software goes back into the checking.
The feeds come from systems a growing company already runs: the hiring tool tells payroll about a new starter, the time tool supplies the hours, the people record holds rates and dates. The weaker those joins are, the more the pay run depends on someone retyping. We looked at the first of them in HRIS for a small business: the trigger for moving off a spreadsheet is the number of handoffs, not the headcount. Payroll is where the handoffs end up costing money.
We connect the hiring, time and people records to payroll so the three feeds are one set of facts with owners, cutoffs and a change report. Discovery is no-risk: we trace the last three pay runs back to their inputs, count the late changes and show where they came from, and you pay only if you go ahead. The build carries a guaranteed estimate, so if we estimate low, we absorb the difference.
The software calculates what it is given. Choose the one that makes it hardest to give it the wrong thing.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
