How to automate payroll processing without automating the approval

Payroll has a shape that makes it unlike most back-office automation. The deadline is immovable, the consequences of an error land on individual people, and a mistake is visible to everybody affected on the same day.

That does not mean leave it alone. It means automate the part that is assembly and checking — which is most of the hours — and leave the part that is a person accepting responsibility for a set of numbers. Getting that line 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 it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

What makes payroll different

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.

It is regulated, with filing obligations, deadlines, and record-keeping requirements that vary by jurisdiction and change.

It is visible. Everyone affected sees the result on the same day, so a systematic error is discovered publicly rather than quietly.

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

So 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

The hours go into gathering, and almost none of it needs judgement.

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

Absence — holiday, sickness, parental leave — pulled from the system that holds it rather than typed from an email.

Variable pay — commission, bonuses, overtime — from the systems that calculate them, with the calculation shown rather than a total pasted in.

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

Deductions and benefits that vary, collected from their sources.

That assembly is where the time goes, it is entirely mechanical, and doing it by hand is where transcription errors enter.

The checks worth running every cycle

The highest-value automation here, and it is read-only.

Variance against last cycle, per person. Anybody whose pay changed by more than a threshold, with the reason if it is known. This single check catches most errors.

Total variance, which 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, because that is both an error risk and the shape of a common fraud.

Statutory minimums, where the calculation is derivable, since an underpayment there is a compliance matter rather than an embarrassment.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, 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 it 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 covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

The approval that must stay human

Somebody accepts responsibility for the numbers, and that is not a step to remove.

Give them what they need to approve properly: 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; one reading four hundred rows reviews none.

Record who approved and when, which is usually a requirement rather than a nicety.

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

The check that runs after, and the one most teams add last.

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

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

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

Run it the same day, since a discrepancy found on the day is recoverable and one found at month end is an investigation.

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

Keep the history. Cycle-on-cycle reconciliation records are what make an audit straightforward rather than an exercise.

Joiners, leavers, and changes

The category that produces most of the errors, because it depends on somebody telling somebody.

A leaver still on payroll is the classic, and it is caught by reconciling headcount against the HR system every cycle.

A joiner missing is discovered by the person not being paid, which is the worst possible detection mechanism.

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

Pull changes from the source system rather than relying on a form or an email, and report anything that changed without a corresponding record.

Flag the effective date, since a change applied to the wrong cycle is both 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 they are actually approving.

Who can see the pack

Access matters more here than in most automation, because the output is everybody's salary in one place.

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

The assembled pack is the most sensitive artefact your finance process produces, and it is frequently emailed.

Do not send it to a channel. Approval belongs in a direct exchange with the named approver, not somewhere with a membership list that 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 that matches your obligations rather than keeping every cycle indefinitely by default.

Log who read it. For an artefact of this sensitivity, knowing who opened it is worth more than it costs to record.

Making it survive

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

Make it idempotent, 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 it should not be produced at all.

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

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

Limits worth knowing about

Payroll rules vary by jurisdiction and change, frequently with little notice, which is an argument for leaving calculation to a provider that maintains it.

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 rather than days of slack.

Personal and financial data flows through this, at the most sensitive end of both, so access scoping and logging matter more here than almost anywhere.

This is not advice on your obligations. What you must file, retain, and check is a question for whoever advises you, and it differs by country and by employment type.

What to build first

The variance report: 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. It is read-only, it takes little building, and it catches the large majority of payroll 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, since 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?

The approval and the submission. Somebody accepts responsibility for the numbers, and the gap between prepared and submitted is where every error is still recoverable — removing it removes the process's only safety net.

What is the single most valuable check?

Per-person variance against last cycle, above a threshold, with the reason where derivable. It catches most payroll errors, it is read-only, and it runs before the money moves.

Why check total variance as well?

Because a systematic error — a wrong rate applied broadly, a deduction missed for everybody — spreads too thin to trip an individual threshold while being obvious in the total.

How do leavers stay on payroll?

Because the change depends on somebody telling somebody. Reconcile headcount against the HR system every cycle rather than relying on a notification, and report anyone present in one and not the other.

Should the automation submit the pay run?

No. 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.

When should reconciliation run?

The same day. A discrepancy between what was approved and what was paid is recoverable on the day and becomes an investigation at month end. Report differences rather than correcting them.

Does this cover our legal obligations?

No — filing, retention, and calculation requirements vary by jurisdiction and employment type and change frequently. That is a question for whoever advises you, and it is a strong argument for leaving calculation to a provider that maintains it.

Where should the approval pack go?

Directly to the named approver, never to a channel. It is the most sensitive artefact your finance process produces, and channel membership grows over time in a way nobody reviews.

What access should the automation have?

Read-only on the sources, and write access nowhere it does not strictly need it. Assembly and checking require no write access at all, which is a rare and worth-taking opportunity to scope tightly.

Related reading

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