Payroll operations · AU

Why You Shouldn't Build Your Own Timesheet or Payroll System With Claude Code

Last updated 10 August 2026

AI coding tools can scaffold a timesheet app, not a compliant payroll system. Why construction award and EBA interpretation needs more than Claude Code.

Laptop and paper timesheets on a plywood desk in a construction site office at dusk, with a tower crane visible outside

AI coding tools are genuinely good now. Claude Code, Cursor, and similar tools can scaffold a working app in an afternoon: a form, a database, a dashboard, an approval flow. For a huge range of internal tools, that's a legitimate way to build software faster and cheaper than hiring a dev team.

Payroll is not one of those cases. Here's why.

The interface is the easy 5%

A timesheet app looks simple: clock on, clock off, submit, approve. An AI coding tool will happily generate that in an hour, and it'll look clean.

But a working interface isn't a working payroll system. The interface is maybe 5% of the actual problem. The other 95% is what happens to that data once it's submitted, and that's the part vibe-coding can't see, because it isn't written down anywhere the AI can read it.

The rules aren't in a spec sheet, they're in the award and the EBA

For construction specifically, correct pay isn't a formula you can guess from first principles. It's buried in:

  • A modern award (hundreds of pages) or an enterprise agreement negotiated with a union
  • Clause cross-references ("as per Award clause X, as varied")
  • Multi-tier overtime rules that depend on the day, the time, the shift length, and what happened on previous shifts
  • RDO accrual mechanics that bank hours at a specific rate and cap them at a specific ceiling
  • Site allowances that key off which construction site someone worked at, banded by project value
  • A minimum weekly super contribution that has to be paid as the greater of a flat dollar figure or the SG percentage, not just 12% of ordinary earnings
  • Annual leave loading that has to be added on top of ordinary pay, not folded into the base rate

None of that is intuitive, and none of it is something an AI coding assistant can infer by looking at a timesheet table and a "calculate pay" button. It has to be explicitly extracted, clause by clause, from the actual instrument that applies to your workforce, and that instrument changes over time as agreements are renegotiated and awards are varied.

We've audited real construction payroll builds where the pay categories and rule sets were mostly right, genuinely well put together, and still had two live compliance gaps: no leave loading being paid despite templates being named "with loading," and no minimum super floor enforced anywhere in the system. Both gaps were invisible from the interface. Everything looked fine until someone actually read the agreement against the configuration.

The failure mode is silent, not loud

Most software bugs announce themselves: a page crashes, a form won't submit, an error appears. Payroll bugs don't do that. If a rule is missing, the system doesn't fail; it just pays the wrong amount, confidently, every single pay run, and nobody notices until:

  • An employee raises it (rare, most people don't audit their own payslip against an award clause)
  • A union or Fair Work does an audit
  • Someone finally cross-references the config against the instrument, months or years later

By the time it surfaces, you're not looking at a bug fix. You're looking at back-pay calculations across every affected employee, potentially years deep, plus the admin cost of remediation and the reputational cost of a public underpayment finding, which in construction, with union oversight, tends to travel.

"It compiled and the timesheet looked right" is not the same as "it's compliant"

This is the core issue with using a general-purpose coding tool for this specific job. Claude Code is excellent at building software that works: that runs, that handles the happy path, that looks right in a demo. It has no way of knowing whether the underlying pay logic matches a legal instrument it's never been shown, and it has no way of flagging the handful of decisions in payroll that specifically require a human sign-off:

  • Whether a given allowance attracts superannuation (an ATO/OTE judgement call, not a coding decision)
  • Whether your rates are current or quietly frozen at a superseded agreement's numbers
  • Whether your base rate already includes an allowance the system is also paying separately (double-counting)
  • Whether "greater of" logic is actually wired in for minimum super, or just SG%

These aren't edge cases you stumble onto by testing the app. They're the kind of thing that only surfaces when someone deliberately reverse-audits the build against the instrument, clause by clause, which is a different discipline to writing the code in the first place.

Where AI coding tools genuinely help here

To be clear, this isn't an argument against AI in payroll, it's an argument against treating payroll as a generic app-building exercise. AI is genuinely useful for:

  • Extracting structured parameters from an award or EBA PDF (rates, thresholds, triggers) as a starting point for a human to verify
  • Generating synthetic test timesheets to stress-test a configuration once it's built
  • Automating the reverse-audit: reading a live config back out and diffing it against the instrument it's supposed to implement

The difference is that in all of those cases, the AI is doing extraction and checking, with a human required to sign off before anything goes live, not writing the pay logic from scratch and shipping it straight to a live pay run.

The actual fix isn't "code it better," it's "don't build the compliance layer yourself"

Payroll engines that specialise in this (rather than general-purpose app builders) exist precisely because the rules engine, the part that interprets an award or EBA correctly, is genuinely hard, genuinely specific to construction, and genuinely not something you want as a side project bolted onto a timesheet app. The timesheet is the easy part. The part worth paying for is the part that reads the award and the EBA so you don't have to guess.

Why Project Payroll built it the other way around

This is exactly the gap Project Payroll and CrewTime are built to close.

CrewTime is the timesheet layer: clock-on, clock-off, multi-job days, photo timesheet capture for sites where personal devices are banned, and a kiosk mode for shared site tablets. It looks and feels like the simple part, because for the worker, it should be simple. But every approved timesheet line feeds straight into the part that actually matters.

The award/EBA interpretation layer is where the real work happens, and it isn't vibe-coded. It runs on Employment Hero/KeyPay as the payroll engine, with a purpose-built rules layer on top that handles exactly the clauses this article is about: multi-tier overtime, RDO accrual and banking, site allowances by project value, and the minimum-weekly-super "greater of" calculation that generic payroll platforms routinely miss. Every EBA is sourced from the Fair Work Commission, built and tested in an isolated sandbox, and mapped clause-by-clause before it ever touches a live pay run.

Nothing goes live without human sign-off. The same gates that should exist in any serious payroll build, allowance super-ability, minimum super floor, leave loading, rate currency, all-purpose vs component rates, employee-to-template assignment, casual vs permanent overtime treatment, are explicit, mandatory checkpoints, not things a general-purpose coding assistant quietly assumed were fine because the timesheet rendered correctly.

Super is paid every pay run, not just calculated. Job costs land against your cost codes before the week closes, not after someone reconciles it manually. And because the rules engine is purpose-built for construction EBAs rather than assembled ad hoc, the fixes and audits described earlier in this article are things Project Payroll checks by design, not things you find out about from Fair Work.

If you're weighing up whether to build this in-house with an AI coding tool versus using a platform built specifically for construction payroll: build the timesheet yourself if you want. Just don't build the part that decides what people get paid, or use the one system where someone already has.

$15 per employee per month, published. No demo required, see the pricing calculator and get your own quote.

More on payroll operations

The Pay Run newsletter

Join the list, payroll for builders, explained fortnightly.

No lock-in · Published pricing · We reply within one business day

Questions

Can I just build a timesheet app with Claude Code?

Yes, and it will probably work fine as a capture tool. The risk starts when that app also decides what people get paid, because the pay rules live in an award or enterprise agreement the coding tool has never been shown.

What usually goes wrong in a self-built construction payroll system?

The gaps we see most often are missing annual leave loading, no minimum weekly super floor, superseded rates, allowances double-counted inside an all-purpose base rate, and overtime that ignores shift sequence.

Why are payroll bugs harder to catch than normal software bugs?

Nothing crashes. The system pays a confidently wrong amount every pay run, so it usually surfaces through a union or Fair Work audit rather than an error message, by which point back-pay is owed across every affected employee.

Where is AI genuinely useful in construction payroll?

Extracting rates and thresholds from an award or EBA for a human to verify, generating synthetic timesheets to stress-test a configuration, and reverse-auditing a live config against the instrument it is meant to implement.

What does Project Payroll cost?

$15 per employee per month, published, plus a setup fee per enterprise agreement we read and build. You can size it yourself in the pricing calculator.

Construction payroll

Stop reading about it. Put it on your crew.

Published pricing, no demos to sit through. We read your award or agreement and build it. We reply within one business day.

15 minutes, your EBA, no sales script.

No lock-in · Published pricing · We reply within one business day