The Payroll Calendar, With the Approval Gate on It

Payroll has a property that nothing else in a small company’s finance function has. It is irreversible, it is externally dated by somebody other than you, and getting it wrong is visible to every employee on the same afternoon. A wrong purchase invoice is corrected next week and nobody outside finance ever hears about it. A wrong payroll is a conversation with a person about their own money.

Given that, the way most companies at this size run it is remarkable. One person collects the inputs, one person enters them, one person checks them, and it is the same person, and the check happens after the file has been submitted, if it happens at all. The approval that exists on paper is usually a signature on a total, which is an approval of an arithmetic sum rather than of anything a person could be wrong about.

The fix is not more diligence from the person running it. It is a calendar with a gate on it, positioned so that the review happens while it is still cheap, which means before submission rather than after pay date. Everything below is built backwards from that single placement.

What this piece does not cover, and where those questions go

A boundary, stated at the front rather than in a footnote, because this is the article where a reader is most likely to want the other thing.

Nothing here addresses source deductions, remittance obligations, what has to be withheld, when it has to be sent, what a company’s remitting position is, or any requirement of employment standards legislation. Not because those are unimportant. They are more important than anything on this page, and they are answered correctly only against the facts of a specific company by somebody whose work that is.

Those questions belong to the accountant who prepares the company’s returns, and, where they concern termination, hours, entitlements or anything else in the employment relationship, to employment counsel. The tax side of payroll is written about at length elsewhere, at khaledhawari.ca, which is a separate practice answering a different question. It is deliberately not answered here.

What is on this page is the operating cycle: who supplies what, by when, who checks it, who approves it, and where it lands in the close. That is a finance operations problem and it is genuinely one of ours.

Build the calendar backwards from the provider’s cut-off

Every payroll calendar has exactly one fixed point that you do not control, and it is not the pay date. It is the moment your payroll provider or your bank needs the file in order for money to reach employees on the pay date.

Confirm that cut-off in writing, from the provider, including how it moves for statutory holidays and for the runs that fall near a long weekend. Do not take it from memory or from how it worked last year. Then everything else is placed relative to it, and the pay date itself becomes an output rather than an input.

Below, P is the pay date and negative numbers are business days before it. This is the shape for a company running a semi-monthly or bi-weekly cycle with a service provider. It compresses to about four days for a small salaried book with few variable inputs, and it stretches for a company with hourly staff, multiple locations or a commission cycle.

Day	Step	Owner	What has to exist at the end of it
P-8	The change window opens. The standing input request goes out naming every person who owes an input and what is due.	Coordinator	A dated request, with the cut-off time in it
P-7 to P-6	Variable inputs collected: hours, overtime, shift premiums, absence, statutory holiday treatment as your provider configures it, commissions and any approved bonus	Managers, into the coordinator	Each input approved by the manager who is accountable for it, not by finance
P-6	People changes assembled: joiners with their start dates, leavers with their last day, role or rate changes with effective dates, changes to deposit details	Whoever holds the employee record	A single people change list for the period, with supporting documents attached
P-5	Input cut-off. A hard time on a fixed day. Anything arriving after it goes into the next run.	Coordinator	The cut-off is enforced, in writing, including against the owner
P-4	The run is prepared and a preliminary register produced	Preparer	A register, unsubmitted
P-4	The review pack is generated from the preliminary register	Preparer	The seven items in the next section
P-3	Review performed against the pack. Queries raised and answered the same day.	Reviewer	Every exception either explained in writing or corrected
P-2	The approval gate. The approver signs the pack, not the total.	Approver	A dated approval naming the version approved
P-2 or P-1	Submission to the provider, at or before the confirmed cut-off	Preparer	Submission confirmation filed
P-1	Funding confirmed: the amount to be debited is in the account, and it agrees to the approved pack	Finance lead	A funding check performed before the debit rather than after
P	Pay date	Provider	Nothing to do, which is the objective
P+1	The final register is filed with the approved pack, the submission confirmation and the bank debit	Preparer	One folder per run, complete
P+1	Remittance dates arising from the run are confirmed against the schedule already agreed with the company’s accountant and carried in the cash forecast as fixed rows	Finance lead	No estimating, no working it out fresh each period
Close	The register is reconciled to the general ledger	Preparer, reviewed	Covered separately, in the payroll reconciliation

Two rows do most of the work. The cut-off at P-5, because a calendar with a soft cut-off is not a calendar. And the gate at P-2, because it is the last point at which an error costs nothing but an amended file.

The seven things the approver actually looks at

An approver handed a total can approve a payroll containing a duplicated employee, a rate entered at ten times its value and a departed employee still being paid, and the total will look entirely plausible. Give them the comparison instead. Every item below is a difference against the previous run, because differences are what a human can actually review.

1. Headcount, this run against last run, with joiners and leavers named individually. Not a count. Names. A leaver still on the register is the most common payroll error there is and it is invisible in a count that happens to net off against a joiner.
2. Gross pay by employee, with the variance against the last run, and every variance above a stated threshold explained in one line. The threshold is set once by the company. Explanations are written by the preparer before the review, not extracted during it.
3. Every change to deposit details since the last run, with the confirmation evidence attached. A deposit change confirmed only through the channel the request arrived on is not confirmed. This row belongs on the gate at any amount, with no threshold, for the same reason a supplier bank change does.
4. The off-cycle items, listed and individually approved. Bonuses, commissions, retroactive adjustments, vacation payouts, final pay. These are where the large errors live, because each is entered by hand and none of them has a previous run to be compared against.
5. Any employee with an unusually low or a nil net amount. Almost always an input error, occasionally something the employee needs to be told about before pay date rather than after.
6. Total gross, total employer cost and the total amount to be debited, against the last run and against the payroll line in the current forecast. The forecast comparison is the one that catches the error that is internally consistent and simply too big.
7. Confirmation that the register being approved is the version that will be submitted. A pack approved at P-2 and a file edited at P-1 is the most quietly dangerous sequence in the whole cycle.

Items 1 and 3 are the two to build first if the calendar has to be introduced gradually. They take minutes to produce, they need no system change, and between them they cover the two errors that cost real money.

The gate does not work if the approver prepared the run

This is the part that is hard in a company with three people in finance, and it is the part that cannot be traded away, because everything above is a review and a review performed by the person who did the work is a proofread.

Some workable splits at this size:

Situation	Preparer	Approver
A bookkeeper and an owner	Bookkeeper prepares	Owner approves the pack. This is the most common arrangement and it works, provided the owner reads the seven items rather than the total.
A finance lead and a bookkeeper	Bookkeeper prepares	Finance lead approves, and the owner approves anything on the off-cycle list
One person doing everything	The same person	A genuine problem. The compensating step is that the owner receives the seven items and the bank debit confirmation directly, every run, and the people change list comes from a source the preparer does not control.

The bottom row is a compensating control rather than a solution and it should be labelled that way in the company’s own documentation, because a control described as adequate when it is a mitigation is how a gap survives for years. The design of the underlying separation, including who is allowed to add an employee and who is allowed to release the payment, sits in the financial controls engagement rather than in the calendar.

When something is wrong, and where in the calendar you found it

The reason the gate sits at P-2 is that the cost of an error rises sharply and in steps, not smoothly.

Found	What it costs
Before the input cut-off	Nothing. It is an input correction.
Between cut-off and submission	An amended register and a re-approval. Inconvenient and entirely contained.
After submission, before the provider’s cut-off	Recall or replace the file, if the provider permits it. Contained, but now dependent on somebody else’s process.
After the provider’s cut-off, before pay date	Usually an off-cycle correction, and an explanation to at least one employee
After pay date	A conversation about somebody’s money, a correction that may not be within finance’s gift to make unilaterally, and a question for employment counsel where the correction reduces what an employee was paid

The last row is the reason for all of this. A payment made in error to an employee is not the same kind of problem as a payment made in error to a supplier, the difference is not a finance question, and a company that discovers it for the first time while trying to fix one is having the wrong conversation at the wrong moment.

The change window, and the one exception to it

The cut-off at P-5 holds against everyone, including the owner, and holding it against the owner the first time is what establishes it. Anything arriving late goes into the next run and is corrected there.

There is one category that cannot simply wait, and it is a termination. Final pay is time sensitive, what it must contain is a matter of employment standards and the employment agreement rather than of finance convenience, and the answer is not one for a payroll calendar to give. Build the exception in as a route rather than as a rule: a termination that arrives after cut-off goes immediately to the owner and to employment counsel, and finance executes whatever they determine. It is the only step in this cycle where the calendar defers to somebody else’s clock.

Where payroll lands in the close

Payroll is a dependency for the close rather than a task inside it. The final register for the period has to be available before accruals can be completed, which is why it appears as a dated hand-off in the close checklist rather than as a step somebody performs when they get to it.

Three items carry forward from the calendar into the close, and each of them should already exist rather than being assembled at close:

• The final register for every run in the period, with its approved pack.
• The employer cost, and the accruals that arise from the run rather than from the calendar: vacation, commission and bonus movement, taken from the plan rather than from recollection.
• Anything paid outside a run in the period, which by construction should be a short list and, if it is not, is the finding.

The reconciliation of the register to the ledger is a separate exercise with its own method, and it is the subject of the piece that follows this one.

Publish the year in advance

Publish the whole year’s calendar at the start of the year: every pay date, every input cut-off with its time, every approval date, and the runs that move because of a statutory holiday. Circulate it to managers rather than to finance, because managers are the ones who will otherwise ask for an exception.

A calendar published in advance turns every late input into a visible choice by a named person rather than into an argument about whether finance is being difficult. That is most of what the document achieves, and it costs a single afternoon once a year.

What we do not do

We do not advise on what must be withheld, on when a remittance is due, or on anything in employment standards, because those are answered by the company’s accountant and its employment counsel against facts we are not the right people to be interpreting. We do not approve a payroll from a total. We do not accept a deposit change confirmed through the same channel that requested it. And we do not move the input cut-off, because the cut-off is the only part of this calendar that anybody tests, and it is tested by asking.