Australian HR and Payroll Software: STP, Super, Awards

Australian HR and payroll software must do more than calculate gross pay and tax. It needs to report the correct employment and income information through STP Phase 2, calculate superannuation under the current Payday Super rules, exchange contribution data through the SuperStream standard, and apply the Fair Work Act, National Employment Standards, and relevant Modern Awards. The payroll engine therefore needs structured pay categories, employee classifications, award rules, audit history, and compliance-aware integrations.

Why Australian Payroll Software Is More Complex Than a Pay Run

A payroll system can produce the right-looking payslip and still calculate an employee's entitlements incorrectly.

That is the central problem with treating Australian payroll as a simple calculation engine.

A payroll run takes employee data, hours, rates, allowances, overtime, leave, deductions, superannuation, taxation information, and employment conditions and turns them into financial transactions. But Australian employers also operate within the Fair Work system, Modern Awards, National Employment Standards, Single Touch Payroll reporting, superannuation obligations, and increasingly time-sensitive super payment requirements.

Each layer affects the software architecture.

An employee's employment type affects how the payroll engine interprets hours and entitlements. The applicable award affects penalty rates, overtime, allowances, classifications, and working conditions. STP Phase 2 requires income and payment information to be categorized and reported to the ATO. Superannuation requires its own calculation and contribution workflow.

Since 1 July 2026, Payday Super has added another major timing requirement: employers must pay Superannuation Guarantee contributions on payday, with the contribution generally required to reach the employee's super fund within 7 business days. The current SG rate is 12%.

This means Australian payroll software needs to manage both calculation and compliance timing.

What STP Phase 2 Changed

Single Touch Payroll Phase 2 expanded the information employers report to the ATO through each STP pay event.

Phase 1 largely focused on reporting gross amounts, PAYG withholding, and superannuation information. Phase 2 introduced more detailed categorisation so the ATO can distinguish how payments are made up and how employees are engaged.

The payroll system needs to assign the appropriate income type to payments and disaggregate gross amounts where required.

This can include salary and wages, closely held payees, working holiday makers, employment termination payments, bonuses, commissions, overtime, allowances, paid leave, and other payment categories depending on the employee and payment circumstances.

The employee record also needs information that was not necessarily required in the same way under Phase 1.

Employment basis is one example.

The system needs to distinguish employment arrangements such as full-time, part-time, casual, and other relevant categories so the STP report contains the required employment information.

Cessation information is another.

When employment ends, the payroll system needs to capture the relevant cessation reason rather than treating termination as a simple change to employee status.

Disaggregating Gross Pay

One of the most important STP Phase 2 changes is that gross pay can no longer be treated as one undifferentiated amount.

Suppose an employee receives ordinary salary, overtime, a bonus, and an allowance in the same pay run.

The payroll engine needs to know what each amount represents before it can generate the correct STP report.

This is why payroll architecture should separate pay codes from the final gross amount.

A pay code should have a defined classification and reporting treatment.

The payroll calculation engine determines the amount.

The STP mapping layer determines how that amount is represented in the ATO report.

This separation becomes useful when reporting requirements change because the business does not have to rewrite the underlying wage calculation simply because an external reporting category changes.

Salary Sacrifice and STP Reporting

Salary sacrifice also requires careful data treatment.

The payroll system should distinguish the employee's gross earnings from amounts salary sacrificed and preserve the relevant reporting information rather than simply reducing the final bank payment.

This is another reason a payroll system should maintain a detailed pay-event ledger.

The system should be able to answer not only "What did the employee receive?" but also "How was that amount constructed, and how was each component reported?"

That distinction becomes important during payroll reconciliation and reporting reviews.

What a Payroll Engine Must Transmit to the ATO

A compliant STP integration should not be treated as a CSV export followed by a manual upload.

The payroll application needs a structured reporting layer that converts the completed pay event into the required STP message and submits it through the employer's approved digital service provider pathway.

The underlying payroll record should retain the values used in the report.

That means the system can reconcile the pay run against the STP submission and identify whether an employee's income type, withholding amount, super information, or other reported field differs from the payroll calculation.

The integration also needs error handling.

An STP submission may be rejected or require correction. A production payroll platform therefore needs submission status, response handling, correction workflows, retry logic, and an audit trail.

The objective is not simply to send a file.

The objective is to create a traceable chain between the payroll calculation, the reported STP event, the response, and any subsequent correction.

Superannuation Guarantee: OTE, Qualifying Earnings and Payday Super

Superannuation is one area where older payroll assumptions can now create serious problems.

Historically, payroll systems commonly calculated the Superannuation Guarantee against Ordinary Time Earnings (OTE), which excludes certain payments depending on their nature.

That distinction remains important for understanding payroll data.

However, from 1 July 2026, Payday Super changes the statutory calculation framework. The ATO's current technical guidance describes the relevant calculation as 12% of an employee's qualifying earnings, a new term that brings together OTE and other payments covered by the new rules.

This means a payroll system being built or updated now should not simply hard-code "SG = 12% of OTE" as the complete rule.

The software needs a calculation model that can identify the employee's qualifying earnings under the current legislation and distinguish those values from other payroll amounts.

Why the OTE Distinction Still Matters

The historical OTE model is still useful when understanding why payroll calculations go wrong.

Not every payment included in gross pay has traditionally been treated as OTE.

For example, particular overtime payments can be treated differently from ordinary hours, while other payments can have their own treatment.

A payroll engine therefore needs payment-type classification before it calculates superannuation.

The important architectural point is that "gross pay" should not be the only financial field used by the super engine.

Each pay component should carry metadata describing its treatment.

The super calculation can then determine which components form part of the relevant qualifying earnings base under the current rules.

This prevents the common mistake of applying one percentage to the employee's entire gross amount without examining the payment composition.

Payday Super Changes the Timing Architecture

Before Payday Super, payroll systems could calculate superannuation during a pay run while the actual contribution payment followed the traditional quarterly timetable.

From 1 July 2026, employers must pay SG on payday, with the contribution generally required to reach the employee's super fund within 7 business days.

That changes the software workflow.

The payroll run can no longer finish with a simple "super calculated" status.

The system needs a contribution workflow that moves from calculation to validation, payment, transmission, response handling, reconciliation, and exception management.

A contribution that fails because of incorrect fund information cannot simply remain unresolved until the next quarter.

The system needs to surface the failure quickly enough for the employer to correct it within the required timeframe.

This is where payroll software starts behaving more like a transaction processing system than a reporting application.

SuperStream Is a Data and Payment Standard

SuperStream standardizes the electronic exchange of superannuation contribution data and payments between employers, super funds, and relevant parties.

The technical standard includes structured contribution messages, payment information, validation processes, error handling, and related services.

The ATO's current SuperStream technical material has also moved into a new phase with Contribution Standard v3.0.

The current v3 release introduces changes including standardized error messages, approved NPP payment functionality, and a new capability for employers to verify member details with super funds before making contributions.

This matters to software developers because SuperStream is not simply a bank transfer.

The payment and its associated contribution data need to remain connected.

An employer may have multiple employees, multiple funds, different member identifiers, contribution types, and payment references inside one payroll cycle.

The platform needs to preserve those relationships.

Why Manual Super Processing Creates Risk

A manual workflow may involve exporting contribution data, checking fund details, uploading information through another system, initiating payment, and later reconciling the results.

That may work for a small payroll.

At scale, every manual handoff introduces another opportunity for an employee's fund details, contribution amount, payment reference, or transaction status to become inconsistent.

A software-integrated workflow can validate the employee's fund information, generate the required contribution data, send it through the appropriate channel, track responses, and reconcile the final result against the payroll ledger.

The goal is not to eliminate human review.

Finance teams still need exception handling.

The goal is to make exceptions visible rather than making every contribution a manual process.

Modern Awards Are a Rules Engine Problem

Modern Awards are one of the hardest parts of Australian payroll software because they are not simply lists of hourly rates.

An award can define minimum pay rates, classifications, ordinary hours, overtime, penalty rates, allowances, breaks, rosters, and other conditions.

The Fair Work Ombudsman also notes that the applicable award depends on the employer's industry and the employee's duties.

That means the payroll engine needs more than an employee's job title.

It may need the employee's classification level, ordinary hours, work pattern, day, time, location, employment type, and relevant award coverage.

Penalty Rates and Overtime

Consider an employee who works ordinary hours during the week and additional hours outside the ordinary span.

The payroll system needs to determine whether those hours are ordinary time, overtime, weekend work, public holiday work, or another category covered by the applicable award.

The rate may then depend on the employee's classification and employment type.

This becomes more complicated when allowances or other all-purpose payments interact with the rate calculation.

A generic payroll product may provide configuration fields for overtime and penalty rates, but that does not automatically mean it can interpret every Modern Award scenario correctly.

The important distinction is between storing a rate and calculating an entitlement.

A production Australian payroll engine needs rules that determine which rate applies to a specific work event.

Award Changes Must Be Versioned

Modern Awards change.

The Fair Work Ombudsman notes that awards are regularly updated by the Fair Work Commission.

A payroll platform should therefore avoid overwriting an old rate or rule with a new one.

Instead, award rules should be versioned by effective date.

An employee paid under an award in June should be calculated using the rules applicable to that pay period, while a July pay run may use updated rates or conditions.

This becomes particularly important during remediation.

If an employer discovers that an employee was underpaid six months earlier, the payroll system needs to reproduce the calculation using the rules that applied at the time.

A current-rate-only database cannot reliably do that.

Why Award Underpayments Become Software Problems

The Fair Work Ombudsman maintains specific guidance for employers dealing with underpayments and recommends reviewing pay records across the relevant employment period.

Underpayments can involve base rates, penalty rates, overtime, allowances, leave payments, leave loading, and other entitlements.

This means an underpayment investigation may require the employer to reconstruct historical payroll calculations rather than simply compare one payslip with one current rate.

Software architecture can make that process easier or harder.

If the system stores only the final gross amount, reconstruction becomes difficult.

If it stores the employee's classification, applicable award version, work hours, pay codes, rates, rules, and calculation results, the employer has a much stronger audit trail.

This is why payroll software should retain the inputs and rules used to produce a pay result.

The system should be able to answer:

Which award applied?

Which classification was used?

Which rate was active?

How many ordinary hours were worked?

Which hours attracted a penalty?

Which allowances were included?

Which super calculation applied?

What was reported through STP?

What was actually paid?

That level of traceability is particularly valuable when an employer needs to investigate historical payroll errors.

Full-Time, Part-Time and Casual Employees

Employment type changes how payroll rules are applied.

Full-time employees generally have a different ordinary-hours structure from part-time employees.

Part-time employees may have agreed hours that affect overtime and additional-hours treatment.

Casual employees have different entitlement structures and can receive casual loading where applicable.

The payroll engine therefore needs employment type as a structured field rather than simply a label displayed on the employee profile.

It also needs to understand the relationship between employment type, award classification, hours, leave, pay rates, and superannuation.

The system should not assume that a casual employee is simply a full-time employee with an additional percentage.

The relevant award and current employment rules determine the actual calculation.

This is especially important when an employee's employment arrangement changes.

If a casual employee becomes permanent, the payroll system needs an effective-dated employment record so that calculations before and after the change remain historically accurate.

Independent Contractors Need Separate Treatment

An independent contractor should not simply be added to the employee payroll table and assigned a different tax setting.

Employee and contractor relationships have different legal and payroll implications.

The classification needs to be assessed correctly before the software decides how the relationship should be handled.

A payroll platform can store contractor records and payment information, but it should not treat contractor classification as a cosmetic field.

Where a business has both employees and contractors, the system should keep the underlying relationship type explicit and ensure that employee entitlements and payroll workflows are not accidentally applied to contractor payments.

This becomes especially important when the business uses integrated HR, payroll, invoicing, and workforce-management systems.

Multi-State Payroll Considerations

Australia's national workplace relations system covers many private-sector employers, but state and territory rules can still affect payroll operations.

Payroll tax is one example.

Payroll tax is administered by the states and territories, with different thresholds and rules.

Leave and public holiday arrangements can also create operational differences depending on the employee's location and applicable employment framework.

The payroll system should therefore store the employee's work location and effective dates rather than assuming that one global payroll configuration applies to every employee.

Public holidays are another practical example.

An employee working in one state may encounter a different public holiday calendar from an employee working in another.

If the business operates nationally, the payroll engine needs location-aware calendars and rules.

This is not about creating a completely different payroll engine for every state.

It is about making location a first-class payroll input.

Generic Payroll SaaS vs. Custom Australian Payroll Software

International payroll SaaS platforms can work very well for businesses with straightforward employee structures, limited award coverage, standardized pay cycles, and uncomplicated superannuation workflows.

A business with salaried employees on individual contracts may not need a highly specialized award engine.

The situation changes when the workforce becomes more complex.

A hospitality business may have several employment classifications, casual workers, weekend penalties, public holiday rates, overtime, allowances, and changing rosters.

A healthcare or aged-care business may have multiple awards and complex shift arrangements.

A national service company may operate employees across multiple states and locations.

A business that has already undergone a wage remediation exercise may also discover that its payroll system cannot reproduce historical calculations accurately.

In these cases, custom development or deep integration can be justified.

That does not necessarily mean replacing the payroll platform.

A business may retain an established payroll engine while building custom HR, award interpretation, rostering, workforce, reporting, or integration layers around it.

The right architecture depends on where the actual limitation sits.

How Custom Australian Payroll Architecture Should Work

A custom or heavily integrated payroll system should separate employee data, time data, pay rules, calculation logic, reporting, and external compliance integrations.

The employee service maintains employment type, start date, classification, award, location, and relevant employment information.

The time and attendance service provides worked hours, shifts, breaks, leave, and other inputs.

The rules engine determines ordinary hours, overtime, penalty rates, allowances, and other applicable entitlements.

The payroll engine calculates gross pay, deductions, tax, superannuation, and net pay.

The STP service maps the completed payroll data to the required ATO reporting categories.

The superannuation service calculates the relevant contribution amount under the current rules and manages the Payday Super and SuperStream workflow.

The audit layer preserves the calculation inputs, rule versions, outputs, submissions, responses, corrections, and payment records.

This separation makes regulatory change easier to manage.

When an STP reporting category changes, the reporting layer can be updated without rewriting the entire payroll engine.

When an award changes, a new effective-dated rule version can be introduced.

When SuperStream technical requirements change, the contribution integration can be updated independently from employee calculations.

When Custom Payroll Development Makes Sense

Custom payroll development should not be the default choice.

If an established payroll platform already supports the employer's awards, employee types, STP requirements, super workflows, and reporting needs, adopting that system may be more practical than building another payroll engine.

Custom development becomes more relevant when the business has a combination of complex awards, large casual or part-time workforces, custom rostering, multiple HR systems, unusual pay structures, existing payroll integrations, or a need to reproduce historical calculations for remediation.

It can also make sense when payroll is part of a broader workforce platform.

For example, a business may want recruitment, employee onboarding, rostering, time tracking, payroll, leave, compliance, and workforce analytics connected through one architecture.

In that situation, payroll becomes one component of a larger HR system rather than an isolated product.

Australian HR and Payroll Software Summary

Requirement	What It Means	Software Implication
STP Phase 2	Payroll data must be reported to the ATO using more detailed income and employment categories.	Maintain structured pay codes, income types, employment basis, cessation data, and STP mappings.
Disaggregated gross pay	Different components of gross pay may need separate reporting treatment.	Store salary, overtime, bonuses, allowances, leave, and other pay components separately.
Superannuation	SG is currently 12%, with Payday Super applying from 1 July 2026.	Calculate qualifying earnings correctly and manage contribution payment timing.
SuperStream	Contribution data and payments follow standardized electronic processes.	Integrate contribution messages, validation, payment status, errors, and reconciliation.
Modern Awards	Awards determine minimum rates and conditions including overtime, penalties and allowances.	Use an effective-dated award rules engine rather than static pay rates.
Employment type	Full-time, part-time and casual arrangements affect payroll calculations and entitlements.	Store employment type as structured, effective-dated payroll data.
Independent contractors	Contractor relationships require separate treatment from employee payroll.	Keep contractor and employee workflows distinct.
Multi-state workforce	Location can affect public holidays, payroll tax and other operational requirements.	Store employee work location and apply location-aware rules.
Payroll remediation	Historical underpayments may require reconstruction of earlier calculations.	Preserve rule versions, pay inputs, calculation results and audit history.
ERP and HR integration	Payroll may need to exchange data with HR, accounting, rostering and finance systems.	Define clear system-of-record boundaries and API-based integration.

Frequently Asked Questions

What is STP Phase 2 in Australian payroll?

STP Phase 2 expands the information employers report to the ATO through Single Touch Payroll. It requires more detailed reporting of income types, disaggregated gross amounts, employment information, allowances, and other payment details, with additional information such as cessation reasons captured where applicable.

How is superannuation calculated in Australia?

From 1 July 2026, the Superannuation Guarantee rate is 12% and Payday Super requires employers to pay SG on payday, with contributions generally required to reach the employee's super fund within 7 business days. The calculation uses qualifying earnings under the current rules, which incorporate Ordinary Time Earnings and other specified payments.

What is SuperStream in Australian payroll?

SuperStream is the Australian standard for electronically sending superannuation contribution data and payments. Payroll software needs to generate compliant contribution information, support validation and payment workflows, handle errors, and reconcile contribution transactions with the payroll records.

Why are Modern Awards difficult for payroll software?

Modern Awards contain industry- and occupation-specific rules covering minimum rates, classifications, ordinary hours, overtime, penalty rates, allowances, breaks and other conditions. The applicable rules can depend on the employee's classification, employment type, hours and work patterns, so a simple fixed-rate payroll configuration may not accurately calculate every award entitlement.

Can custom payroll software support STP Phase 2 and SuperStream?

Yes. A custom payroll platform can integrate STP reporting and SuperStream workflows, provided the implementation follows the applicable ATO technical standards and uses the required digital service provider, gateway, fund, and validation arrangements. The payroll calculation layer should remain separate from the external reporting and contribution integrations.

Conclusion

Australian payroll software needs to be built around Australian payroll rules rather than treating Australia as another country configuration inside a global pay engine.

STP Phase 2 requires more detailed reporting than the original STP model.

Modern Awards require classification-aware calculations for rates, overtime, penalties, allowances, and other entitlements.

Superannuation has also entered a new phase. From 1 July 2026, the 12% SG rate applies alongside Payday Super, which changes the timing and software workflow for contributions.

SuperStream then connects contribution data and payments through standardized electronic processes.

For businesses with straightforward employment structures, established payroll SaaS can be a practical choice.

For businesses with multiple awards, large casual workforces, complex rostering, custom HR systems, multi-state operations, or historical payroll remediation requirements, deeper customization or a custom integration layer may be more appropriate.

The right decision is not simply whether to buy or build payroll software.

It is whether the chosen architecture can reproduce the employer's payroll rules accurately, report the required information, process superannuation on time, preserve historical evidence, and adapt when Australian employment rules change.

For businesses evaluating an Australian HR and payroll platform, Pixbit can assess the existing HR, payroll, rostering, accounting, and compliance architecture before recommending whether to integrate, extend, or build.

The exact scope depends on employee count, award coverage, payroll complexity, integrations, reporting requirements, and the level of customization required. Pixbit scopes exact cost and timeline in a single discovery session.