Australian Single Touch Payroll (STP), Payday Super and SuperStream readiness in Odoo

Open employer, employee-category and employment-rule registers

Start with the employer and ABN or other applicable identifier, entity, payroll system of record, pay calendar and responsible reviewers. Employee-category registers identify the applicable award, agreement, employment status, allowances, penalty rates, super fund details and payslip requirements. Effective dates matter; a current screen label does not establish which rule applied to a historical pay event.

Use the Fair Work annual wage review, payslip guidance and penalty-rate guidance as starting sources for current human review. They do not replace analysis of the actual award, agreement, employee category or effective date.

Replace every synthetic example with your own evidence, assign an owner, record the evidence and result, and mark each item Passed, Blocked or Not applicable.

• Employer and pay calendar: Example Australian employer and fortnightly payday. Owner: payroll controller. Evidence: entity, ABN and approved calendar. Result: Blocked pending client evidence.
• Employee category: synthetic award-covered employee. Owner: payroll/employment reviewer. Evidence: category and current instrument decision. Result: Blocked pending client evidence.
• Allowance or penalty: synthetic weekend or expense example. Owner: award/agreement reviewer. Evidence: current clause, effective date and treatment. Result: Blocked pending client evidence.
• Payslip: synthetic employee with varied earnings. Owner: payroll operations owner. Evidence: required fields and delivery evidence. Result: Blocked pending client evidence.
• Specialist review: replace the example with the qualified Australian specialist reviewing the actual employer. Owner: payroll controller. Evidence: obligations and implementation questions confirmed. Result: Blocked pending client evidence.

Reviewed 6 November 2026. General implementation guidance only; it is not tax, payroll, employment or legal advice. Confirm your obligations with a qualified Australian specialist.

Assign Single Touch Payroll (STP) Phase 2 event ownership and evidence

Single Touch Payroll (STP) Phase 2 reports are made on or before payday. Use the ATO employer reporting guidelines to review the event and required disaggregation. The pay run, payroll approval, STP preparation, user submission and later correction are related but separately controlled steps.

From 1 July 2026, Payday Super reporting includes qualifying earnings and super liability. Review the STP reporting under Payday Super source for the current fields and responsibilities. A QE-first implementation is correct. The ATO also accepts super liability plus ordinary time earnings (OTE) until 30 June 2027, so OTE submissions are not impossible during that transition. Legacy quarterly payment assumptions do not replace Payday Super deadlines.

• Pay-event approval: normal synthetic payday. Owner: payroll preparer and approver. Evidence: approved pay run and event timestamp. Result: Blocked pending client evidence.
• Phase 2 fields: employee category and disaggregated amounts. Owner: payroll reviewer. Evidence: field-level source and expected payload. Result: Blocked pending client evidence.
• Qualifying earnings: current ATO category assessment. Owner: payroll/employment reviewer. Evidence: included and excluded earnings decision. Result: Blocked pending client evidence.
• Super liability: liability associated with the payday. Owner: super reviewer. Evidence: calculation, fund and reporting reconciliation. Result: Blocked pending client evidence.
• Submission: user initiates and records the result. Owner: authorised payroll user. Evidence: timestamp, response and submitter. Result: Blocked pending client evidence.
• Correction: approved amendment after payday. Owner: payroll controller. Evidence: original event, correction and response. Result: Blocked pending client evidence.

Acceptance does not treat a generated payload as an ATO response. A user-initiated submission, its actual response and any correction path must be evidenced in the deployed build and provider process.

Apply current Payday Super and SuperStream controls

From 1 July 2026, the general superannuation guarantee (SG) rate is 12% of qualifying earnings. The ATO's Payday Super overview and payment-deadline guidance state that contributions generally need to reach funds within seven business days of payday, subject to exceptions.

SuperStream covers both money and data. Review SuperStream for employers and test the message, payment, fund receipt and SuperStream data acceptance as separate artefacts. A direct-debit arrangement does not prove that a fund received the contribution or accepted the associated data.

• Qualifying earnings: employee with reviewed earning types. Owner: payroll/employment reviewer. Evidence: included and excluded calculation with reviewer rationale. Result: Blocked pending client evidence.
• SG calculation: general 12% applied to approved qualifying earnings. Owner: super reviewer. Evidence: expected and actual liability comparison. Result: Blocked pending client evidence.
• Fund deadline: payday plus the applicable current rule. Owner: payroll controller. Evidence: fund receipt date and exception assessment. Result: Blocked pending client evidence.
• Money and data: SuperStream contribution message and payment. Owner: SuperStream provider owner. Evidence: provider references for both channels. Result: Blocked pending client evidence.
• Rejected message: synthetic fund or data rejection. Owner: super reviewer. Evidence: error, correction, resubmission and acceptance. Result: Blocked pending client evidence.
• Reconciliation: liabilities, debits, fund receipt, SuperStream data acceptance and STP compared. Owner: finance controller. Evidence: signed reconciliation with residual ownership. Result: Blocked pending client evidence.

No universal payroll compliance or automatic acceptance follows from these controls. Exceptions and employee-specific circumstances require review by a qualified Australian specialist.

Keep PAYG withholding, instalments, BAS and STP distinct

PAYG withholding concerns amounts withheld and reported under the employer's obligations. PAYG instalments are a separate regime, BAS is a reporting and payment channel for applicable obligations, and STP reports payroll events. A single payroll calendar entry cannot stand in for all four.

Review the actual withholder size and cycle using the ATO guidance for small and medium withholders and large withholders. Use current tax tables, including the applicable tables effective from 1 July 2026, with human review.

• PAYG withholding: employer-specific withholding cycle. Owner: PAYG reviewer. Evidence: actual notice, payday and payment obligation. Result: Blocked pending client evidence.
• PAYG instalments: separate instalment notice where applicable. Owner: BAS or tax reviewer. Evidence: issued notice and confirmed cycle. Result: Blocked pending client evidence.
• BAS: relevant reporting and payment obligation. Owner: BAS reviewer. Evidence: actual BAS statement and agent concession. Result: Blocked pending client evidence.
• STP: on or before the relevant payday. Owner: payroll submitter. Evidence: pay event and submission evidence. Result: Blocked pending client evidence.
• Tax-table version: current table for the pay date. Owner: payroll configuration owner. Evidence: source, effective date and configuration test. Result: Blocked pending client evidence.

Acceptance compares the calendar with actual notices and tests one routine and one changed-cycle scenario. It does not infer eligibility, concessions or withholding amounts from a generic template.

Scope SuperChoice onboarding and user-initiated Odoo actions

The reviewed Odoo 19 Australian payroll documentation and its documentation change record describe SuperChoice API onboarding with scoped test and production setup, user-initiated STP submissions and direct-debit arrangements for super contributions. STP submission, debit initiation, fund receipt and SuperStream data acceptance are separate events; none constitutes automatic end-to-end compliance.

Record the employer and ABN/entity onboarding evidence, exact SuperChoice arrangement, test credentials, production credentials, access owners and direct-debit approval. Keep test and production artefacts visibly separate. Credentials and bank authorities are handled through the client's approved secure process rather than embedded in project notes or test scripts.

• Employer onboarding: synthetic entity in scoped test, followed by client-approved employer and ABN details for production. Owner: payroll implementation owner. Result: Blocked pending client evidence.
• SuperChoice credentials: test-only access and expiry record, followed by secure production handover. Owner: authorised client administrator. Result: Blocked pending client evidence.
• STP submission: user initiates a synthetic test event, then an authorised user initiates the actual event. Owner: payroll submitter. Result: Blocked pending client evidence.
• Direct debit: test approval and failure scenario, followed by client bank and provider approval for super-contribution arrangements. Owner: finance and provider owners. Result: Blocked pending client evidence.
• Build validation: version, configuration and response captured, followed by the same scoped tests on the production-ready build. Owner: payroll test owner. Result: Blocked pending client evidence.

Test successful and rejected submission, direct-debit failure, correction and access revocation. STP submission responses, debit initiation, fund receipt, SuperStream data acceptance and reconciliation remain different checkpoints.

Exclude unsupported business flows before configuration or migration

Year-to-date migration needs an object and population register covering employee categories, pay events, earnings, allowances, deductions, super liabilities, fund details and opening balances. Source values, target values and reconciliation are reviewed by payroll specialists rather than inferred from accounting journals.

The standard Odoo Australian payroll business flow excludes Foreign Employment Income (FEI), actors and performers, death-benefit reporting, withholding payer number (WPN) instead of an ABN, and allowances subject to varied withholding. These are business-flow exclusions, not only YTD-import exclusions. Affected populations are outside standard Odoo Australian payroll scope and require joint Odoo and specialist assessment before configuration or migration, including whenever YTD migration is involved. A row-count match cannot override those exclusions.

• Standard payroll population: no identified business-flow exclusion. Owner: payroll implementation owner. Evidence: approved configuration and, where relevant, source-to-target YTD reconciliation. Result: Blocked pending client evidence.
• Foreign Employment Income (FEI): synthetic excluded classification. Owner: Odoo and specialist assessors. Evidence: joint assessment outside standard Odoo Australian payroll scope before configuration or migration. Result: Blocked pending client evidence.
• Actor or performer: synthetic excluded employee category. Owner: Odoo and specialist assessors. Evidence: business-flow assessment and targeted handling. Result: Blocked pending client evidence.
• Death-benefit reporting: synthetic excluded payment. Owner: Odoo and specialist assessors. Evidence: business-flow decision and supporting evidence. Result: Blocked pending client evidence.
• Withholding payer number (WPN) instead of an ABN: synthetic excluded employer arrangement. Owner: Odoo and specialist assessors. Evidence: assessment outside the standard ABN business flow. Result: Blocked pending client evidence.
• Allowances subject to varied withholding: synthetic allowance requiring current review. Owner: Odoo and specialist assessors. Evidence: current clause, business-flow assessment and target decision. Result: Blocked pending client evidence.

The migration plan states whether each excluded population is transformed separately, manually reconstructed, retained in an archive or handled by another provider. It never silently drops the population to make totals agree.

Treat registers and later versions as bounded evidence

The ATO product register and Super product register can be checked for current entries, but they expressly do not provide a recommendation or description guarantee. Register presence is not ATO endorsement, proof of every deployed feature or a substitute for SuperChoice and build testing.

Maintain three requirement classes: documented Odoo 19 core behaviour, custom or provider requirements, and separately labelled later-version education. SuperChoice onboarding, direct debit, award decisions and client procedures are not relabelled as generic accounting configuration. Record both the QE-first design and the ATO transition path so an accepted OTE submission is not rejected as impossible and quarterly payment assumptions are not retained.

• Odoo 19 documentation: use it to establish documented feature scope, then test the proposed deployed build. Owner: payroll test owner. Boundary: no universal compliance inference. Result: Blocked pending client evidence.
• ATO registers: check the current listed product entry and date. Owner: content owner. Boundary: no recommendation or description guarantee. Result: Blocked pending client evidence.
• SuperChoice and provider evidence: establish the specific service workflow and test onboarding, messages, debit and errors. Owner: provider and payroll owners. Boundary: no automatic end-to-end statutory outcome. Result: Blocked pending client evidence.
• Fair Work and ATO rules: review current employer obligations with a qualified Australian specialist. Owner: payroll/employment reviewer. Boundary: no generic award or tax decision. Result: Blocked pending client evidence.
• Named product version and deployed build: retain acceptance evidence for that exact baseline. Owner: implementation administrator. Boundary: later versions require separate assessment. Result: Blocked pending client evidence.

Acceptance applies to the named Odoo version and deployed build; later versions require separate assessment. Keep source changes and build retests with the implementation evidence.

Train each payroll and finance role through practical labs

Role tracks cover the payroll preparer, award/agreement reviewer, super reviewer, PAYG/BAS reviewer, finance controller, implementation administrator and employee-support champion. Each track names permitted actions, required evidence, escalation and the tasks the role must not perform.

Routine labs use a normal synthetic payday and a correct fund message. Exception labs cover qualifying-earnings variation, an accepted transition OTE submission, an allowance requiring award review, an STP correction, a rejected fund message, direct-debit failure, a business-flow-excluded population and reconnection or backlog handling. Users explain which evidence belongs to money, data, reporting and reconciliation rather than memorising a single green-status definition.

• Payroll preparer: prepare and reconcile a synthetic pay run; correct an STP event with approval. Owner: payroll controller. Evidence: observed preparation and correction. Result: Blocked pending client evidence.
• Award/agreement reviewer: confirm the current category and instrument; assess an allowance subject to varied withholding and its effective date. Owner: payroll/employment reviewer. Evidence: signed classification rationale. Result: Blocked pending client evidence.
• Super reviewer: check qualifying earnings and liability; resolve a rejected fund message. Owner: super reviewer. Evidence: calculation and fund-response evidence. Result: Blocked pending client evidence.
• PAYG/BAS reviewer: check distinct calendars and notices; resolve a changed-cycle or correction scenario. Owner: PAYG/BAS reviewer. Evidence: notice and reconciliation review. Result: Blocked pending client evidence.
• Finance controller: reconcile payroll, debit and ledger; handle direct-debit failure and residual ownership. Owner: finance controller. Evidence: signed financial reconciliation. Result: Blocked pending client evidence.
• Implementation administrator: maintain scoped configuration and access; manage a credential, build or provider change. Owner: implementation administrator. Evidence: change and retest record. Result: Blocked pending client evidence.
• Employee-support champion: explain the payslip and enquiry route; handle backlog, correction and employee communication. Owner: payroll controller. Evidence: observed enquiry and escalation. Result: Blocked pending client evidence.

A role passes by completing the task and retrieving the evidence within its permissions. Attendance or a screenshot of someone else's submission is not acceptance.

Assess routine and exception lab results

Review the normal payday and every exception lab against its expected result, including the accepted transition OTE path. Record Passed, Blocked or Not applicable with the evidence and owner rather than treating attendance or a screenshot as acceptance.

Retain record classes and agree the acceptance pack

The agreed acceptance pack includes employer and employee registers, current award and ATO review, expected and actual pay-event fields, SuperChoice test and production evidence, submission responses, direct-debit results, YTD reconciliations, exclusion dispositions and role assessments. Every residual has a named owner and stop or escalation condition.

Most ATO business records are retained for five years, with exceptions. Fair Work time-and-wages records require seven years. ASIC financial records require at least seven years. Assign the obligation and any exception by record class rather than imposing one database-wide period. Control access, correction and audit ownership for source exports, payslips, provider messages, approvals and reconciliation evidence.

• Normal payday: on-or-before-payday user submission evidenced. Owner: payroll controller. Stop condition: missing or late unapproved submission. Result: Blocked pending client evidence.
• QE variation: current qualifying-earnings decision and liability agree. Owner: payroll/employment reviewer. Stop condition: transition OTE path ignored or quarterly assumptions retained. Result: Blocked pending client evidence.
• Fund exception: rejected message corrected and reconciled. Owner: super reviewer. Stop condition: money or data status unclear. Result: Blocked pending client evidence.
• Debit exception: failure, retry and bank outcome separated. Owner: finance controller. Stop condition: debit initiation treated as fund receipt. Result: Blocked pending client evidence.
• Business-flow-excluded population: Odoo and specialist assessment recorded before configuration or migration. Owner: payroll implementation owner. Stop condition: affected population forced through standard scope. Result: Blocked pending client evidence.
• Records and access: record-class retention and retrieval tested. Owner: record and security owners. Stop condition: missing evidence or unauthorised access. Result: Blocked pending client evidence.

Confirm the employer's obligations and excluded populations with a qualified Australian specialist before relying on the configuration. No automatic ATO filing, automatic super contribution payment or acceptance of the associated SuperStream data is claimed.

Continue with the GST and BAS guide, AUD migration guide and POS recovery checklist to connect payroll controls to accounting, source data and branch operations.