- Accueil
- Apps
- SaaS Tools
- Australia Payroll & Payday Super for Odoo
Aperçu illustratifAustralian payroll built into Odoo:
STP Phase 2 event reporting, award-aligned pay rules, superannuation guarantee calculation with payday-super readiness, NES leave accruals, payment summaries and ABA bank files. Built to order by
ECOSIRE for your Odoo 17, 18 or 19 database.
Qu'est-ce que Australia Payroll & Payday Super for Odoo ?
Australian payroll built into Odoo: STP Phase 2 event reporting, award-aligned pay rules, superannuation guarantee calculation with payday-super readiness, NES leave accruals, payment summaries and ABA bank files. Built to order by ECOSIRE for your Odoo 17, 18 or 19 database. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $999.00 USD; request a quote for a scoped proposal.
Fonctionnalités clés
Fait sur commande, clé en main
Aucune configuration à faire vous-même — une app fonctionnelle conçue, installée et prise en charge par ECOSIRE.
- 1
Vous commandez
Commencez par un prix de développement unique. Nous cadrons le projet avec vous au lancement.
- 2
Nous développons et installons
ECOSIRE la développe, la configure et l'installe sur votre Odoo.
- 3
Mise en ligne + assistance
Vous êtes en ligne en une semaine ouvrée environ, avec deux semaines d’assistance après la mise en production. Les défauts du code que nous livrons sont corrigés gratuitement.
Spécifications techniques
- Compatibilité Odoo
- Odoo 17, Odoo 18, Odoo 19
- Éditions
- Enterprise et Community
- Licence
- Licence à confirmer
- Version Python requise
- Python 3.10+
- Base de données
- PostgreSQL 12+
À propos de ce produit
Odoo's payroll localisation coverage for Australia is thin. hr_payroll ships the engine — contracts, salary structures, hr.payslip and rule-based computation — but the country pack that turns that engine into compliant Australian payroll is not something you install and switch on. In practice Australian employers either run payroll in a separate system and re-key journal entries into Odoo, or they hand-build salary rules nobody can audit. Neither survives an ATO query. Single Touch Payroll is not an end-of-year report you can catch up on: it is an event-based submission due on or before each pay event, with STP Phase 2 disaggregating gross into overtime, bonuses, allowances by type, directors' fees, paid leave and salary sacrifice. And the payday super reform moves superannuation from a quarterly task to a per-pay-cycle obligation with a tight window between paying wages and the contribution reaching the fund — a cadence that spreadsheet-driven SuperStream batching cannot meet.
We build a proper Australian localisation layer as a first-class Odoo module. Salary rule categories and hr.salary.rule records are defined per STP income type and disaggregation code, so the categorisation the ATO wants is a property of the rule rather than a mapping bolted on afterwards. A hr.payroll.au.award model, with a hr.payroll.au.award.classification child, holds the classification levels, base rates, casual loading and penalty/overtime multipliers you operate under; hr.contract is extended to point at a classification and pay items resolve their rates through it, so an award increase is one dated record rather than fifty edited rules. Superannuation is computed by a dedicated hr.payroll.au.super.rule — dated SG percentage, maximum contribution base ceiling, and OTE-eligible earnings determined from rule category flags rather than a hardcoded list — with salary sacrifice and employer-additional contributions tracked on separate rules so the reportable employer super contributions figure comes out right. Leave sits on extended hr.leave.type records carrying NES accrual method, pro-rata basis and cash-out eligibility, with accrual posted by a scheduled ir.cron that writes allocations and leaves a traceable audit line on every run.
On the reporting side, each pay run produces an immutable hr.payroll.au.stp.event record — pay event or update event — holding the full employee-level payload, a state machine (draft / sent / accepted / rejected), the ATO receipt id and the gateway response, so a rejected submission is investigable months later instead of lost in a log file. Submission is deliberately transport-agnostic: the module builds and validates the payload, and we wire it to your chosen SBR2/DSP gateway or to a file handoff, because your ATO software id and credentials belong in your ir.config_parameter, not in a connector we control. Super contributions batch into hr.payroll.au.super.batch, producing a SuperStream-compatible alternative file format contribution file for your clearing house, with a payday-super mode that switches batching from quarterly to per-pay-run, computes the due date from the payment date and raises an overdue state before the window closes. Employee payments export as ABA files with BSB and account validation, a self-balancing option and a per-run lodgement reference, built by a byte-exact fixed-width builder rather than a QWeb template so the file parses cleanly at the bank. Payslips, payment summaries and super remittance advice are QWeb PDF reports you can rebrand.
Access control is explicit rather than assumed. ir.model.access.csv grants plus record rules separate payroll officer, payroll manager and STP lodger, hide salary data from ordinary HR users, and scope every payroll record to its company for multi-entity databases. The same models are exposed over XML-RPC and JSON-RPC under identical permission checks, so an external rostering or timesheet system can push worked hours in and read computed payslip lines out without a security bypass. Automated actions cover the operational risks that actually bite: an STP event still unsent past the pay date, a super batch approaching its payday-super deadline, an ABA file generated but never marked as banked. We target Odoo 17.0, 18.0 and 19.0 on separate branches and build against your edition — Community and Enterprise differ around payroll accounting entry generation and document handling, so the __manifest__.py dependencies branch accordingly instead of quietly assuming Enterprise.
This is a build-to-order product, not an existing download. We scope your award coverage, pay cycles, super arrangements, entity structure and gateway choice on a short call, quote a fixed price against that scope, and build. Typical delivery is one working week from confirmed scope. You get the full source installed and configured on your database, a parallel run against your real pay data on a staging copy before it touches production, training for your payroll officer, the git repository handed to your own organisation, and a post-go-live support window that includes supervision of your first live pay run and first STP lodgement. Legislative parameters — SG rate, maximum contribution base, tax scale coefficients, the payday super commencement date — are stored as dated configuration records, so a rate change is a data update you make yourself rather than a code release you wait for.
Ce que vous obtenez
- Complete installable source code for your exact Odoo version (17.0, 18.0 or 19.0) and edition, with a clean `__manifest__.py`, no obfuscation and no licence key
- Installation and configuration on your database — awards and classifications, salary structures, super rules, leave types and dated legislative parameters loaded for your entity
- Technical documentation: model and field reference, salary rule computation walkthrough, STP payload field mapping, security group matrix, and an upgrade note for the next Odoo major version
- End-user guide plus a live training session for your payroll officer and finance approver, recorded so new staff can be onboarded later
- UAT on a staging copy of your production database with your real pay data, including a parallel-run comparison against your current payroll output and a documented rollback plan
- Git repository handover — full commit history, a branch per Odoo version, transferred to your GitHub or GitLab organisation (or delivered as a bundle)
- Post-go-live support window covering defect fixes, first live pay run assistance and supervision of your first STP lodgement
- Configuration handbook for the dated legislative parameters, so SG rate, contribution base and award rate changes are updates you can make in-house
Pour qui c'est
Payroll manager at an Australian SME running Odoo
Runs fortnightly or monthly pay for 20-300 staff and keeps payroll in a separate product today because Odoo cannot lodge STP. Wants one system where the payslip, the journal entry and the super batch reconcile against each other, and wants the STP submission to be a button rather than a re-keying exercise.
Finance director preparing for payday super
Understands that payday super turns superannuation from a quarterly task into a per-pay-run cash-flow event with a short window. Needs the system to compute the due date, produce the contribution file every cycle, warn before the deadline, and give a clean RESC figure so reportable contributions are right at year end.
Odoo implementation partner or internal ERP lead
Owns the Odoo instance and will not accept an opaque third-party binary in the addons path. Wants readable models, proper `ir.model.access.csv` and record rules, a git history they can review, and a module that upgrades to the next major version rather than pinning the business to 17.0 forever.
Multi-entity employer with award-covered staff
Operates several companies or brands in one database under different modern awards and classification structures. Needs award rates held as dated data with company-scoped record rules, so a classification increase applies from the right date in the right entity and payroll never leaks across companies.
Comment Australia Payroll & Payday Super for Odoo se compare
| Critère | ÉCOSIRE | Construction personnalisée | Concurrent | Natif Odoo |
|---|---|---|---|---|
| STP Phase 2 reporting | Purpose-built event records with disaggregated gross, receipt tracking and a rejection audit trail | Achievable, but the payload schema and disaggregation rules are weeks of research before a line is written | Often a partial or Phase 1-shaped payload, with the gateway hardcoded to the vendor's own connector | No Australian STP capability in Odoo core |
| Payday super readiness | Per-pay-event batching with computed due dates and overdue warnings, switchable by dated config | Depends entirely on whether your developer tracked the reform before building | Most listings still assume quarterly SuperStream batching | No superannuation model beyond a salary rule you write yourself |
| Award rates and classifications | Dated award and classification records driving contract rates; an increase is one data entry | Usually hardcoded into salary rules, so every award increase becomes a developer ticket | Typically a flat rate field with no classification structure or penalty multipliers | Salary structures exist, but nothing models a modern award |
| Source code ownership | Full readable source and git history transferred to you — no licence key, no obfuscation | You own it, but only the original developer understands it once they move on | Commonly licence-key gated and sometimes partially compiled | Open source, but there is nothing here to own |
| Fit to your entities and pay cycles | Scoped to your awards, entities, pay frequencies and gateway before a line is written | Exact fit by definition, at full discovery and build cost | Generic by design; you adapt your process to the module | Generic engine with no Australian assumptions either way |
| Security and multi-company isolation | Separate payroll officer, manager and STP lodger groups with company-scoped record rules | Frequently deferred to phase two and never implemented | Often one payroll group with salary data visible to every HR user | Base HR groups only, with no payroll separation for Australia |
| Cost and timeline | Fixed quote against agreed scope, typically one working week to delivery | Time and materials, with the discovery phase billed to you | Cheap upfront; the real cost arrives as customisation and workarounds | Free, but the compliance gap makes it unusable for Australian payroll |
| Ongoing legislative maintenance | Rates as dated data you edit; schema changes under a support agreement, no recurring licence | Every ATO change becomes a new engagement and a new quote | Depends on whether the publisher is still maintaining the listing next year | Nothing to maintain |
Foire aux questions sur Australia Payroll & Payday Super
How long does delivery take?
This is built to order, not an instant download. Typical delivery is one working week from confirmed scope. The clock starts once we have agreed your award coverage, pay cycles, super and gateway arrangements and entity structure on the scoping call, and you have signed off the fixed quote. A single-award, single-company build usually lands at the lower end; wide award coverage, several entities or an unusual STP gateway push toward the upper end. We tell you which you are on the call, not afterwards.
Does the module lodge STP directly with the ATO?
The module builds, validates and stores the complete STP Phase 2 payload and manages the full event lifecycle, including the receipt and any rejection response. Transmission itself goes through an SBR2-enabled Digital Service Provider gateway, and we wire the module to the gateway you hold credentials with — or to a validated file handoff if your accountant lodges on your behalf. That split is deliberate: your ATO software id and credentials stay in your own database rather than inside a shared connector we control. Name your gateway on the scoping call and the integration is part of the build.
What about payday super?
The module ships a payday-super mode. Instead of accumulating contributions into a quarterly batch, it opens a super batch per pay event, computes the contribution due date from the payment date, and flags any batch approaching or past its window before it becomes a shortfall. The commencement date and the SG percentage are dated configuration records, so you can keep running quarterly today and switch cadence on the date it applies to you — no code change, no redeploy, no waiting on us.
What happens when the ATO changes rates or reporting requirements?
Two different things, handled differently. Rates and thresholds — SG percentage, maximum contribution base, tax scale coefficients, award rates — are dated data records you edit yourself, and we document exactly where. A structural change to the STP schema or a genuinely new reporting requirement is a code change; that is covered as maintenance inside your support window, and beyond it we quote it as a small scoped update. There is no recurring licence fee keeping the module alive.
How do support and updates work after go-live?
Every build includes a post-go-live support window covering defect fixes, help with your first live pay run and supervision of your first STP lodgement. You own the source and the git repository outright — nothing stops working if you choose not to renew, and there is no licence key phoning home. Beyond the included window we offer an ongoing support agreement covering legislative updates, Odoo point-release compatibility and a response SLA, or you can maintain it in-house using the technical documentation we hand over.
Does it work on Odoo Community, or do I need Enterprise?
Both are supported, and we build against your edition. The differences are real: Enterprise provides payroll accounting integration and document handling that Community does not, so on Community the payslip-to-journal posting is implemented inside the module rather than inherited. We branch the `__manifest__.py` dependencies accordingly instead of assuming Enterprise and leaving you to discover the gap. Odoo 17.0, 18.0 and 19.0 are each supported on their own branch.
Can it work alongside a rostering or timesheet system we already use?
Yes. Pay runs, payslip lines, award classifications and super batches are exposed over XML-RPC and JSON-RPC under the same access rights and record rules as the UI, so an external system can push worked hours and penalty-eligible shifts in and read computed results out without any security bypass. If you want a specific integration built rather than just the API surface, raise it on the scoping call and we price it into the same delivery.
Modules associés

Audit Trail / Audit Log
Log every create, read, write and delete on any Odoo model with old/new field values for full, exportable traceability.

Audit Trail & SoX Compliance Log
An immutable, field-level audit trail for Odoo accounting — capturing who changed what, when, from which IP, with full before/after value diffs and tamper-evident locking your auditors can trust. Built to order, installed and supported by ECOSIRE.

Authorize.Net Gateway for Odoo
A build-to-order Authorize.Net payment provider for Odoo that adds Accept.js hosted-field card entry, CIM customer-profile tokenization, and full auth/capture/refund/void reconciliation. ECOSIRE builds, installs, and supports it for your Odoo 17/18/19 environment.

Automated Database Backup & Restore for Odoo
Encrypted, scheduled Odoo backups to cloud & SFTP with retention rules, failure alerts and one-click restore. Built for you.
Australia Payroll & Payday Super
Australian payroll built into Odoo: STP Phase 2 event reporting, award-aligned pay rules, superannuation guarantee calculation with payday-super readiness, NES leave accruals, payment summaries and ABA bank files. Built to order by ECOSIRE for your Odoo 17, 18 or 19 database.
- STP Phase 2 payload builder with disaggregated gross — overtime, bonuses and commissions, directors' fees, paid leave by type, salary sacrifice, and allowance sub-types resolved from salary rule category flags rather than a post-hoc mapping table
- Immutable `hr.payroll.au.stp.event` records for pay events and update events, with draft/sent/accepted/rejected state machine, ATO receipt id, stored gateway response and the full employee-level payload retained for audit
- Transport-agnostic lodgement layer: the module validates and produces the STP payload, then hands off to your chosen SBR2/DSP gateway or a validated file drop — credentials stay in your own `ir.config_parameter`
- `hr.payroll.au.award` and `hr.payroll.au.award.classification` models holding classification levels, base rates, casual loading and penalty/overtime multipliers as dated records, so an award increase is one data entry