Payroll across multiple ABNs: what you need to know

Running payroll across more than one ABN isn't unusual, but it does change how payroll needs to work. Each ABN is a separate legal entity for reporting purposes, so each one needs its own pay run, its own Single Touch Payroll (STP) reporting and its own compliance trail, even if the business looks and operates like one company from the outside. That's not a workaround or an edge case. It's standard practice for any business structured across multiple entities, and it's exactly where a lot of payroll setups start to creak.

It's also more common than most people realise. Franchise groups, multi-venue hospitality businesses, healthcare practice groups, aged care providers, construction businesses with related entities, and professional services firms built around trusts and holding companies all commonly operate under more than one ABN. If you're one of them, or you advise one, here's what actually changes about payroll, and what to look for in a system that handles it properly.

Why do businesses end up with more than one ABN?

There's rarely a single reason, but a few structural patterns come up again and again:

• Franchises. Franchise agreements often require each store or territory to be its own legal entity, separate from the franchisee's other locations.
• Hospitality. Liquor licences are tied to the entity, not the brand, so each venue frequently ends up on its own ABN.
• Healthcare and allied health. Practice groups commonly register each clinic separately for billing and Medicare provider reasons, even when the back-office team is shared across sites.
• Aged care and disability services. Providers often run each facility as its own entity for funding and registration purposes.
• Construction and trades. Businesses frequently set up separate trading entities per project, region or licence type, while still drawing on one shared pool of workers.
• Professional services. Many firms are structured around trusts and related companies for tax and liability reasons that have nothing to do with how the business runs day to day.

In every one of these cases, the business is one team in practice. Structurally, it's several.

What gets difficult about payroll with multiple ABNs

Each ABN needs its own pay run, and that's normal

This is the part that trips people up most, so it's worth stating plainly: Single Touch Payroll reporting is done per entity, not per business. If you operate under three ABNs, you run and report payroll for each of them separately. That isn't a limitation of any particular payroll system, and it isn't something you can consolidate away. It's how STP works for any structure with more than one ABN.

The real question isn't whether it's required (it is). It's whether your software makes it manageable or painful.

Duplicate systems and duplicate admin

The most common workaround is a separate payroll subscription for each ABN. That solves the reporting problem but creates a new one: admin staff logging in and out of multiple systems to process what is, in practice, one payroll cycle for one business. Multiply that by the number of entities in the group, and payroll day becomes several payroll days stitched together by hand.

Staff who move between entities

In groups that share a pool of workers, staff often move from one entity to another as projects start and finish, new venues open or teams are restructured. Handled badly, every move means setting the person up again: a new employee record, leave balances carried across by hand, and an employment history split across two profiles.

Staff who work across sites

Plenty of groups also have staff who split their week between entities: a chef who covers shifts at two venues, or a practitioner who sees patients at more than one clinic. The business needs to know how much of that person's wages belongs to each site. Handled badly, that means setting the person up twice, or splitting their timesheets by hand every pay cycle.

Who should see which entity's payroll

The bigger the group, the more this matters. A payroll officer who handles one venue's wages shouldn't necessarily see the whole group's pay data. An external bookkeeper brought in for one entity shouldn't see the others.

This is a genuine separation-of-duties and confidentiality issue, not a nice-to-have. Many payroll systems don't handle it well, because they're built on the assumption of one entity, one team and one set of permissions.

Real-world examples

A hospitality group runs three venues, each under its own ABN for liquor licensing. It has a head office payroll administrator who processes all three pay runs. It also has a bookkeeper who handles one venue on behalf of a part-owner of that site. Without access control at the entity level, the bookkeeper either sees everything or is locked out entirely and sent reports by hand. Neither option is good: one is a confidentiality problem, the other is extra admin nobody asked for.

A franchise runs four stores, each incorporated separately under the franchise agreement. From a staffing point of view, it's one payroll operation: the same regional manager oversees all four stores. At the back end, though, it needs four separate, correctly reported pay runs. Run from four separate systems, one payroll day turns into four.

A healthcare practice group registers each clinic as a separate entity for Medicare billing. Each clinic has a practice manager who handles that clinic's payroll, and a group finance manager needs to see all of them. Each practice manager should see their own clinic's pay data and nothing else, without the finance manager losing the full picture.

A construction business operates separate entities per project or licence type. It has a different challenge: a shared pool of tradespeople and site supervisors who move between entities as projects start and finish. Payroll needs to follow them accurately, without the business creating a new employment record every time someone starts a job under a different ABN.

None of these businesses is an edge case. Multiple entities are a normal shape for a growing business to take, and the payroll problem is structural, not a planning failure.

What good multi-ABN payroll looks like

Whichever platform a business ends up using, six things matter:

1. One login, with a separate pay cycle for each entity. Admin staff shouldn't need a different system for each ABN. They need one place to work from, with each pay cycle still run and reported against the correct entity.
2. Reporting that respects the entity split. STP and other compliance reporting need to go out correctly for each ABN, without someone manually separating figures the system should have kept apart in the first place.
3. Granular access control. The business should be able to decide, pay cycle by pay cycle, who can see and process it, rather than choosing between full visibility across every entity and no access at all. This matters most in the scenarios above: external bookkeepers, site-specific payroll staff, and owners with a stake in only part of the group.
4. No re-setup when staff move. When someone moves from one entity to another, they shouldn't need a new employee record. Their leave balances and history should come with them.
5. Wage costs tracked by site. When staff work across entities, the system should show how much of their wages belongs to each one, without anyone splitting timesheets by hand.
6. A group-wide view for the people who need it. Separating entities shouldn't stop an owner or finance manager from reporting on payroll across the whole group.

These are worth asking of any payroll system before you commit to it. Here's how Microkeeper answers them.

How Microkeeper handles multi-ABN payroll

In Microkeeper, a business with more than one ABN runs from a single account. Each ABN gets its own pay cycles and its own STP reporting, and you decide who can see each one.

One login, a pay cycle for each ABN

Add each of your ABNs to your Microkeeper account, then set up pay cycles under them. Every pay cycle belongs to one ABN. When a pay run is processed, STP is reported under that entity automatically, so nobody has to separate the figures by hand.

For the franchise with four stores, that means four pay runs from one login, not four systems.

You choose who sees each entity's payroll

Access works in two layers, from broad to narrow:

1. Payroll access on the person's profile. Each staff member is set to Full Access (can process pay runs), Medium Access (view-only, plus locking the pay run and downloading the bank file) or No Access. Only people with Full or Medium Access can be given access to a pay cycle.
2. Access on each pay cycle. Each pay cycle is open to either the Whole Payroll Team or Selected Users only.

Take the hospitality group. Set each venue's pay cycle to Selected Users. Select the head office administrator on all three, and the bookkeeper on their one venue only. With Full Access, the bookkeeper can process that venue's payroll and see its reports, while the other two venues don't appear for them at all.

The practice group works the same way: each practice manager is selected on their own clinic, and the finance manager on all of them. The restriction applies across pay runs, payslips, reports, leave, and bank and super files.

Staff who move between entities

When one of the construction business's tradespeople moves onto a project under a different ABN, you move them onto that entity's pay cycle. They keep the same employee record and their leave balances. Pay already processed stays with the entity that paid it. There's no second profile to set up and no history to keep in sync.

Staff who work across sites

When a chef covers shifts at a second venue, or a practitioner sees patients at another clinic, they're still employed and paid under one ABN, with one employee record. Each shift is tracked against the location where it was worked, so cost centre reports show exactly how much of their wages belongs to each venue or clinic. Those cost centres carry through to your accounting exports, ready for recharging between entities.

Still one view of the whole business

Separating entities doesn't hide the bigger picture from the people who need it. Reports can include every pay cycle a user has access to. An owner or finance manager can report on payroll across all ABNs, while a site-specific payroll officer only sees their own.

All of this sits on the same data as Microkeeper's HR, rostering and timesheets. For setup steps, see our FAQ on Access Control with Multi-ABN and Payroll Teams.