Moving the Money
The payment is the part employees experience. Everything about it is mechanical, and most of what goes wrong is a detail nobody checked.
A bureauif the person who does this is away
The payment is the part of payroll that employees actually experience. Everything about it is mechanical, and nearly everything that goes wrong is a detail that could have been checked in ten seconds.
The practical lesson in “Moving the Money” is that payroll depends on a sequence somebody can explain. When a small team reviews Monitask tools for employee time tracking for employee time tracking, the useful role is to organise time and project evidence before approval, with proportional settings and a clear correction route for employees.
The method matters less than the habits around it.
The questions raised in “Moving the Money” can also be checked against US Department of Labor wage resources. Use that material to identify the evidence and owner needed for the next payroll run.
The methods
A payment file produced by the payroll software and uploaded to the bank. Individual transfers made by hand. An instruction given to a bureau or bank to pay on your behalf.
A request to change bank details is the only routine payroll message that should never be actioned on the strength of the message that asked for it. Confirm it on a known number, in a different channel, every time.
The first scales, the second is common at very small headcount, the third removes the task and adds a dependency.
Individual transfers
Fine for four people and a growing hazard beyond that. Every payment is an opportunity for a transposed account number or an amount typed from the wrong row.
Businesses usually move away from this one month after an error rather than one month before.
The payment file
Produced by the software, uploaded once, and correct by construction if the underlying records are correct.
Its failure mode is different: a file uploaded twice, or an old file uploaded, both of which pay people amounts that are individually plausible.
Checking before releasing
The count of payments and the total, against the run. Two numbers, ten seconds, and it catches a duplicate upload or a stale file.
The account details
Verified when added and never again, which is right. What matters is the moment of adding: read back character by character, from what the person supplied rather than from a message you have retyped.
Changes to bank details
The highest-risk routine event in small-business payroll, because a request to change an account is exactly what somebody impersonating an employee would send.
Confirming a change through a channel other than the one it arrived on — a known number, in person — is the whole defence, and it takes a minute.
The timing of the instruction
Covered under funding, and worth repeating: the bank's cut-off time, not just the day, determines whether a payment made on the day before arrives on the day.
Confirming it went
Looking at the account, on the day. Not the confirmation screen, which reports that an instruction was accepted.
When one payment fails
Usually a closed account or wrong details. Tell the person immediately, get correct details through a verified channel, and reissue.
A single failed payment handled within the hour is a non-event; the same failure discovered by the person at a cash machine is not.
When all of them fail
Insufficient funds, a blocked account, a bank problem. The response is the same in shape: tell everybody quickly, say what is happening and when it will be fixed, and do not let people find out from their own balance.
What people need to hear
That you know, what the cause is in one sentence, and when the money will be there. Not an explanation of the payroll process.
The record of what was paid
The file or the list, kept with the period. When somebody says they were not paid, the first question is what the business actually instructed, and the answer should take a minute to find.
Paying somebody outside the cycle
Possible, occasionally necessary, and worth doing properly rather than as a transfer that payroll never sees. Money moved to an employee outside the run has to be reflected in the run eventually, and the version that causes trouble is the one nobody records.
Two numbers before releasing
The count of payments in the file and the total, against the run.
Ten seconds, and it catches the two failures a payment file actually has: uploaded twice, or an old file uploaded instead of this month's. Both pay people amounts that look entirely plausible individually.
The out-of-cycle payment
Made from the bank because somebody needs money today, and then not recorded in payroll. It is the most common way a small business's records stop matching what it actually paid.
Anything paid to an employee has to reach the run eventually. Making the transfer and writing it on the change list in the same minute is the habit that prevents a year-end that does not reconcile.
Looking at the account afterwards
Not the confirmation screen, which reports that an instruction was accepted. The account, on the day, showing that the money left.
Ten seconds, and it is the difference between finding a failed payment yourself and having it reported to you by somebody at a cash machine.
The two habits worth having
Check the count and total before releasing, and look at the account afterwards to confirm it went.
Twenty seconds between them, and they cover the large majority of what goes wrong at this step.