HR & Payroll /Document processing live field guide · 9 min

STP Phase 2 Category Auditor

Audits pay-category mappings against ATO STP Phase 2 income types and flags generic or high-risk codes before lodgement — heading off correction events and audits.

Open the live demo

theater/demos/hr-payroll_stp-phase-2-category-auditor.html · sandbox · read-only

Open

FIG. 1

The live demo, running on fabricated data. Open it to step through the full flow — every output is shown for a person to approve before anything happens.

How it would work

Reads each payslip in the pay run, maps every component to its STP Phase 2 reporting category, flags anything bundled or miscategorised, and hands each flag to a payroll officer to fix and approve before the pay event lodges.

Input 01

The pay run + the category map

The pay run for the period — each employee's gross, overtime, allowances, paid leave and super — plus your payroll system's mapping of each pay code to an STP Phase 2 income type, allowance type and tax treatment.

Agent 02

Disaggregates and checks

Disaggregates gross the way Phase 2 requires — income type, overtime, each allowance by type, paid leave by type — and flags anything mapped to a generic code or bundled into gross when the ATO wants it itemised.

Output 03

A flagged audit, not a lodgement

A per-payslip audit: compliant components cleared, miscategorised ones flagged with the suggested reclassification and its basis. A payroll officer reviews and approves each fix before the pay event is lodged. Nothing lodges to the ATO on the tool's say-so.

Where it works well

It runs the same disaggregation check on every payslip, every pay run, and never skips it under deadline pressure.

Best for a payroll officer or bureau running regular pay events under Phase 2, where the same pay codes recur every cycle and a wrong mapping repeats silently.
It catches the classic trap — an allowance bundled into gross instead of itemised by type — that an end-of-year reconciliation would otherwise surface months later.
Across a bureau's client books, the recaptured hours go back into the genuine exceptions and the lodgement judgement, not line-by-line category checking.

The invisible cost of STP Phase 2 isn't a hard call — it's tracing every pay code to its income type, allowance type and tax treatment, payslip after payslip, when the gross used to be a single number you just sent.

Where it works badly

It only audits the mapping you gave it — a confidently clean run can still be wrong at the source.

Weak where a pay code is genuinely ambiguous — an allowance that's partly a reimbursement, or a payment that could be overtime or a bonus. It should flag for a person, not guess the category.
It can't see what isn't on the payslip — a salary-sacrifice arrangement or reportable fringe benefit recorded elsewhere won't be reconciled by reading the pay run alone.
On a one-off or heavily customised pay run with no stable pay-code library, there's no repeating pattern to check, so it gives you little over a careful manual review.

The honest test

If you can't say whether your payroll system's pay-code-to-category map was ever checked against current ATO guidance, this tool makes that unchecked map faster to lodge — not more correct.

If your payroll system maps "site allowance" to the wrong allowance type to begin with, the tool checks it against that same wrong map and clears it. It audits consistency with your configuration, not the law underneath it.

What it doesn't do — and shouldn't

It flags. A payroll officer fixes the mapping and approves. That boundary is deliberate.

WHAT IT DOES

Surfaces the income type, allowance type and tax treatment each component maps to

Flags components bundled into gross or sitting on a generic catch-all code

Shows the suggested reclassification and the basis for each flag

WHAT IT WON’T

Change the pay-code mapping in your payroll system

Lodge the pay event to the ATO

Certify the pay run as STP Phase 2 compliant

An STP pay event is a reporting obligation to the ATO, and a wrong income type or allowance category flows through to an employee's income statement, their super guarantee base and the ATO's pre-fill — so an error triggers a correction event and can prompt review. The accountable person stays on the decision because the consequence lands on the employer, not the tool.

What your data has to look like

An itemised pay run and a pay-code mapping the tool can actually read — not a single gross figure.

Typical readiness

across orgs we see, before the first job

Each payslip's components itemised

Usual weak point

The pay-code-to-category mapping, machine-readable

Needs shaping

Current ATO STP Phase 2 category definitions

Needs shaping

A stable, reused pay-code library

Usual weak point

A clean export from the payroll system

Usually ready

The real first job

The weak point is usually the pay-code mapping itself: a configuration set up once, often by whoever migrated to Phase 2, and rarely re-checked against current ATO guidance. Getting that mapping reviewed and corrected at the source is usually the real first job — a payroll-configuration exercise more than a software one, larger and more valuable than the audit layer on top. Fix the map, and every pay run after that lodges right by default.

Right fit if…

You run regular pay events under STP Phase 2 with a stable, reused pay-code library

The pay run is genuinely itemised — allowances and leave broken out, not bundled into gross

You can export your payroll system's pay-code-to-category mapping for the tool to read

You're a bureau or payroll team carrying real volume across pay cycles or client books

Walk away if…

Your gross is still a single bundled figure with allowances not separated out

The pay-code mapping lives only in someone's head or a closed payroll system you can't export

Pay runs are one-off or heavily customised each cycle, with no repeating code pattern

You want a tool that certifies the lodgement compliant without a person approving

Open questions

The worried-buyer questions, answered straight

It audits, it doesn’t lodge. It checks each component against your payroll system’s STP Phase 2 mapping, flags anything bundled into gross or on a generic catch-all code, and shows the suggested fix and its basis — but a payroll officer corrects the mapping and approves each change before the pay event is lodged. It also can’t catch a mapping that was wrong at the source, which is exactly why the person, not the tool, stands behind the lodgement.

That bundling is exactly what it’s built to flag — an allowance buried in gross instead of itemised by its STP Phase 2 allowance type is the classic Phase 2 error. But it works from an itemised pay run and a readable pay-code mapping; if your gross is a single number and the mapping lives only inside a closed payroll system, cleaning up the pay-code configuration is the real first piece of work, and the audit on top pays off across every pay run after.

No. It takes the line-by-line category checking off the desk so the payroll officer spends their time on the genuine calls — whether an ambiguous payment is overtime or a bonus, whether an allowance is really a reimbursement — and on the lodgement itself. The pay event stays theirs to approve and lodge, and where a registered agent lodges, the reasonable-care duty stays with them. The capacity it frees goes back into payroll judgement.

Current to the ATO rules in force when you run it. The STP Phase 2 disaggregation-of-gross rules and allowance types are set by the ATO and can be updated, and your payroll system’s mapping has to track them. The honest test: do you know, today, whether your pay-code-to-category map was last checked against current ATO guidance — or just carried over from your Phase 2 migration and never revisited?

Payroll data — names, pay, super, tax file information — is sensitive personal information under the Privacy Act and the ATO’s data-handling obligations. Any deployment runs against your own payroll export and systems, not a shared pool, and the data isn’t used to train third-party models; we scope where it sits and who can see it as part of the build. The demo here runs entirely on fabricated data — Broadmeadows Steel Fabrication and its employees are not real.

No — it surfaces miscategorisations and suggests fixes, but it doesn’t certify compliance. Whether an income type is right, whether an allowance type fits the payment, and whether the pay event is correct to lodge are judgements the payroll officer or registered agent makes against current ATO guidance. The tool gets the audit most of the way; the accountable person closes the last step and lodges.

What it takes to build

3–5 weeks · 4 phases

Reused from template~60%

Bespoke to this skin~40%

stack · Claude · payroll export · rules engine · review UI

What it would cost

Fixed scope, fixed price, fixed dates.

Bite-sized first piece

One contained change, low risk

Pilot build

Most builds land here

Embedded support

Scale on proof

Considering this for your payroll team?

The honest place to start is a bite-sized first piece — one pay run, one client book, low risk. Tell us where category-checking time actually goes; we'll play it back, scope it, and show you what's possible.

Book a call How we work