Employment Hero AU Payroll
An Australian configuration overlay on the Employment Hero work entry sync, shipping super and STP endpoints plus a country scoped mapping variant.
Store price is USD 235 all-in: installing this also pulls the 4 paid ERP Heritage modules it depends on.
Why this module
Employment Hero AU Payroll
Australian catalogue, nothing more
Two endpoints, two mapping variants and one job, all shipped as data. No new payroll models, no employee field changes, no migrations. It prepares the Australian shape a work entry deployment builds on, and stops there.
Tunable without an upgrade undoing it
Endpoints ship with noupdate off so corrections reach you on upgrade. Mappings and the job ship with noupdate on, so any source path or policy you adjust on site survives the next module update untouched.
Runs on the proven orchestrator
The STP pull job runs through the same engine as the rest of the suite: external id cross reference, idempotent upsert, per record isolation, audited runs. Running it twice never duplicates a work entry type.
Day in the life
An Australian deployment prepares its work entry sync.
After installing the overlay, the Australian endpoints and mappings are present. The administrator opens the STP Categories (AU) job and runs it. The engine fetches pay categories from the Australian business API, paginating with OData skip and top, then maps each one onto a work entry type, keyed by its external id so a re run updates rather than duplicates. Single Touch Payroll reporting codes land on the external code field of the work entry type. The run records what it created and updated, and ends done. The work entry mapping is now scoped to Australia, so when the company country is Australia the engine selects the Australian shape instead of the default. The superannuation endpoint sits ready in the catalogue for the deployment to wire into its own job when it needs super payment data. No payroll model was created, no employee field was touched, and the whole step was configuration the module shipped.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
The STP category job keys every record by its external id through the cross reference, so re running it updates the matched work entry type instead of creating a second one. An unchanged payload is a no op.
Each record is processed inside its own savepoint. One malformed STP category is logged as an error line and the run continues to the next, ending in the partial state rather than aborting the whole pull.
Both Australian endpoints declare OData paging with a page size of one hundred, so the engine walks skip and top pages until a short page ends the scan, with a maximum page guard that stops a runaway unbounded read.
The work entry and STP mappings carry the Australian country, so the engine selects them only when the company country is Australia and falls back to the base mapping otherwise. Australian and non Australian companies coexist.
When a webhook drives the job, the inherited engine verifies the HMAC signature in constant time, rejects replays by a unique event constraint, and queues deliveries for one record on an ordered per entity channel so they apply in arrival order.
Endpoints run under the payroll rate group. A 429 or transient error is retried with exponential backoff and jitter, honouring a clamped Retry After header, and a token bucket holds the client side budget below the Australian API ceiling.
The STP job uses an explicit Employment Hero wins policy on pull, so a category changed on both sides resolves by the rule you chose rather than by accident. The policy is a field you can change on the job.
What is inside
Built to do the job, end to end.
- Superannuation contributions endpoint. A GET endpoint on the Australian business super payment path, with OData paging and a page size of one hundred, registered under the payroll rate group. It ships ready for a deployment to wire into its own job.
- STP categories endpoint. A GET endpoint on the Australian business pay category path, same paging and rate group, feeding the Single Touch Payroll category catalogue into the sync engine.
- AU work entry mapping variant. A pull mapping onto the existing work entry model, scoped to Australia, mapping name, employee by external id, date, duration in hours and work entry type. It lets an Australian deployment diverge the Australian shape from the default without touching the base mapping.
- STP category mapping and pull job. A pull mapping that lands STP categories onto work entry types, mapping name, code and the Single Touch Payroll reporting code onto the external code field, with a ready to run job that pulls them keyed by external id with an Employment Hero wins conflict policy.
- Tunable as data. Endpoints ship with corrections delivered on upgrade, while the mappings and job ship so that on site edits to source paths or policies survive the next update. Most changes here are configuration rows, not code.
Honest about the edges
What this does not do, so nothing surprises you.
- This module is configuration only. It creates no payroll models and adds no fields to the employee or any other record. It ships the Australian endpoint and mapping catalogue, not a payroll calculation engine.
- It depends on the Employment Hero work entry sync module and the wider suite engine. On its own it does nothing; it extends an existing deployment.
- The superannuation endpoint is shipped but has no accompanying sync job. A deployment wires it into its own job when it needs super payment data. Only the STP category pull job is ready to run out of the box.
- Australian mapping selection depends on the company country being set to Australia. With a different company country the engine uses the base mappings instead.
- Source paths in the mappings reflect the published Australian business API payload shape and may need tuning to match your organisation's exact payload before a first successful run.
- Targets the Odoo 17 Community work entry model. It does not add Single Touch Payroll lodgement, ATO submission, or any statutory filing; it syncs the category catalogue and work entry context only.
- STP reporting codes are carried onto the external code field of the work entry type for reference. The module does not interpret or validate them against ATO rules.
Employment Hero Odoo integration, Australian payroll Odoo 17, Single Touch Payroll Odoo, superannuation sync Odoo, KeyPay Odoo connector, work entry sync Odoo, STP category mapping, Odoo 17 Community payroll integration, Employment Hero work entry, idempotent payroll sync, country scoped mapping Odoo, Australian business API Odoo
Need this fitted to the way you work?
ERP Heritage delivers end to end Odoo work: Odoo Implementation, Customization and Development, Integration, Migration, Consultation, Support and Training. We help teams put this module into production, shape it to their process, and keep it running.
We work with businesses across Australia (Melbourne, Sydney, Brisbane, Perth, Adelaide, Canberra) and the Middle East (Dubai, Abu Dhabi, Riyadh, Jeddah, Doha, Kuwait City, Muscat). Start a conversation at erpheritage.com.au or email info@erpheritage.com.au.
Languages
Available in 19 languages
The interface ships translated out of the box. Switch language in Odoo and the fields, menus, and messages follow.
Modules teams pair with this one.
Premium ERP Heritage modules that extend the same stack, each built to the same engineering bar.
Real-time fiscalisation of customer invoices and credit notes with the Mauritius Revenue Authority e-Invoicing (E...
The Canada country pack for the ERP Heritage Employment Hero integration
A dependency free asynchronous job queue that runs long running and fan out work out of band of the request that...
Post Irish payslips to the general ledger on the Irish chart of accounts
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Employees (hr)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 4271 |
| Technical Name |
eh_hero_ent_country_au |
| License | OPL-1 |
| Website | https://www.erpheritage.com.au/ |
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module