How to automate payroll processing without automating the approval

To automate payroll processing, let software assemble the inputs and run the checks, and keep a person on approval and submission. Assembly and checking take most of the hours and need no judgement. Approval means one person accepts responsibility for the numbers, and that step stays human.

The deadline is fixed, errors land on individual people, and every affected employee sees a mistake on the same day. Getting the line between automated and human steps in the right place is the whole design.

What we'll cover

• What makes payroll different
• Assembly, which is most of the work
• The checks worth running every cycle
• Building it with CodeWords
• The approval that must stay human
• Reconciliation, before anything else
• Joiners, leavers, and changes
• Who can see the pack
• Making payroll automation reliable
• Limits of payroll automation
• What to build first
• Frequently asked questions

Key takeaways

• Automate payroll assembly and checking, because they are mechanical and are where transcription errors enter.
• Keep approval and submission with a named person, because the gap between "prepared" and "submitted" is where every error is still free to fix.
• Run a per-person variance check against the last cycle before approval, with a total variance check beside it.
• Reconcile what was paid against what was approved on the same day.
• Send the pack only to the named approver, never to a channel.

What makes payroll different

Payroll differs from most back-office automation in six ways, and each one pushes the design toward caution.

The deadline does not move. A pipeline that can be rerun tomorrow is fine for reporting and not for a pay run.

Errors are personal. An underpayment affects somebody's rent, which is a different category of consequence from a wrong dashboard.

Payroll is regulated. Filing obligations, deadlines, and record-keeping requirements vary by jurisdiction and change.

Payroll is visible. Everyone affected sees the result on the same day, so a systematic error is discovered publicly.

Corrections are costly in process, in trust, and sometimes in filings that have to be amended.

The design principle is conservative: automate what is checkable, make every step reversible before submission, and put a person in front of the irreversible one.

Assembly, which is most of the work

Assembly is the gathering of inputs: it takes most of the hours, needs almost no judgement, and is where manual transcription errors enter. Automate it first.

Hours and timesheets come from wherever they are recorded, validated against expected ranges.

Absence (holiday, sickness, parental leave) comes from the system that holds it, not from an email.

Variable pay (commission, bonuses, overtime) comes from the systems that calculate it, with the calculation shown rather than a total pasted in.

Changes since last cycle (new starters, leavers, salary changes, role changes) are gathered as a list rather than remembered.

Deductions and benefits that vary are collected from their sources.

The checks worth running every cycle

The highest-value payroll automation is a set of read-only checks that run before approval. Each check names a specific error and flags it before the money moves.

Variance against last cycle, per person. Flag anybody whose pay changed by more than a threshold, with the reason if it is known. This check targets the most common errors.

Total variance. This catches systematic problems that per-person variance spreads too thin to show.

Headcount reconciliation against your HR system: anybody being paid who left, anybody who joined and is missing.

Zero and negative values, which are almost always wrong.

Duplicate payments to the same person or the same bank details.

Bank detail changes since last cycle, flagged prominently. A changed bank detail is both an error risk and the usual shape of payroll fraud.

Statutory minimums, where the calculation is derivable, because an underpayment there is a compliance matter.

Building it with CodeWords

CodeWords connects to 3,000+ integrations (CodeWords pricing page, 2026), so assembly and checking can run across the HR system, the time tracker, and the payroll provider without anybody retyping.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which sources, what to assemble, and which checks to run.
3. Authorize the connections, with read-only access wherever the automation only gathers.
4. Describe the exceptions: a variance above a threshold, a missing timesheet, a leaver still present, changed bank details.
5. Run the automation in parallel with the manual process for at least two cycles and compare the outputs before relying on it.

You describe the outcome; Cody builds it, connects it, and deploys it. The Free plan costs $0, Pro costs $39 per month, and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

The approval that must stay human

Approval stays human because somebody must accept responsibility for the numbers. Give that person what they need to approve properly, and never let the automation submit.

Give the approver the evidence: the totals, the variances with explanations, the exceptions, and the changes since last cycle, rather than a figure and a button.

Make the exceptions the focus. A reviewer reading forty flagged items reviews them; a reviewer reading four hundred rows reviews none.

Record who approved and when. Most payroll processes require this record.

Require a second approver above a threshold, and for anything involving changed bank details.

Never let the automation submit. The gap between "prepared" and "submitted" is where every error is still recoverable, and removing it removes the only safety net the process has.

Reconciliation, before anything else

Reconciliation compares what was paid against what was approved, and it should run on the same day as payment. Most teams add it last, but a discrepancy found on the day is recoverable and one found at month end is an investigation.

Compare what was paid against what was approved. A difference means something happened between the two steps, and you want to know immediately.

Compare the bank total against the payroll total. This catches a payment that failed or duplicated.

Compare against the general ledger once posted, so finance and payroll agree before anybody asks.

Report differences rather than resolving them. An automated correction in payroll is the wrong response.

Keep the history. Cycle-on-cycle reconciliation records make an audit straightforward.

Joiners, leavers, and changes

Joiners, leavers, and mid-cycle changes produce the most payroll errors, because each depends on one person telling another. Pull the changes from the source system and compare them against payroll every cycle.

A leaver still on payroll is the classic error. Reconciling headcount against the HR system every cycle catches it.

A missing joiner is discovered when the person is not paid, which is the worst way to detect an error.

Mid-cycle changes, such as a salary change effective partway through, are where manual calculation errors concentrate.

Report anything that changed without a corresponding record in the source system.

Flag the effective date. A change applied to the wrong cycle is an overpayment and an underpayment in sequence.

Report the list of changes to the approver as part of the pack, because that list is what the approver is approving.

Who can see the pack

Only the named approver should see the payroll pack, because the pack holds everyone's salary in one place. Access matters more here than in most automation.

Scope the automation's own access to read-only on the sources, and write nowhere it does not need to write.

Treat the assembled pack as the most sensitive file your finance process produces. Teams often email it, which spreads it.

Do not send the pack to a channel. Approval belongs in a direct exchange with the named approver, not in a place whose membership list grows.

Redact in the exception report where you can. A variance report can name the change without restating the salary.

Keep the archive access-controlled, and set a retention period that matches your obligations rather than keeping every cycle indefinitely.

Log who read the pack. Knowing who opened it costs little to record.

Making payroll automation reliable

A reliable payroll automation is read-only where possible, safe to rerun, and loud when a source is missing.

Read-only wherever possible. Assembly and checking need no write access to anything.

Make it idempotent (safe to run twice), so a rerun produces the same pack rather than duplicating anything.

Fail loudly on a missing source. A pack assembled without the timesheet system is not a pack, and the automation should not produce it.

Keep each run timestamped and archived, with the inputs, because reconstructing a cycle later is otherwise impossible.

Report the outcome: sources gathered, checks run, exceptions raised, and anything that could not be retrieved.

Limits of payroll automation

Payroll automation has five limits. Check each one before you commit to an end-to-end design.

Payroll rules vary by jurisdiction and change, often with little notice. Leave calculation to a provider that maintains the rules.

Your provider's API may not cover everything its interface does, which constrains what can be automated end to end.

Timing windows are tight. Submission deadlines mean a failed automation has hours, not days, of slack.

Personal and financial data flows through the automation, so access scoping and logging matter more here than in most other automation.

This article is not advice on your obligations. What you must file, retain, and check depends on your country and employment type, so ask whoever advises you.

What to build first

Build the variance report first: every person whose pay changed by more than a threshold since last cycle, with the reason where it is derivable, produced before the approval rather than after the payment. The report is read-only, takes little building, and flags errors at the one moment they are still free to fix.

Two habits make the difference. Include the total variance alongside the per-person list, because a systematic error spreads too thin to trip an individual threshold. And flag changed bank details separately and prominently, because that single check covers both an ordinary error and the most common payroll fraud.

Frequently asked questions

What part of payroll should stay manual?

Approval and submission should stay manual. A named person accepts responsibility for the numbers. The gap between prepared and submitted is where every error is still recoverable, so removing that gap removes the process's only safety net. Automate assembly and checking, which are mechanical.

What is the single most valuable check?

The most valuable check is per-person variance against last cycle, above a threshold, with the reason where derivable. The check is read-only, runs before the money moves, and targets the most common payroll errors, such as a wrong rate or a leaver still being paid.

Why check total variance as well?

Total variance catches systematic errors. A wrong rate applied broadly, or a deduction missed for everybody, spreads too thin to trip an individual threshold, yet it is obvious in the total. Running both checks together covers individual mistakes and company-wide ones before approval.

How do leavers stay on payroll?

Leavers stay on payroll because the change depends on somebody telling somebody. Reconcile headcount against the HR system every cycle instead of relying on a notification, and report anyone present in one system and absent from the other. The check takes seconds to run.

Should the automation submit the pay run?

No, the automation should not submit the pay run. Prepare it, check it, present the exceptions, and let a person submit. Automating the irreversible step removes the last point at which a mistake costs nothing to fix, and it removes the approver's accountability.

When should reconciliation run?

Reconciliation should run the same day as payment. A discrepancy between what was approved and what was paid is recoverable on the day and becomes an investigation at month end. The automation should report differences to a person rather than correcting them itself.

Does this cover our legal obligations?

No, this article does not cover your legal obligations. Filing, retention, and calculation requirements vary by jurisdiction and employment type, and they change. Ask whoever advises you, and leave calculation to a payroll provider that maintains the rules for your country.

Where should the approval pack go?

The approval pack should go directly to the named approver, never to a channel. The pack is the most sensitive file your finance process produces, and channel membership grows over time in a way nobody reviews. A direct message or email limits who can read it.

What access should the automation have?

The automation should have read-only access to the sources and write access only where strictly needed. Assembly and checking require no write access at all, so you can scope the permissions tightly. Narrow access limits the damage if a credential leaks or the automation misbehaves.

Related reading

• QuickBooks and CodeWords
• Connecting Xero to Google Sheets
• Business process automation