Xero — An API, and No Database at All

Xero changed what small-business accounting software felt like. Bank feeds that arrived on their own, a reconciliation screen an owner could work without training, and — unusually for its market — an early public API with real documentation behind it. A large share of small businesses in the UK, Ireland, Australia and New Zealand run their ledger on it — not because of marketing: the product is pleasant to use and the data is deliberately made available. What follows is what that data can carry, where Xero’s scope stops, and what has to be built above it when the questions get harder than one company at a time.

At a glance

What Xero is

Xero is cloud accounting software for small businesses: sales invoices and quotes, bills, bank feeds and reconciliation, VAT or sales tax returns filed to the local authority, a general ledger behind all of it, and payroll in the countries where Xero ships it. It runs in a browser and a mobile app, on a monthly subscription per organisation — no server to run, no version to upgrade.

Two things deserve specific credit. The first is bank feeds: Xero built direct banking connections early and made reconciliation the daily habit the product organises itself around, which is why Xero ledgers are so often current rather than three weeks behind — and a current ledger is worth more to a reporting layer than structure in a stale one. The second is the API: published and documented long before competitors treated integration as a first-class concern, versioned, moved to OAuth 2.0, with an app marketplace Xero counts in the thousands built on top. That decision is why this article can describe a clean extraction route at all.

Xero is also honest about its own edges: its developer documentation says plainly that the product is not built for very high transaction volumes and points readers at the published system limits. A vendor that publishes the shape of its own ceiling is worth building on.

The plans, and what each one changes for finance

Xero sells plans rather than editions, and the names differ by market. The table is about the finance consequence of each tier.

One practical note: on any plan, multi-currency reporting needs a consistent translation policy above the ledger — a group presenting in a currency no entity uses is a layer-level problem by definition.

Who Xero fits

Owner-managed businesses that want the ledger current. The core case, and Xero is very good at it. Bank feeds, reconciliation, VAT filed from the same screen, an accountant looking at the same data. If this is the whole requirement, Xero on its own is a complete answer.

Businesses selling through several channels. E-commerce, wholesale and retail feeding one ledger, with the operational systems doing the operational work. This is where Xero most often reaches us: the accounting is fine and the question is not an accounting question.

UK and Irish businesses on Xero’s home ground. Xero’s country editions cover the UK and Ireland properly — local VAT, Making Tax Digital, the filings a local accountant expects. Where the edition matches the jurisdiction, Xero is the sensible default and often the incumbent.

The UK or Irish entity of a CEE group. There is no Slovak, Czech or Polish edition of Xero, so in our region it almost never runs the local books. Where it appears is one step removed: the parent and the trading companies run local systems, and the UK or Irish subsidiary runs Xero because that is the correct local choice. Getting that entity into the group numbers is the recurring question.

Groups that grew sideways. A UK company on Xero, a Slovak or Czech company on POHODA or Money, something else again in the entity acquired last year, and a stock or e-commerce system beside each. Every one of those choices was locally correct. Nobody owns the view across them, and that is the conversation this page exists to have.

What Xero holds — and why it is good material

A well-run Xero organisation is good material, and for a specific reason: the reconciliation habit. Because bank feeds arrive daily and the product is built around clearing them, data quality in Xero tends to be high and current in a way on-premises ledgers frequently are not. Against what we more often meet — a spreadsheet consolidation, a half-configured cloud tool, a year of manual journals — a current Xero ledger is a strong starting point.

The ledger itself is complete and traceable. Every posting carries its account, date, contact, tax treatment, currency and source document type. The Accounting API exposes the ledger both as documents — invoices, bills, payments, bank transactions, manual journals — and as posted journals, which is the difference between reading a business and rebuilding one, and the route that matters for profitability analysis .

Tracking categories are the analytical asset, and their limit is the honest part of the story. A Xero organisation supports two active tracking categories, each holding a capped number of options, tagged on invoice, bill, bank transaction and manual journal lines, and on payroll where payroll is in-product. Used deliberately that is real structure: cost centre and channel, or department and site, carried down to the line. Two is a design decision, not an oversight — Xero’s market is single companies who want one or two cuts of the P&L, and two well-implemented dimensions beat a configurable framework nobody fills in. It stops being enough the first time someone wants product by channel by region by customer group at once.

What sits outside Xero’s scope

Xero is scoped to running the accounting of one company well. Three things sit outside that scope, and each boundary was drawn deliberately.

The view across companies. One organisation is one legal entity, with its own subscription, chart of accounts and tracking categories — no consolidated organisation, no intercompany elimination, no group ledger. Xero does not claim otherwise: for group reporting it points customers to consolidation apps in its own App Store. It is also why a five-company group on Xero has five ledgers and a spreadsheet. For statutory consolidation and a management group view alike, the work happens above Xero — because there is no inside for it to happen in.

The view across systems. Whether e-commerce revenue matches the ledger, or warehouse stock matches the balance sheet. This is worth saying plainly: no ERP does this. Not Xero, not Business Central, not SAP. Cross-system truth is a layer above every transaction system, which is the point we make at more length here .

Analysis beyond two dimensions, held somewhere durable. Xero’s reporting is capable within its scope. What it cannot do is carry a third and fourth dimension, hold a data model that a dashboard or an AI assistant can query, or keep a definition of margin that survives someone editing a layout.

None of this is a reason to change system. It is a reason to add a layer.

How we elevate it

We connect Xero in single companies, in groups where Xero sits beside other ledgers, and — most often — in businesses where Xero is one of three or four systems that all have to agree.

Getting the data out has exactly one route, and being precise about it is most of the job. There is no database to read — Xero is a multitenant cloud service — so the well-documented API is the route: a registered application, OAuth 2.0 with refresh tokens, one connection per organisation. A four-company group is four connections, four consents and four independent rate-limit budgets. Extraction runs incrementally against modification timestamps rather than re-reading history, because the ceilings are real: five calls in progress at once, 60 calls a minute and 5,000 calls a day per organisation, plus 10,000 calls a minute across every organisation the application touches. Read-only throughout, nothing written back, and nobody working in Xero notices we are there.

What happens next is the Xero-specific work.

Building durable ledger history inside the API’s ceilings

The first job is a ledger history that does not depend on the API being available, fast, or unchanged. We take the posted journals rather than reassembling the ledger from documents, walk the full history once in batches, and land it in the governed layer where it stays. From then on the nightly run collects only what has changed, which for a normal Xero organisation sits inside the daily ceiling.

Two constraints shape the design. Xero applies a high-volume threshold to requests that would require it to process very large document volumes, and rejects them rather than serving them slowly — so extraction has to be narrow, filtered and incremental from the start, not one large query that works in testing and fails in the third year. And the rate-limit budget belongs to the organisation rather than to us, so a limit consumed by an unrelated app is a limit you no longer have. Holding history in our own layer takes the reporting off that dependency: the API becomes the delivery mechanism, not the archive.

Getting more dimensionality than two tracking categories can carry

Two tracking categories are two. The layer above is where the rest of the dimensionality lives, and it is built once rather than argued about monthly.

We map the Xero chart of accounts to a management structure — revenue by what you actually sell, cost by what you actually control, margin at the level you actually decide — and we hold the extra dimensions as attributes of the entities the ledger already references rather than as tags the bookkeeper has to remember. Customer becomes segment, region and channel. Product or SKU, joined from the operational system, becomes category, brand and range. The two tracking categories keep doing their job, and the model carries product by channel by region by customer without anyone reconfiguring Xero. We also audit how consistently the categories have been filled across history, which is usually the more valuable finding. The design problem underneath is the same one every system in this series has: chart of accounts architecture .

One view across every organisation, and every other system

This is where Xero’s scope boundary turns into ordinary work. Each Xero organisation becomes one entity in a common model, beside another Xero organisation, a POHODA or Business Central database, a Shopify store, a payroll export or a budget spreadsheet — all producing the same standardised output. Group reporting in any currency with translation applied consistently, reconciliation across systems rather than within one, intercompany elimination, and drill-down from a group total back to the Xero invoice that produced it.

This is routine rather than aspirational: we work with 70+ companies across 11 countries, on 12+ different ERP and accounting systems. See Group Reporting & Consolidation .

On the governed layer, the rest is the platform doing its standing job: daily reconciliation against the ledger so the close confirms rather than rebuilds, a semantic model that Power BI and AI can both query reliably , and your business context accumulating so answers get sharper the longer it runs.

What becomes answerable

• Which customers and channels are actually profitable, after fulfilment and channel cost — not just gross margin on the invoice?
• What is group EBITDA in one currency, when two entities are on Xero and two are on something else?
• Does storefront revenue agree with ledger revenue this month, without anyone exporting anything?
• Which products make money by channel and by region at once — four cuts, not two?
• How much cash is tied up in stock that has not moved in six months, and what does that do to cash flow next quarter?

Every one of these is answered from data Xero and its neighbours already hold. The information was there. What was missing was the structure to ask.

What it takes, and what does not change

Connection in days. First reports in the first week. For a single-entity Xero client, the connection is a read-only login and the first governed reports follow inside a week. A full build — management chart of accounts, dimension repair, consolidation across several entities, the reporting suite — runs in phases over the following months. The distinction matters, and we would rather be precise about it than promise a finished model in a fortnight.

What we need from you: an NDA, read-only access, and a conversation about what the numbers should mean.

What does not change: Xero stays your system of record. Your accountant keeps working the way they work. No migration, no data cleanse project, no retraining, nothing written back.

Read-only access throughout. Your data stays in an EU-hosted Azure environment, aligned with ISO 27001 and GDPR, governed by you.

In practice

JING Tea — Xero alongside Shopify and CIN7

A premium London tea brand selling through direct e-commerce, wholesale to hotels and restaurants, and international retail. We have run their management reporting for three-plus years. The layer began by unifying Sage 200 accounting and inventory, manual inventory feeds and hand-built budgets into one consolidated view — the multi-source reporting problem, solved once.

Then the business replaced its entire operating stack: Sage 200 out, Shopify, Xero and CIN7 in. The same layer absorbed the change. No history was migrated, there was no reporting blackout, and the management view stayed the same through the switch. Sage-era history remains on Sage; new data flows in from Shopify, Xero and CIN7; the layer pulls both eras into one model on the same chart of accounts, the same channels and the same drill-down from P&L to sales order. A marketing data feed is being added on the same foundation, and Claude AI is connected so the team can ask questions in plain English against numbers that already reconcile.

Worth being precise about what this proves. Xero is the accounting system in that stack, not the whole of it — Shopify sells, CIN7 holds stock and operations, Xero holds the ledger. Three systems, each correct in its own domain, and one governed layer above them where the numbers meet. That is the normal shape of a Xero estate, not an unusual one.

When the system underneath changes

Xero is often the arrival rather than the departure — it replaces something a business has outgrown, and it usually lands well. Occasionally it is replaced in turn, when entity count or operational complexity outgrows a single-company cloud ledger — the usual destinations are the mid-market ERPs covered elsewhere in this series .

Either way, because the governed layer sits above the ledger, only the connection changes. The data model , the reports, the dashboards and the consolidation logic stay as they are. Clients who built the layer first find the migration measurably easier: they can prove the new system’s numbers against the old from day one, and they keep their reporting history through the change.

This is not a theoretical claim. When JING Tea replaced its operational stack, the reporting layer carried through the change unaltered — the systems underneath moved, the numbers and the reports did not. The layer that survived that migration is the layer reading Xero today.

How Xero compares

Xero is one of several capable systems in the estates we work in. Each has its place in the series .

From a data-layer perspective the choice matters less than it appears. Each becomes a source in the same governed model, which means the system decision can be made on operational fit rather than on reporting fear. The full matrix — including the Polish stack — is on the series hub .

Frequently asked questions

Do we need to replace Xero to get proper management reporting? No, and we would usually advise against it. Keep Xero for what it does well — clean transaction capture, bank reconciliation, VAT and local compliance, an accountant who knows it — and build the reporting layer above it. Replacing a working ledger to solve a reporting problem is an expensive way to solve the wrong problem.

Is Onetribe a replacement for Xero? No. Xero remains your system of record and your team keeps using it exactly as they do now. We read from it, never write to it. If you change system later, the reporting layer stays.

Is Xero an ERP or accounting software? Accounting software, and Xero says so. It carries the ledger, invoicing, bills, banking, VAT and — in some countries — payroll, but no manufacturing, warehousing or multi-entity group structure. In practice a Xero business runs an operational system beside it, which is why the reporting question is a cross-system question.

What database does Xero use, and can we read it directly? There is no customer database access to Xero at all — no SQL connection, no ODBC driver, no restorable backup file. That is the consequence of running a multitenant cloud service, not a documentation gap. The Xero API is the only data route, and it is a properly built one.

Can Xero connect to Power BI? Yes, through the API, and the design choice matters more than the connection. A report tool pointed straight at Xero spends the organisation’s API budget on every refresh — the same ceilings described above, shared with every other connected app. The durable pattern is to extract once on a schedule into a governed model and build BI reporting on the model, which also holds ledger history independently of what the API will serve today.

Can Xero consolidate several companies? No — one Xero organisation is one legal entity, and there is no consolidated organisation or intercompany elimination inside the product; for a small business that is correct design. For a group it means consolidation happens above Xero — in a governed layer rather than a spreadsheet, so the group number stays drillable back to the invoice, with data governance that survives the person who built it.

Does Xero have an API, and what are its limits? Yes, and it is a genuine strength — REST and JSON, OAuth 2.0, separate APIs for accounting, payroll, files, assets, projects and bank feeds, one connection per organisation. Serious use is shaped by the published ceilings and the high-volume threshold covered in the extraction section above. A complete nightly ledger extract is entirely possible; it has to be engineered rather than improvised.

Is Xero’s own reporting enough? For one company, often yes — and worth exhausting before adding anything. It runs out in the same three places: across organisations, across systems, and anywhere a third or fourth dimension is needed. If Xero is your only system and one company is your whole business, start there and come back when that stops being true.

Official Xero resources

• Xero API rate limits — the documented ceilings
• Xero product and pricing — xero.com
• Xero Developer portal
• Accounting API overview
• OAuth 2.0 API limits and system limits
• Limits FAQs — rate limits per organisation
• Xero Central — product help and support
• Xero App Store

Onetribe is not a Xero partner or reseller. We build the governed data layer above your ERP, whichever ERP that is.

Next steps

• Every source system we connect — the series hub, with the full matrix
• How we consolidate any combination of systems — group reporting
• Why your ERP doesn’t govern your data — the cross-system layer, in detail
• Discuss your Xero estate — free assessment