Arsalan YasinMost Australian employers running Odoo believe their STP obligations are handled because pay events lodge successfully and no error codes come back. Successful lodgement is not the same as accurate lodgement. The ATO accepts what your payroll system sends it, and if your salary rules are mapped to the wrong reporting categories, you have been quietly submitting incorrect data to a system that now feeds employee tax returns, Services Australia assessments, and superannuation guarantee calculations. Getting odoo single touch payroll configuration right is a mapping exercise, not a switch you flip during onboarding.
This matters more in the 2026 to 2027 financial year than it did in any prior year. Payday Super commenced on 1 July 2026, and the ATO now calculates expected SG liability from the ordinary time earnings components inside your STP Phase 2 reporting. Misclassify an allowance and you are not just reporting the wrong figure, you are potentially underpaying superannuation against a seven business day deadline. This article covers what STP Phase 2 actually requires, how the Australian localisation in Odoo 19 handles it, and where implementations tend to break.
What Changed Under STP Phase 2
STP Phase 2 has been mandatory for all Australian employers since 1 January 2022. There are no remaining transition concessions and no further deferrals. The core shift from Phase 1 was not about reporting more often, it was about reporting with structure. Phase 1 sent a gross figure and a PAYG withholding amount. Phase 2 requires that gross be broken apart so the ATO can see what each dollar actually represents.
One practical consequence is that TFN declarations no longer need to be sent separately to the ATO once you are reporting under Phase 2, because the employment and taxation information travels inside the pay event. You still collect and retain the declaration, but the lodgement obligation is absorbed into your payroll reporting.
Disaggregation of Gross
Disaggregation is the requirement that carries the most configuration weight. Instead of a single gross amount, each pay event must separately report salary and wages, overtime, bonuses and commissions, directors’ fees, paid leave, allowances itemised by type, and lump sum payments across categories A, B, D and E.
Salary sacrifice is the trap that catches experienced payroll teams. Under Phase 1 you reported post sacrifice amounts. Under Phase 2 you report pre sacrifice amounts, with the sacrificed value reported separately as type S for superannuation or type O for other employee benefits. If your Odoo salary rules were built before this changed, or were migrated from a Phase 1 era configuration, the sequence in which your rules calculate gross will produce technically valid payslips and incorrect STP data.
Tax Treatment Codes, Income Types, and Employment Basis
Three further fields drive how the ATO interprets each payment. The tax treatment code is a six character string assembled from the employee’s tax scale, offset claims, study and training loan status, residency, and Medicare levy position. Odoo derives this from the employee record rather than asking you to enter it, which is convenient and also means an incorrect employee record silently produces an incorrect code on every pay event until someone checks.
Income type separates salary and wages from working holiday maker income, foreign employment income, closely held payees, and labour hire arrangements, with a country code required in some cases. Employment basis records whether the person is full time, part time, casual, labour hire, a non employee, or a voluntary worker. None of these are cosmetic. Income type governs which disaggregated components are permitted against that employee, so a wrong income type invalidates the reporting beneath it.
How Odoo Handles STP Phase 2 in Australia
Odoo’s Australian localisation is layered rather than monolithic, and understanding which layer does what determines whether your setup will hold up. The base module installs the Australian chart of accounts and GST configuration. Payroll compliance sits in l10n_au_hr_payroll, which installs the Australian Employee salary structure, the Australian Employee Pay structure type, and the underlying salary rules with their associated rule parameters for rates and caps.
Odoo 19 added direct lodgement through l10n_au_hr_payroll_api, which is genuinely significant. STP data is generated from the pay run, routed through an ATO approved sending service provider, and the lodgement status updates inside the same screen. Odoo states compliance with both SuperStream and STP Phase 2. Registration runs through a payroll onboarding flow where you nominate a payroll responsible user, and the system operates in either testing or production mode so you can validate output before anything reaches the ATO in earnest. Use testing mode properly. It exists precisely so that a mapping error surfaces before it becomes a correction.
Community vs Enterprise: The Licensing Reality
This needs stating plainly because it changes procurement decisions. The payroll compliance modules and STP lodgement capability are Enterprise. If you are a GST registered employer running Odoo Community, you have the Australian chart of accounts and tax configuration, and none of the payroll compliance or STP lodgement functionality. There is no supported Community path to lodging STP Phase 2 pay events natively.
The distinction between what each edition delivers for people management is worth understanding before you commit, and my breakdown of Odoo Community versus Enterprise for HR walks through where the payroll engine, salary structures, and compliance layers sit. Australian employers evaluating a Community based implementation on cost grounds usually reverse the decision once payroll enters scope.
Employee Record Configuration That Drives STP Accuracy
Because Odoo derives the tax treatment code from the employee record, the record is the control point. The Australia specific tab on the employee form captures TFN and TFN status, residency, tax free threshold election, study and training loan flags, Medicare levy variations, withholding variation where one applies, employment basis, income type, and country code for working holiday makers.
The failure pattern here is predictable. Records created during initial data migration inherit defaults, nobody revisits them, and the error compounds across every subsequent pay event for that employee. Before your next run, spot check a working holiday maker, a casual, and anyone with a study loan. Those three cases surface most configuration gaps.
Mapping Salary Rules to STP Reporting Categories
Every salary rule that produces a monetary result needs to be mapped to the STP category it belongs to. This is the step that separates a functioning payroll from a compliant one. A rule that calculates correctly but reports into the wrong bucket gives you accurate payslips and inaccurate lodgements, which is the harder problem to detect because employees never complain about it.
Allowances and Salary Sacrifice: Where Mappings Break
The ATO has been explicit that allowances must be separately itemised against the correct allowance type. Lumping allowances into a generic bucket, or leaving a pay code marked as not reportable, are among the most common setup mistakes it sees. Each allowance type carries specific deductibility implications that flow into the employee’s prefilled tax return, so a tool allowance reported as a generic allowance produces downstream problems for the employee, not just for you.
Also confirm continuity of year to date amounts. If your transition to Phase 2 reporting or your migration into Odoo broke YTD continuity, the ATO’s view of the employee’s year will not reconcile with yours.
Lodging Pay Events and Reading ATO Responses
Odoo 19 renamed payslip batches to pay runs, and the STP event is generated from the pay run rather than assembled separately. Lodgement is required on or before the day payment is made, regardless of pay frequency, with a concessional approach available for closely held payees.
Treat the response as part of the process rather than a receipt. A successful transmission confirms the file was well formed and accepted. It says nothing about whether the classifications inside it were right. Build a habit of reconciling STP totals against your payroll analysis reports each period, and cross check the ATO’s prefilled W1 and W2 labels on your activity statement against your own withholding records. Discrepancies there are usually the first visible symptom of a mapping fault.
Terminations, Cessation Codes, and ETPs
Termination reporting requires the cessation date and a cessation reason code explaining why employment ended, covering resignation, redundancy, dismissal, contract cessation, and related categories. Employment termination payments must be reported with their correct ETP codes and are excluded from ordinary gross. Because Phase 2 reporting replaced employment separation certificates for most purposes, a wrong cessation code directly affects the former employee’s dealings with Services Australia. Configure the termination workflow before you need it, not during an exit.
End of Year Finalisation in Odoo
The finalisation declaration is what moves an employee’s income statement in myGov from “not tax ready” to “tax ready”, and the ATO’s deadline is 14 July each year. Finalisation is triggered from within Odoo once all pay events for the financial year are lodged and reconciled.
Finalisation is not a formality. Errors discovered after finalisation require amended reporting, and employees who have already lodged their returns on the basis of your figures may need to amend theirs. The reconciliation work belongs in late June, not the second week of July.
Payday Super: The New Pressure on STP Data Quality
From 1 July 2026, superannuation guarantee contributions must be paid on payday rather than quarterly, and must reach the employee’s fund within seven business days. The rate remains 12 percent of the ordinary time earnings base. The Small Business Superannuation Clearing House closed, so employers who relied on it needed a replacement in place before 30 June 2026.
The connection to STP is direct. The ATO derives expected SG liability from the OTE components reported in your pay events, then matches that against contributions confirmed by funds through SuperStream. Any allowance or overtime element mapped incorrectly for OTE purposes now produces a visible gap between what the ATO expects and what your fund receives, against a deadline measured in days rather than months. Payroll classification errors that were previously invisible have become enforceable.
A Pre Go Live STP Configuration Audit
Before your next pay run, work through six checks. Verify income type and country code on every employee record. Confirm gross is disaggregating into the correct components rather than reporting as a single figure. Review every allowance mapping against its ATO allowance type. Confirm salary sacrifice is reporting pre sacrifice gross with type S and type O separated. Validate employment basis and cessation configuration. Then run a test pay event in testing mode and reconcile the output against your expected OTE base.
If that list surfaces more questions than answers, the fastest path is a working session over your actual configuration rather than a generic checklist. I work with Australian businesses on exactly this mapping layer, including salary rule configuration, employee record remediation, and validating STP output before it reaches production. Book a Consultation if you want a second set of eyes on your setup before finalisation season or your first Payday Super cycle.
Conclusion
STP Phase 2 rewards employers who treat payroll configuration as an ongoing compliance function rather than a one time implementation task. Odoo 19 gives Australian employers a credible native path, with the Australian payroll localisation handling disaggregation, tax treatment codes, and direct lodgement without a bolted on third party payroll product. What the software cannot do is tell you that a rule is mapped to the wrong category, because from the system’s perspective nothing is wrong.
The employers who will move through the Payday Super transition cleanly are the ones auditing their mappings now, in a quiet part of the financial year, rather than discovering the gaps when the ATO’s expected SG figure does not match what their fund received.
Frequently Asked Questions
Does Odoo Community support STP Phase 2 lodgement?
No. The Australian payroll compliance modules and the STP lodgement capability are Enterprise only. Community gives you the Australian chart of accounts and GST configuration, but there is no supported native path to lodging pay events.
We migrated to Odoo mid financial year. Do we need to rebuild year to date figures?
You need continuity of YTD amounts in your STP reporting, so the migrated figures must carry across correctly. The ATO does not expect employers to reconstruct pre Phase 2 periods with information that was never captured, but a mid year migration inside the Phase 2 era is a different situation and the YTD position should reconcile.
How do we know our salary rule mappings are actually correct?
Run a pay event in testing mode and reconcile the disaggregated output line by line against what each rule was intended to produce, paying particular attention to allowances and to whether OTE classified items are landing where the SG calculation expects them. Cross checking the ATO’s prefilled W1 and W2 activity statement labels against your own records is a useful ongoing control.
What happens if we miss the 14 July finalisation deadline?
Employees’ income statements remain in a “not tax ready” state, which delays their returns and can affect Centrelink and child support assessments. Failure to lodge penalties accrue per 28 day period and scale with business size, so the cost is both relational and financial.
Does Payday Super change what we report through STP?
The reporting fields themselves have not changed, but the consequences of getting them wrong have. Because the ATO calculates expected SG liability from the OTE components in your pay events, classification errors that previously went unnoticed now generate visible discrepancies against a seven business day payment deadline.
