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, which means each one needs its own pay run, its own Single Touch Payroll (STP) reporting, and its own compliance trail, even it, from the outside, the business looks and operates like one company. 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.

This is 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 service firms built around trust and holding companies all commonly operate under more than one ABN. If you're one of them, or advising one, this is what actually changes about payroll, and what to look for in a system that handles it properly.

Why do businesses end up qith more than one ABN

There’s rarely a single reason. A few structural patterns come up again and again:

Franchise agreements often require each store or territory to be its own legal entity, separate from the franchisee’s other locations. Liquor licensing in hospitality frequently forces each venue onto its own ABN, since licences are tied to the entity, not the brand. 

Healthcare and allied health groups commonly register each clinic separately for billing and Medicare provider reasons, even when the practitioners and the back-office team are shared across sites. 

Aged care and disability service 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, per region, or per licence type, while still drawing from one shared labour pool. And plenty of professional services firms are structured around trusts and related companies for tax and liability reasons that have nothing to do with how the business actually operates day to day.

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

What actually gets difficult about payroll once you have multiple ABNs

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

This is the part that trips people up the most, and 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 those three ABNs separately. That’s not a limitation of any particular payroll system, and it’s not something you can consolidate away, it’s how STP works for any structure with more than one ABN. The confusion usually isn’t about whether this is required (it is), it’s about whether the software they’re using makes it manageable or makes it painful.

Duplicate systems and duplicate admin work

The most common workaround is running a completely separate payroll subscription per 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 operating business. Multiply that by however many entities are in the group, and payroll day becomes several payroll days stitched together manually.

Staff who work across entities

Plenty of businesses in this position have employees who work across more than one entity in the group: a chef who covers shifts at two venues under different ABNs, or an allied health practitioner who sees patients at more than one clinic in the same group. Handled badly, this means duplicate employee records, inconsistent leave balances between the two versions of that employee, and manual reconciliation every pay cycle to make sure hours, leave and entitlements line up.

Who should be allowed to see which entity’s payroll

The bigger the group, the more this matters. A payroll officer who only handles one venue’s wages shouldn’t necessarily be able to see the whole group’s pay data. An external bookkeeper brought in for one entity shouldn’t have visibility over the others. This is a genuine separation-of-duties and confidentiality issue, not just a nice-to-have, and it’s one that a lot of payroll systems don’t handle well, because they’re built around the assumption of one entity, one team, one set of permissions.

Real-world examples

A hospitality group running three venues, each under its own ABN for liquor licensing reasons, might have a head-office payroll administrator who needs to process all three pay runs, plus a bookkeeper who only handles one venue for the owner who part-owns just that site. Without proper entity-level access control, that bookkeeper either sees everything or has to be locked out of the system entirely and sent reports manually. Neither option is good, one is a confidentiality problem, the other is extra admin work nobody asked for. 

A franchise running four stores, each incorporated separately per the franchise agreement, is really running one payroll operation from a staffing and scheduling point of view, the same regional manager rosters staff across all four stores, but needs four separate, correctly reported pay runs at the back end. If the roster and the payroll system don’t agree on which store an employee worked in on a given day, someone ends up manually reconciling it before the pay run can go out. 

A healthcare practice group with clinics registered as separate entities for Medicare billing reasons might have practitioners who see patients at two or three of those clinics in a given week. Their hours need to be tracked and paid correctly against the right entity, without the admin team manually splitting timesheets after the fact. This is a common source of pay errors in practice groups, not because anyone’s being careless, but because splitting one person’s hours across entities by hand, every fortnight, is exactly the kind of task that produces small mistakes at scale. 

A construction business operating separate entities per project or per licence type often has the opposite problem: a smaller 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 having to duplicate their employment record every time they move onto a job under a different ABN.

None of these businesses are edge cases. They’re a normal shape for a growing business to take, and the payroll problem is structural, not a planning failure.

What good multi-ABN payroll actually looks like

Regardless of which platform a business ends up using, a few things matter for this to actually work well. 

One login, entity-separated pay cycles. Admin staff shouldn’t need to log into a different system per ABN. What they need is one place to work from, with each pay cycle still run and reported against the correct entity behind the scenes. 

Reporting that respects the entity split. STP and other compliance reporting need to go out correctly per ABN, without someone manually separating figures that the system should have kept apart in the first place. 

‍Granular access control. The system should let a business decide, per pay cycle, who can see and process it, not force an all-or-nothing choice between full visibility across every entity and no access at all. This matters most in exactly the scenarios above: external bookkeepers, site-specific payroll officers, and owners who only have a stake in one part of the group. 

‍No duplicate employee administration. Staff working across entities in the same group shouldn’t need to be set up as if they’re two different people, with two leave balances and two employment histories to keep in sync manually. 

‍A consolidated view for whoever needs to see the whole group. Entity-level separation shouldn't come at the cost of an owner or finance manager being able to see how the business is performing as a whole, when they’re the one person who’s supposed to have that visibility.

There are the questions worth asking of any payroll system before committing to it, not just Microkeeper. 

How Microkeeper handles multi-ABN payroll

Microkeeper supports multi-ABN payroll natively, with access control built specifically around it rather than bolted on. Every pay cycle in Microkeeper is linked to a specific ABN, and access to that Pay Cycle  is linked to a specific ABN, and that access is controlled separately from a user’s general Access Control settings. 

There are two ways to set who can access a given Pay Cycle:
Whole Payroll Team means anyone in the business with Payroll Access can see and process it. 
‍Selected Users restricts it to specific named team members, useful for exactly the bookkeeper-of-one-venue scenario described above. Only people who already hold ‘Payroll - Full Access’ or ‘Payroll - Medium Access’ on their employee profile are eligible to be assigned in the first place, so it sits on top of the existing permission structure rather than replacing it. 

In practice, that gives a business a layered system: general Access Control sets the baseline, Payroll Team Access determines who’s assigned to a given entity’s payroll at all, and Pay Cycle access governs which specific cycles that person can actually open. A payroll officer can be given access to one venue’s cycles and nothing else. A head office administrator can be given the whole group.

Full detail on how this is configured is covered in our FAQ on Access Control with Multi-ABN and Payroll Teams, including where to set it up.

This sits alongside the rest of Microkeeper’s platform: HR, rostering and timesheets using the same data as payroll, so staff working across entities within a group don’t need duplicate employee records maintained separately just to keep the ABNs apart.