Why Xero Still Has No Safe Read-Only Role

There is a gap in the middle of Xero’s permissions model, and most teams run into it the same way. Someone in sales needs to check whether an invoice was paid. A project manager wants to see what was billed. Neither of them should be able to change anything, and neither of them needs access to the rest of the books.

Xero has roles that are narrow. Xero has a role that is read-only. It does not have one that is both.

Last verified: September 2026.

The asymmetry

Put Xero’s roles on one axis and the problem is easy to see.

The narrow roles, the four sales and purchases variations, limit which parts of Xero someone touches. All four can still create records. Three of them can approve.

The read-only role, Viewer, genuinely cannot write. It also cannot be pointed at one customer or one project. It views most of the organization.

So the choice for “let this person check an invoice” is between a role that can also issue one and a role that can also read the rest of the books.

The narrow roles are not read-only

Xero groups four roles as variations of sales and purchases. Here is what each can do, in Xero’s own terms. The labels below follow Xero’s Rest of world edition; the US edition names these four roles differently, so check the exact names in your own organization:

Role	Can create	Can approve
Draft sales and purchases	Draft invoices, bills, quotes, purchase orders	No
Sales	Invoices, quotes, customer credit notes	Yes, and can record payment on invoices
Purchases	Bills, supplier credit notes, purchase orders	Yes, and can pay bills
Sales and purchases	All of the above	Yes, both sides

Even the most restricted of the four writes records into Xero. Draft sales and purchases cannot approve anything, and a draft is not a posted transaction, but it still creates records that someone else now has to review, approve, or delete. That is a reasonable role for a data entry assistant. It is the wrong role for a person who only wants to look something up.

There is no variation of these roles that removes the create rights and keeps the narrow scope. The narrowness and the write access come together.

The read-only role is not narrow

Viewer is the role people reach for when they want view-only access, and it does the read-only part properly. A Viewer cannot create or edit transactions, and cannot run new reports.

The breadth is the problem. Viewer has access to sales, purchases, contacts, classic expense claims, fixed assets, and reports, budgets and manual journals. Xero’s own compare table also notes that a Viewer can see bank balances, balance in Xero, and account transactions in Xero, though not imported bank statements.

That is a sensible design for someone who is supposed to have oversight of the whole organization. It is a lot to hand a warehouse supervisor who wanted to know whether a purchase order was approved.

Note what is not on the list of things you can restrict. You cannot give Viewer access to one customer. You cannot scope it to a tracking category, a project, or a single bank account. Xero’s permissions are organized by functional area, and the area is the smallest unit available.

Where Xero does narrow, it narrows by authorship

Xero is not incapable of fine-grained access. It just uses a different axis than most people expect.

Look at the places Xero goes below the role level. Projects has an “Edit own only” permission, where a user sees their own time entries, projects, and tasks. Expenses has a Submitter role, where a user enters and submits their own expenses. The Documents upload-only permission, which you can give an Employee user, lets them upload to the file library and view their own files.

In every case the narrowing is by who created the record, not by which customer or account it belongs to. That works when the records are personal, like your own timesheet. It does nothing for the sales rep who wants to see invoices for their accounts, because those invoices were created by finance.

This is the honest answer to the most common question about Xero permissions, and it is worth stating plainly: the only per-record narrowing Xero offers is “records you made yourself.”

Connecting AI does not fix it

The obvious next thought is that an API connection could be more precise than the UI. Scopes look like the tool for the job. They are not, and it is worth understanding why before you design around them.

A Xero scope names a resource area and an access level. accounting.invoices.read is a resource plus a verb. There is no place in that grammar for which invoices. So a scope decides which endpoints an app may call, not which rows inside those endpoints it gets back. Read access to invoices can still mean read access to the organization’s invoices.

The second half matters more. Xero’s developer FAQ is explicit that a connection belongs to a person:

The user that connects the integration has to have either Standard, Adviser, or Administrator level user with the Connected Apps permission.

The API essentially works on behalf of the user that authorised it to connect.

Two things follow. A Viewer cannot authorize an app at all, so the read-only role cannot be the basis for a read-only connection. And the connection is set up by someone with broad access, which is the opposite of the narrowing you were trying to achieve. Xero adds further conditions on top: Reporting APIs and the /ManualJournals and /Journals endpoints need the authorizing user to have Reports access, and the Payroll APIs need Payroll Admin.

What Xero does not publish is a precise rule for how that user’s access maps to the rows a given endpoint returns. Note the hedge in “essentially.” If your design depends on that mapping, test it against your own connection rather than assuming it. Xero MCP Scopes Explained goes through the scope model in detail.

The short version: a correctly scoped read-only AI connection is still a connection made by a broad-access user, inside endpoints that were never row-filtered to begin with. Scopes are a real control. They are not a permissions model for people.

What to do instead

If the requirement is genuinely “this person needs to see everything and change nothing,” Viewer is the right answer and you should use it.

The requirement is usually narrower than that, and it usually belongs to someone who does not need a Xero seat at all. A sales rep checking payment status, a service tech confirming what was billed, an ops lead looking up a purchase order: each wants one fact, occasionally, and none of them should be learning Xero’s interface to get it.

That is the problem Kipper is built for. People ask in Slack, Microsoft Teams, SMS, or chat, and Kipper answers from a read-only connection to Xero. It cannot create, edit, approve, or delete anything in your books. Access is configured per person in Kipper rather than per Xero role, so you are not choosing between a seat that can write and a seat that sees most of the organization.

One boundary worth being direct about, since Viewer’s bank access came up above: Kipper does not read Xero bank data. No bank account balances, no individual bank feed transactions, no imported bank statements, no reconciliation status. What it answers from is the operational record layer, such as contacts, invoices, payments, bills, bill payments, purchase orders, items, credit notes, and supplier credits, plus the Xero trial balance, profit and loss, and balance sheet reports.

For the full role-by-role detail, see Xero user roles and permissions. For how AI connections to Xero work generally, start with the complete guide to Xero MCP, or see the hosted Xero MCP connector if you would rather not manage scopes yourself.

FAQ

Can I restrict a Xero user to a single customer?

No. Xero permissions work by functional area across the whole organization. There is no way to limit a user to one customer, one tracking category, one project, or one bank account. The closest Xero gets is showing someone only the records they created themselves.

Does Xero have a read-only user role?

Yes, the Viewer role. It cannot create or edit transactions or run new reports. What it is not is narrow. Viewer can view most areas of Xero, including sales, purchases, contacts, fixed assets, and reports, budgets and manual journals, and it can see bank balances and account transactions in Xero, though not imported bank statements.

Do Xero scopes stop an AI from seeing everything?

Not by themselves. A Xero scope names a resource area and an access level, such as accounting.invoices.read, so it decides which endpoints an app can call rather than which records inside them it can see. Xero also requires the person authorizing an app to be a Standard, Adviser, or Administrator level user, so a Viewer cannot set one up.

Which Xero roles can approve transactions?

Administrator and Standard, plus Sales, Purchases, and Sales and purchases. Draft sales and purchases can create invoices, bills, quotes, and purchase orders but cannot approve them. All four of the sales and purchases variations can still create records, so none of them is read-only.

Sources

• Xero Central, “User roles and permissions in Xero,” Rest of world edition. The compare-roles matrix comes from here, read 15 September 2026. Xero Central renders client-side and its articles carry no publication date, so this one is cited by title and read date rather than by link.
• Xero Central: User roles and permissions in Xero (US Business edition). The additional permissions list comes from here. Xero publishes region-specific versions of this article, so confirm role and permission labels against the version your organization sees.
• Xero API permissions FAQ
• Xero OAuth 2.0 scopes