The Payroll Process : A Runbook From Cutoff to Filing

The Fabric Team
August 6, 2026
25 min read

The Payroll Process: A Step-by-Step Runbook From Timesheet Cutoff to Tax Filing

The payroll process is the repeating operational cycle that turns one period of work into a correct payment, a set of filings, and a retained record. It begins when the pay period closes and time data stops changing. It ends when the money has cleared, the tax deposits have been made, and the run has been archived. Most published guides to processing payroll present the cycle as a list of steps that finishes at "pay your employees," and give the second half, where the money actually moves and where errors get caught, a single line.

This is a runbook for the run itself. It covers the order of operations, the timing constraints, the payroll register and the reconciliations performed against it, the approval gate, and the filing obligations that close the cycle out. For pay philosophy, salary bands, and how compensation design feeds payroll, the compensation and payroll guide covers that ground. For tooling and employee self-service, see payroll automation and self-service.

One framing note before the steps. Every step below exists because of a specific failure it prevents, so the useful question about any step is which error it catches.

Table of contents

What the payroll process actually is

The payroll process is the end-to-end sequence an employer repeats every pay period to pay people correctly and prove it afterwards. It behaves like a cycle, not a one-off task. Each iteration takes two inputs, time and attendance data for the period plus any changes to employee records, and produces four outputs: net payments to employees, remittances to third parties, filings and deposits to tax authorities, and a retained record of the whole thing.

Payroll processing is the common name for the calculation stage inside that cycle, so the two terms often get used interchangeably. The distinction worth keeping is scope. Calculation is one step. The process is the ordered set of steps around it, including the controls that decide whether a calculation is allowed to become a payment.

The cycle is also fixed in time. Every stage of it sits on a published calendar, and the whole run is squeezed into the gap between the first date on that calendar and the last.

Full cycle payroll processing, defined

Full cycle payroll processing is the term used when one person or one team owns the entire loop for a pay period instead of a single stage of it. The loop has eight stages:

  • Time capture
  • Gross to net calculation
  • Register review
  • Approval
  • Funding
  • Disbursement
  • Filing and deposits
  • Record retention

The phrase turns up mostly in job descriptions, where it separates an end-to-end payroll role from a data entry one. It is useful as a scope definition: if you cannot name who owns each of those eight stages for your own runs, the unowned ones are where errors tend to survive.

The payroll process step by step

The payroll process runs in nine steps, and the order is not negotiable. Time data closes first, because every downstream calculation depends on a stable input. Employee record changes are applied next, because a raise or a termination applied after calculation forces a rerun. Calculation follows. The payroll register is then produced and reviewed, which is the last cheap moment to find a problem. Approval comes after review and before money moves, which is the whole point of having an approval. Funding, disbursement, filing, and retention close the cycle out.

Read the sequence as a set of gates, not a checklist. Each gate sits where the cost of an error jumps: before calculation, before payment, and before filing. A wrong number caught at the register costs an edit. The same number caught after disbursement costs a recovery conversation with an employee. Caught after filing, it costs an amended return.

Here is the sequence with the specific error each step is designed to catch.

Step What it produces The error it is there to catch
1. Timesheet cutoff A frozen set of hours, absences, and overtime for the period Late or edited time data changing a number that has already been calculated
2. Manager approval of time Attested hours with a named approver Unworked or unauthorised overtime entering the run unchallenged
3. Master data changes Joiners, leavers, rate changes, and deduction changes with effective dates Paying a leaver, missing a joiner, or applying a raise to the wrong period
4. Gross to net calculation Gross pay, statutory and voluntary deductions, employer costs, net pay Stale tax tables, wrong deduction codes, missed caps and thresholds
5. Payroll register review A line-by-line record of the run plus reconciliations against it Any of the above, while it is still cheap to fix
6. Approval to pay A dated sign-off by someone who did not prepare the run A single person creating and releasing a payment without a second pair of eyes
7. Funding and disbursement Net pay to employees, remittances to third parties Insufficient funds, a missed bank deadline, a failed or misdirected payment
8. Filing and deposits Tax deposits and statutory reports on their due dates Late deposits and late or missing returns, both of which carry penalties
9. Posting and retention General ledger entries and an archived run An unreconstructable run when an auditor, a regulator, or an employee asks

If you came looking for a payroll process flowchart, that table is the same thing written as a control sequence instead of a diagram.

Cutoff and change control: the two inputs

A pay run has exactly two inputs, and both of them need a hard boundary. The first is time and attendance data for the period. The second is changes to employee records, which payroll people usually call master data. Everything the run produces is a function of those two inputs, so a run is only as trustworthy as the moment you freeze them.

The timesheet cutoff is the freeze on input one. After cutoff, hours for that period stop being editable, and anything that arrives late goes into the next run or an off-cycle payment. Cutoff exists because a single retroactive edit invalidates a calculation that has already been reviewed.

Change control is the freeze on input two. Joiners, leavers, rate changes, and deduction changes all need an effective date and a submission deadline against the same calendar.

How to enforce a timesheet cutoff

A published cutoff only does work when it is enforced. The common failure is a manager submitting time two days late and payroll accepting it as a favour, which pushes the review window into the funding window and removes the slack the calendar was built with.

Keep the exception path explicit instead. Late time goes into the next period, or into an off-cycle run with its own approval. The exception then stays visible and counted, instead of being absorbed silently by the payroll team.

Change control, and the classic effective-date error

Master data changes generate retroactive corrections whenever the date a change is entered drifts away from the date it takes effect. A raise agreed in a meeting on the 3rd, entered on the 20th, and effective from the 1st produces an underpayment for the current period and a retro adjustment in the next one.

Route every change through one queue with an effective date attached, and reconcile that queue against the register before approval. Time and attendance tracking covers the upstream side of input one in more detail.

Gross to net: calculating the run

Gross to net is the calculation stage: start from what each person earned for the period, apply everything that comes out, and arrive at the amount the bank will actually send. Gross pay is the total before deductions, and net pay is what lands in the account. The route between them runs through statutory deductions, voluntary deductions, and, in parallel, employer-side costs that never appear in the employee's net figure but do have to be funded and reported.

The sequence inside this step matters as much as the arithmetic, because many deductions are calculated on a base that earlier deductions have already changed, and many are capped. Run them in the wrong order and the totals still look plausible, which is precisely what makes the error hard to spot later.

Four groups make up the calculation:

  • Earnings. Base pay for the period, overtime, shift premiums, commission, bonuses, and any allowances or reimbursements being paid through payroll.
  • Statutory deductions. Income tax withholding and social insurance or retirement contributions, calculated to the rules of the relevant jurisdiction.
  • Voluntary and court-ordered deductions. Benefit contributions, retirement plan contributions, loan repayments, and wage garnishments, which follow the withholding limits and ordering rules attached to the order that created them.
  • Employer-side costs. Employer contributions and payroll taxes that the business owes on top of gross pay.

If the difference between the first and the last of those is still fuzzy, the gross to net calculation is worth walking through on its own before you review a register full of it.

What a payroll register is, and why it is the control document

A payroll register is the line-by-line record of a single pay run, showing every employee's earnings, every deduction, employer contributions, and net pay, with column totals for the run as a whole. Payroll systems generally produce one as a preview before the run is committed, then again as a final version afterwards.

Its real job is control. The register is the one artifact where a payroll run can be checked as a whole before any money moves. Every other view of a pay run is partial: a payslip shows one employee, a bank file shows only net amounts, and the general ledger shows only totals. The register shows the full grid, so it is the only place where an error in one person's record and an error in the run's totals are both visible at the same time.

That is why the register review sits immediately before approval. It is the last cheap moment in the cycle.

What a payroll register contains

The exact columns vary by system and country, but a register consistently carries the same shape:

  • Employee identifier, name, and pay group
  • Hours or units for the period, split by earning type
  • Gross pay, broken out by earning code
  • Each statutory deduction as its own column
  • Each voluntary and court-ordered deduction as its own column
  • Net pay and the payment method
  • Employer contributions and employer taxes
  • Column totals for the entire run

The register also feeds record retention, though retention rules name required records rather than the register itself. Under the FLSA, US employers must preserve payroll records for at least three years and the records that wage computations are based on for two years, per the Department of Labor's recordkeeping fact sheet. Retention rules elsewhere differ, so check the requirement for each country you pay in.

The four reconciliations to run against the register

A register review works as a small number of comparisons that make anomalies surface on their own, which is faster and more reliable than reading the document top to bottom.

  1. Period over period variance. Compare this run against the last one, line by line, and investigate anything that moved more than a threshold you set in advance. Payroll is a repetitive number, so this comparison is where an unexplained change is easiest to see.
  2. Headcount roll-forward. Last run's employee count, plus joiners, minus leavers, should equal this run's count. A mismatch means someone was paid who should not have been, or someone was missed.
  3. Foot and cross-foot. Column totals should add to the run total, and for each employee gross minus total deductions should equal net. This catches broken deduction codes and mapping errors.
  4. Register to funding to ledger. Total net pay should equal the payment file, total statutory deductions should equal the amount being remitted, and the run should equal what posts to the general ledger.

Variance review is the one to invest in. Set a percentage threshold you can defend, apply it to every line, and require a written explanation for each flagged employee before the run goes to approval. Missing timesheets, duplicated bonuses, and leavers still on the file all surface as variances.

Register versus payslip versus journal

These three get conflated, and separating them makes the control easier to explain to a finance team.

  • The payroll register is the whole run, every employee, every column. It is the control document.
  • The payslip is one employee's slice of that register, formatted for the employee and often legally mandated in content.
  • The payroll journal is the accounting summary of the run, the entry that posts to the general ledger.

All three come from the same calculation. If they disagree, the disagreement is the finding.

Approval: who signs the run off

Approval is a named person accepting the run and authorising payment, recorded with a date. It is a separate step from review, and the separation is the control. Review asks whether the numbers are right. Approval asks whether this run is authorised to become money. Collapsing the two removes the only checkpoint standing between a preparation error and a payment.

The principle underneath is segregation of duties: the person who prepares a run should not be the only person who releases it. In a small team the releaser can be the finance lead or the business owner. What matters is that the releaser is not the preparer, and that the approval leaves a record.

Approval should be given against evidence, not a summary figure. A useful approval pack stays short and contains the register totals, the variance report with an explanation for every flagged line, the headcount roll-forward, and the funding amount. An approver who sees only a total cannot meaningfully approve anything.

Funding and disbursement: the point of no return

Funding is making sure the money is in the account before the payment file executes, and disbursement is the execution itself. This is the step where the cycle stops being reversible. Once net pay has reached employee accounts, correcting an overpayment turns into a conversation, a repayment agreement, and a question about what your local wage payment law lets you recover.

Treat the payment file as the boundary of the whole process. Everything before it is editable at the cost of a rerun. Everything after it is a correction with a person on the other end of it, which is why the register review and the approval both sit ahead of the file rather than behind it.

This step also carries more than one payment, on more than one deadline, and the amounts do not all come from the same column of the register.

Three things go out in this step, and only the first is the one most calendars plan for:

  • Net pay to employees, through the payment file your bank or provider executes.
  • Third-party remittances: garnishment payments to the issuing agency, benefit premiums to carriers, retirement contributions to the plan administrator.
  • Tax deposits, which are covered in the next section and run to their own deadlines.

Two operational details are worth pinning down in writing. The first is your bank's submission deadline, which sits earlier than the pay date by an amount that depends on payment method and provider, and which sets the true end of your review window. The second is the funding amount, which is larger than total net pay because employer contributions and remittances come out of the same account.

Off-cycle runs and corrections

Some payments cannot wait for the next scheduled run. A missed new joiner, a departure where local final pay rules fix an earlier date than your next run, or a correction to an underpayment will each usually justify an off-cycle run.

Off-cycle runs deserve the same gates as scheduled ones, in compressed form: a register, a variance check against what was intended, and an approval by someone other than the preparer. Skipping the gates because the run is small is how one correction creates a second. Back pay covers how underpayments are calculated once one is found.

Filing, deposits, and retention

Filing and depositing are where the payroll process stops being internal, and where jurisdiction stops being a footnote. Obligations differ by country, and inside the United States they differ by state on top of the federal rules. There is no universal payroll calendar, and any guide handing you one is describing a single country without saying so.

US federal employment tax deposits run on one of two schedules, set by a lookback period rather than by choice. The IRS states it plainly: employers who reported $50,000 or less of employment taxes during the lookback period are monthly schedule depositors, and employers who reported more than that are semiweekly schedule depositors. For Form 941 filers, the lookback period is the twelve months starting July 1 of the second preceding year and ending June 30 of the prior year.

State withholding, state unemployment insurance, and local taxes each run to their own registration and filing calendars, which is why multi-state employers keep an obligations register per jurisdiction.

US federal deposit schedule Who it applies to When the deposit is due
Monthly Employers reporting $50,000 or less in the lookback period Generally by the 15th day of the following month
Semiweekly Employers reporting more than $50,000 in the lookback period Wednesday, Thursday, or Friday paydays by the following Wednesday. Saturday, Sunday, Monday, or Tuesday paydays by the following Friday
Next-day rule Any employer accumulating $100,000 or more on any day in a deposit period By the next business day after the $100,000 threshold is reached

Source for all three rows: IRS Topic no. 757. These are US federal rules only. State and local obligations sit on top of them and are not derived from them.

Other countries run different cadences entirely

The US model reports periodically and deposits on a lookback-driven schedule. That model is not universal, and assuming it is will produce a late filing somewhere else.

In the United Kingdom, for example, employers operate PAYE in real time and must send a Full Payment Submission to HMRC on or before each payday, not after the period closes. If you pay people in more than one country, build a separate obligations calendar per country instead of extending the one you already know. For an example of how different a statutory regime looks, see provident fund, UAN, and global payroll compliance.

Two documents gate the calculation rather than the filing: the forms new hires complete before their first run. I-9 and W-4 requirements sit upstream of payroll in onboarding, and a missing W-4 changes how the first run withholds.

*This article is general operational guidance and not legal or tax advice. Payroll obligations differ by country, by state or province, and often by worker classification. Confirm the rules that apply to your workers with employment counsel or a qualified tax adviser in the relevant jurisdiction.*

Where the cycle usually breaks

The failures worth designing against are ordinary and repetitive. A late timesheet, a wrong effective date, a review performed as a glance, and a bank deadline that arrived earlier than someone assumed will each break a run, and none of them requires an unusual tax rule to do it.

That matters for where you spend attention. The calculation is the part of the payroll process a system repeats identically every cycle. The inputs and the timing are the parts people control, which is what makes them the volatile half.

So the gates in the sequence sit exactly where human input enters or where a deadline binds. Four points account for most of what goes wrong in practice, and each of them is a place where a person either supplies data or approves something on a deadline. Reviewing your last three runs against these four is usually enough to find your own pattern.

  • At cutoff. Late timesheets accepted as exceptions, which compresses every downstream window.
  • At master data. Effective dates entered wrong, or a change agreed verbally and never submitted, which produces retroactive corrections in the next cycle.
  • At the register. The review performed as a glance at the total rather than as variance analysis, which is how a duplicated bonus or a terminated employee reaches the bank.
  • At funding. The bank deadline treated as the pay date, or the funded amount set to net pay only, leaving remittances short.

A useful habit is to log every exception you granted during a run, then read the log at quarter end. A manager who is late every period, or a deduction that needs a manual fix every month, is a process defect, and a process defect can be fixed outside the pressure of a live pay run.

Where Fabric fits, and where it does not

Fabric is not a payroll system. It does not calculate pay, produce a payroll register, fund payments, or file taxes, and nothing in this post should be read as a description of what Fabric does.

The honest connection is upstream. Every new joiner who appears in a pay run started as a hire, so at bulk hiring volumes the number of joiners entering each cycle is set by how the hiring funnel is running rather than by anything payroll controls.

Fabric is an AI interview platform. Recruiters enter a job description, and Fabric's AI agents handle sourcing, outreach, resume screening, eligibility checks, scheduling, and AI-led Round 1 interviews, so the recruiter receives a shortlist. Fabric's eligibility screening is designed to flag candidates who fall outside parameters such as budget, location, and years of experience, and to surface that to your recruiter. It is a signal for your team to weigh, not an automatic reject.

*This article is for informational purposes only. Fabric's Interview Engine screens, scores, and records Round 1 interviews; it does not make the final hiring decision. The recruiter or hiring panel using Fabric remains responsible for all hiring decisions.*

Screening eats around 80% of time-to-hire
Payroll runs on a fixed calendar. Your hiring funnel does not have to be the reason joiners miss it.
Book a 30-minute walkthrough

Related Posts

FAQ

What are the steps to process payroll?

The sequence runs from timesheet cutoff to record retention: close the period, apply master data changes, calculate gross to net, review the payroll register, obtain approval, fund the account, disburse net pay and third-party remittances, file and deposit taxes, then archive the run. Each step exists to catch one specific error before the next step makes it expensive to fix.

What is full cycle payroll processing?

Full cycle payroll processing means owning the whole loop for a pay period instead of one stage of it, from time capture and gross to net calculation through register review, approval, funding, disbursement, filing, and record retention. The phrase is normally used to distinguish an end-to-end payroll role from a data entry one.

How long does it usually take for payroll to process?

There is no standard duration, because the gap is set by your own payroll calendar: the payment file has to reach the bank before the pay date, and the register review sits ahead of that. The lead time depends on your payment method, your bank, and your provider's submission deadline, so the number that matters is your own cutoff to pay date gap.

How can a beginner understand payroll?

Start with the sequence before the tax tables: learn what each step in the cycle produces and what error it is there to catch, then learn the calculations underneath. The payroll register is the fastest way in, because it shows every employee's gross pay, deductions, and net pay for one run on a single document.

What is a typical payroll cycle?

Weekly, biweekly, semi-monthly, and monthly cycles are all in normal use, and which one counts as typical depends on the country, the industry, and often the state or the worker classification. Because pay frequency can be prescribed locally, confirm the rule that applies to your workers before copying another employer's cycle.

Can employers delay payroll processing?

Internal processing steps can move inside your own calendar, but the pay date itself is the one your contracts and your local wage payment rules point at, so missing it becomes a wage payment problem instead of an operations problem. If one run is at risk, the usual answer is an off-cycle payment for the affected employees instead of moving the pay date for everyone.

Try Fabric for one of your job posts