Xero's Permission Rebuild: What Changes for Connected Apps

Xero is rebuilding its user permissions model, replacing an all-or-nothing system where granting someone access to raise a purchase order also handed them supplier bills and other unrelated data, with more granular, job-based roles, according to Xero's own product update. For teams connecting Xero to other systems, the near-term risk is not that your integration breaks today. It is that a client tightening permissions in the Xero UI can now restrict a human user more precisely than your OAuth connected app can restrict itself, because the API's scope model has not caught up to the same granularity yet.

What did Xero actually change about user permissions?

Xero's new permissions rebuild lets admins grant a user access to one job, like raising a purchase order, without automatically exposing supplier bills, bank feeds, or other adjacent data that used to come bundled in. Xero describes the old system as working "a bit like a house key: you either hand it over or you don't," and says the redesign responds to years of specific, practical requests surfaced through its Product Ideas forum, like letting someone see stock without opening the whole bank feed.

The rollout so far covers Business Edition plans globally, with one exception: timesheet permissions are live only in Australia, and only for accounts on Xero's newer timesheet experience. Xero says existing permission assignments are not changed by the rollout and that it plans to keep extending granular controls "area by area" based on demand it is tracking through Product Ideas.

Why does this matter for OAuth connected apps, specifically?

Because the thing being rebuilt is the human-facing permissions screen inside Xero, not (yet) the OAuth scope model that connected apps authenticate against. Those are two different systems that happen to describe overlapping data, and right now they are moving at different speeds.

Xero's OAuth scopes already went through a similar granularity push. The Xero Developer scopes documentation shows the old accounting.transactions scope marked deprecated, with a set of new scopes, accounting.invoices, accounting.payments, accounting.banktransactions, and accounting.manualjournals, meant to replace it so an app only requests the slice of transactional data it actually uses.

That is good progress. But look closer at what accounting.transactions still covers while it remains active: BankTransactions, BankTransfers, BatchPayments, CreditNotes, ExpenseClaims, Invoices, LinkedTransactions, ManualJournals, Overpayments, Quotes, Payments, Prepayments, PurchaseOrders, Receipts, and RepeatingInvoices. Several of those objects, including PurchaseOrders, do not yet have a dedicated granular scope of their own. An app that needs purchase order data still has to request the broad, deprecated scope, which also grants it bank transactions and credit notes it may never touch.

That is the exact mismatch Xero's permission rebuild calls out on the human side: letting a contractor "raise a purchase order and stop there" is now possible for a person, but an integration asking for the same single capability through the API cannot yet scope itself that narrowly.

Where does the UI-vs-API gap actually bite an integration?

Three places we'd flag if you run connected apps against Xero today:

1. Client-side permission audits start asking questions your app can't answer. As finance and ops teams use the new granular roles to tighten who can see what, security reviewers naturally turn the same question on connected apps next: "why does this integration have bank transaction access when it only ever touches invoices?" If your app's OAuth consent screen still lists accounting.transactions, you don't have a clean answer yet, because the narrower scope for the object you actually need doesn't exist.

2. Re-authorization becomes a support event, not a background task. Xero's scopes are additive: moving a connection to a new set of scopes means sending the user back through the OAuth consent flow again, per the scopes documentation. If Xero does eventually split out an accounting.purchaseorders scope and you want to adopt it to shed unnecessary access, every connected organization has to re-consent. Plan for that as a migration, not a config flag.

3. The permission a human has in Xero's UI is not a reliable proxy for what your app's token can do. If your integration logs in as, or acts on behalf of, a specific Xero user, remember that the new granular roles govern that person's UI access, not the separate OAuth scopes your app's connection was granted. An admin can lock a contractor down to purchase orders only and still have no effect on an API connection authorized under the broader legacy scope. Don't assume tightening one tightens the other.

Will Xero bring OAuth scopes in line with the new UI permissions?

We don't know yet, and we want to be direct about that rather than guess. Xero's product update commits to extending UI permissions "area by area," and its scopes documentation shows an active trend toward splitting broad scopes into narrower ones. But as of this rebuild's announcement, Xero has not published a stated plan to align OAuth scopes one-for-one with the new permission model (unverified claim, not found in any Xero source as of this writing). Treat a future purchase-order-specific scope, or similar splits for Quotes, CreditNotes, and the other objects still bundled under the deprecated scope, as a reasonable bet based on the pattern, not a confirmed roadmap item.

The same week Xero published the permissions update, its application security team published a piece on why judgment has to keep pace with AI-accelerated development, arguing that the tools speeding up building are speeding up attacks just as much. Read together, the two posts point the same direction: Xero is treating access control as a moving target it expects to keep tightening, not a one-time project. Build your integration's scope requests assuming the floor will keep rising.

How does this compare to other platforms tightening connected-app access?

Xero is not alone this cycle. NetSuite is forcing a hard cutover from token-based auth to OAuth 2.0 that will break unmigrated connectors by its 2027.1 release, and Microsoft and HubSpot both shipped auth changes in October that broke integrations relying on old assumptions. The pattern across all three: platforms are narrowing what a connected app can get away with requesting, usually ahead of any enforcement deadline, which means the integrations that get caught out are the ones that over-scoped early and never revisited it.

If you are also building agent-facing access into Xero, note that the same granularity questions extend to Xero's Developer Remote MCP Server, the hosted MCP endpoint Xero runs for AI clients like Claude Desktop or custom agents. An agent connecting through MCP still authenticates through the same OAuth scope model described above, so a model with standing access to accounting.transactions has the same unnecessarily broad reach as any other connected app, arguably a bigger concern given how agents chain actions autonomously.

What should you do now, before Xero changes anything else?

Audit your current Xero OAuth scope list against what your integration actually reads or writes. If you're requesting accounting.transactions purely for PurchaseOrders or Quotes, document why, because that scope also grants access to bank transactions and payments you likely don't need. When Xero does ship narrower scopes for those objects, you want a short list of connections to migrate, not a rediscovery project.

Second, don't build logic that infers API access from a user's Xero UI role. They are separate systems today. If your app needs to know what a connected organization's data access actually looks like, check what your OAuth token's granted scopes allow, not what the connecting user can click on inside Xero.

Third, treat your next scope migration as a user-facing re-consent flow, not a silent upgrade. Because scopes are additive and re-authorization is required to change them, write the migration path and the client-facing message for it now, before you're doing it under a Xero-imposed deadline instead of on your own schedule.

FAQ

Does Xero's permission rebuild change anything about my app's existing OAuth connection? Not directly. The rebuild is live in Xero's user permissions screen, which governs what signed-in humans can do. It does not change OAuth scopes, so your app's existing connected-app authorization is unaffected until Xero ships a corresponding change to the scopes model.

Is there a granular OAuth scope for PurchaseOrders yet? No. As of Xero's current scopes documentation, PurchaseOrders is still covered only by the deprecated accounting.transactions scope alongside several other transaction objects, not a scope of its own.

Which Xero OAuth scopes are already deprecated? accounting.transactions and accounting.transactions.read are marked deprecated in favor of accounting.invoices, accounting.payments, accounting.banktransactions, and accounting.manualjournals (plus their .read variants), per Xero's scopes guide.

Does tightening a user's permissions in Xero also restrict my integration's API access? No. A connected app's access is governed by the OAuth scopes granted when the connection was authorized, not by the Xero UI role of the person who connected it. Restricting a user in the permissions screen does not retroactively narrow an existing API connection.

Where this leaves integration builders

Xero is signaling, through both the permissions rebuild and its security team's public commentary, that access control is getting more deliberate across the board, on a timeline it controls. The safest position for any team connecting custom systems to Xero is to request only the scopes you use today and to have a tested re-consent path ready for when narrower scopes for PurchaseOrders, Quotes, and the other remaining bundled objects eventually ship.

If you're weighing whether to build and maintain that scope hygiene in-house or bring in a team that has already done it across proven platforms, fluidlabs has built Xero integrations as part of our Docusign IAM work and can help you design an access model that survives the next platform change instead of reacting to it. Talk to the fluidlabs team about auditing your current Xero scope footprint before Xero's next permissions update makes the gap harder to ignore.