How to approve bills across multiple Xero organisations

You cannot, inside Xero. Each organisation is a separate ledger with its own approval state, and Xero deliberately keeps one open at a time — so approving across a group means either switching organisations one by one, or putting a layer above them that reads and writes to each. There is no third option, and no setting that changes this.

That is worth stating plainly because the search for a setting is where most finance teams lose a fortnight.

Why can’t you approve bills for two Xero organisations at once?

Because Xero has decided you should not be able to, and has said so. The request to open multiple organisations in different browser tabs is one of the longest-running items on Xero’s own product ideas forum, and the answer has been consistent: there are no plans to enable it. The stated reason is data integrity — if two organisations were open in one session, a bill entered against the wrong one would create a permanent audit trail in the wrong ledger, and Xero has no undo for that.

Whether or not you like the trade-off, it is a considered architectural position rather than a missing feature. That matters for planning, because it means waiting for Xero to fix it is not a strategy. The common workaround — a second browser, or an incognito window per entity — tells you how firm the constraint is. Nobody adopts a second browser for a problem that has a settings toggle.

What does Xero’s native bill approval actually do?

It moves a bill through three states: Draft, Awaiting Approval, and Awaiting Payment. Someone with the right permission promotes it from one to the next.

That is the whole mechanism. There is no routing by amount, no routing by account code or department, no sequential chain where a second approver only sees the bill once the first has signed off, and no delegation when someone is on leave. A user either can approve bills in that organisation or cannot.

For a single company with one person approving, this is genuinely sufficient, and adding a tool on top would be overhead for nothing. The strain appears at two boundaries: when approval needs to depend on the bill rather than on the person, and when the same person needs to approve across several organisations.

What breaks first when a second entity appears?

Consistency, before convenience. The approval rule now lives in two places and drifts.

The mechanics are survivable at first — switching organisations is a few clicks, and at two entities and a handful of bills a week that is an irritation rather than a problem. What degrades quietly is that “anything over $10,000 goes to the group finance director” exists as an understanding rather than as a rule the system enforces. In one organisation the threshold is applied. In the other, the bookkeeper who joined in March has never heard of it. Nothing alerts anyone, because from inside either ledger nothing is wrong.

The second failure is visibility. Answering “what is waiting for approval across the group right now” means opening each organisation in turn and writing the answer down somewhere else. At three entities that is a five-minute job nobody does weekly. At ten it is not done at all, which is usually when a supplier calls about an invoice that has been sitting in Awaiting Approval since June.

What are the real options?

Three, and the honest ranking depends on entity count and how much the approval rules vary.

Switch organisations manually. Free, and correct for two entities with simple rules and one approver. The cost is invisible until it is not: no cross-entity view, no enforcement, and a control that exists only as long as the person who remembers it stays.

Add an approval layer over the Xero files. ApprovalMax is the established option here and does the core job well — one inbox showing approvals from every connected organisation, multi-step chains, and rules by amount. The usual pattern is to build the workflow once and clone it per entity, adjusting approvers. Worth knowing that cloning means the rules are consistent at the moment you clone them; keeping them consistent afterwards is still a manual discipline across however many copies exist.

Use a system where the group is the unit, not the entity. This is what APBuddy does: approval rules, thresholds and roles are defined once for the group and apply across every connected Xero organisation, so there is one workflow rather than one per file. It also means the same layer can see spend that spans entities — a duplicate invoice entered in two companies, or a subscription being paid twice.

If you have two entities and one approver, take the first option and spend the money elsewhere. The case for a layer starts around three or four entities, or earlier if approval routing has to vary by amount or department.

How do you keep approval rules consistent across entities?

Write the rule down once, outside any Xero organisation, and treat that as the source of truth — then make the system enforce it rather than relying on people to remember it.

In practice that means being explicit about four things, for the group rather than per entity:

• Thresholds. What amount changes who approves, and is it per bill or per supplier per month?
• Sequence. Whether approvals are parallel (anyone) or sequential (this person, then that one), and what happens when the two disagree.
• Coverage. Who approves when the named approver is away — a nominated deputy, or an escalation after a set number of days.
• Exceptions. Which categories skip the chain entirely. Rent and payroll usually should; a new supplier never should.

The test of whether it is written well enough is that someone who joined last week could apply it without asking. If applying it requires knowing that Sarah handles the northern entities, it is not a rule, it is a habit.

When is a new supplier the thing to control, rather than the invoice?

When the invoice arrives, the decision has already been made — so the control that actually prevents spend sits before it, at the point someone commits.

This is the reason approval and procurement end up in the same conversation. Approving a bill from a supplier nobody onboarded, for work nobody raised a purchase order against, is a review rather than a control: the money is committed and the only remaining question is whether to pay late. Groups that get this right move the decision earlier — a request before the engagement, a purchase order before the work, onboarding before the first invoice — and the bill approval becomes a check that the invoice matches what was already agreed.

That sequencing matters more across entities than within one, because a supplier engaged by one company in the group is frequently paid by another.

Does any of this change once entities are consolidated for reporting?

No — consolidation is a reporting exercise and happens after the fact, so it inherits whatever the approval process let through.

It is worth saying because the two are often bought together and they solve different problems. Consolidated reporting tells you what a group spent once the spend has happened. Approval routing decides whether it happens. A duplicate invoice paid in two entities appears in consolidation as an accurate total of two payments that should have been one. The reporting is not wrong; the control was missing several weeks earlier.

If you are choosing between the two and the pain is “we cannot see the group’s numbers”, start with reporting. If the pain is “we found out afterwards”, start here.