Enterprise Australian Payroll Architecture: Payday Super, STP and SuperStream v3
Since 1 July 2026, Australian employers
must pay super guarantee on each payday, and the money must reach the
employee's fund, with enough data to allocate it, within 7 business days.
Payroll software now has to behave like a payments system: event-driven,
idempotent, observable and reconcilable per pay event, not per quarter. This document is for CTOs, HR tech founders
and payroll providers who have shipped, or are still shipping, Payday Super
support. It covers what the rules require of your software, a reference
architecture, and the failure modes that cause late super.

- Experience
- 12+
- Projects Delivered
- 200+
- Clients Satisfaction
- 100%
What changed on 1 July 2026
Two details drive system design. The 7 business days run from the payday reported in STP, and the clock stops when the fund receives the contribution, not when your system or clearing house sends it. Longer windows exist for specific cases, such as a new employee's first contribution, so deadline logic needs reason codes, not one constant.
| Item | Before 1 July 2026 | From 1 July 2026 |
|---|---|---|
| When super is due | Quarterly, within 28 days of quarter end | Received by the fund within 7 business days after each payday (QE day) |
| Calculation base | Ordinary time earnings (OTE) | Qualifying earnings (QE), which bring OTE and some other payments together |
| STP reporting | OTE and/or super liability | Year-to-date QE and super liability, both mandatory |
| Fund handling | Longer allocation timeframes | Funds have 3 business days to allocate or return a contribution |
| Small business clearing house | ATO's free SBSCH available | SBSCH closed permanently; employers need a payroll, commercial, fund or portal route |
| Messaging standard | SuperStream contributions standard | Contribution standard v3.0, with member verification requests (MVR) and NPP support |
Payday Super architectural compliance matrix
Provides a structured overview of Payday Super architectural requirements, mapping compliance obligations to system capabilities, controls, and implementation considerations.
| Dimension | Legacy quarterly model | Payday Super model | Recommended pattern (PerfectionGeeks) |
|---|---|---|---|
| Settlement window | 28 days after quarter end | 7 business days after payday; fund has 3 business days to allocate or return | Pay on payday, not day 7. Day 7 is the hard deadline; an internal day-3 alert is the working deadline |
| Payment rail | Bank or clearing house batch, often days to settle | Faster payments where fund or clearing house supports NPP | Rail abstraction layer with per-fund settlement SLAs held as data |
| Data protocol | SuperStream contributions standard | Contribution standard v3.0 (ebMS3/AS4 between gateways, XBRL data, PRN linking payment and data) | Versioned message builders; conformance tests in CI |
| Earnings base and STP | OTE or super liability reported | YTD QE and super liability on every pay event | Pay-code to QE mapping as versioned config; delta calculation between YTD snapshots |
| Audit and reconciliation | Month-end or quarter-end | Per QE day: liability, payment, fund receipt, allocation or rejection | Append-only event log; per-contribution state machine; replayable history |
| Award and pay rules | Rules updated periodically | QE depends on how each pay element is classified, so rule changes change super | Deterministic, versioned rules engine; each pay element carries its QE class and rule version |
Reference architecture
Design rules that prevent the common failures:
STP: qualifying earnings and super liability
SuperStream v3, NPP and rejections
Identity, SSID and machine credentials
The 7-business-day deadline engine
Reconciliation and ATO compliance posture
Core technology stack and CTO checklist
Outlines the core technology stack, key architectural components, and CTO checklist to ensure the platform is scalable, secure, resilient, and Payday Super compliant.
| Layer | Recommended choice |
|---|---|
| Messaging and queueing | Apache Kafka or AWS SQS/EventBridge for durable, replayable events; outbox pattern for exactly-once-effect dispatch |
| Transport and gateways | ebMS3/AS4 via a certified gateway or in-house build validated against ATO conformance testing guidance |
| Identity | ATO machine credentials and SSID flow; OAuth2 and mTLS for your own APIs and services |
| Data | Relational store with encryption at rest (for example AWS RDS, AES-256) plus an append-only contribution ledger |
| Hosting | AWS Sydney (ap-southeast-2) is a common choice; confirm residency needs against customer contracts |
| Rules | Deterministic, versioned pay classification engine with fixtures from real award scenarios |














