Services
Monthly bookkeeping run entirely in Xero — closed, reviewed and proven every period by the team that does the work.
Bookkeeping packages
The Xero Handbook
The app store is one of the reasons people choose Xero, and one of the reasons some Xero files become unreadable. Connecting is easy. Deciding what should connect, how it should post, and who owns it when it quietly stops working is the part that takes judgement.
First principle
Xero is a general ledger with a reconciliation engine and an invoicing front end. It is deliberately not a warehouse system, a payroll engine, a procurement tool or a reporting suite. That restraint is why it stays usable, and it is the whole reason the app layer exists.
Which leaves a choice for everything Xero does not do natively. You can run it in a spreadsheet, run it in a connected system, or force it into the ledger by making Xero hold operational detail it was never designed for.
The third option is the most common and the most expensive. Stock levels tracked through journal entries, project profitability reconstructed from account codes, purchase approvals living in an email thread that ends at a bill. It works until it does not, and by then the ledger is where operations live and nobody can close the month without unpicking it.
The rule worth holding on to: Xero should hold the accounting consequence of an event. The system where the event happens should hold the detail behind it.
The filter
An integration is not free because the subscription is small. It is a system someone has to own, monitor, and eventually unwind. Two tests decide whether it is worth that:
If neither test is met, what you have is a subscription with a login. And before connecting anything that passes, three questions are worth answering out loud:
It is almost always the second one doing the same job. Two overlapping tools posting to the same accounts is where most duplicate transactions come from, and the duplication is rarely obvious, because each app is behaving exactly as configured.
Design decision
Integrations differ less in what they connect than in the shape of what they post. There are three shapes, and the one you pick determines how the file reconciles for as long as the connection exists.
| Shape | What lands in Xero | Works when | Goes wrong when |
|---|---|---|---|
| Transaction level | Each invoice, bill or payment as its own document | Volume is low to moderate and someone genuinely needs per document detail in the ledger | Volume is high. The file slows, and the reconcile screen becomes something people avoid |
| Summary journal | A periodic journal, usually daily, carrying totals by account | A high volume channel where the detail belongs in the source system anyway | The journal does not tie to the bank deposit, or the summary quietly nets a fee you never see |
| Two way sync | Records kept aligned in both directions: contacts, items, sometimes invoices | Master data has to be consistent in two places and one side is clearly authoritative | Both sides can edit the same field. The last write wins, and nobody is told |
The shape decision is not only a question of taste. Xero publishes hard limits on how much an integration can push through its API, and those limits apply to every app on the platform equally.
Syncing a single invoice rarely costs a single call, because the contact, the document and the payment are separate operations. That arithmetic is the mechanical reason a busy sales channel posting every transaction individually eventually falls behind, and why a daily summary keeps working. Current limits are published on Xero’s developer site.
This choice belongs on the short list of things that are painful to reverse. Switching a sales channel from detail to summary after a year means unpicking months of postings and rebuilding the comparatives. It is worth deciding deliberately at setup rather than accepting whichever default the app ships with. The other decisions in that category are on the setup and migration page.
In practice

Roughly in order of how easily each one justifies itself:
Zapier, Make and the low code builders belong in a different category from everything above. They hold nothing. They move events between systems that have no native connection, and for that they are genuinely useful: a signed contract creating a task, an approved bill triggering a notification, a form submission reaching the CRM.
The line worth drawing is at the ledger. A workflow tool that creates invoices, bills, contacts or payments in Xero is a bookkeeping process with no owner, no reconciliation, and no audit trail beyond a run history somebody has to remember to open. It breaks on renamed fields, changed schedules and expired authorisations, and nothing announces it. The first sign is a month that will not close.
This matters more than it did two years ago, because building one no longer takes a developer. An automation assembled in an afternoon can keep posting to your general ledger long after the person who built it has left.
So use the glue layer for notifications and handoffs. For anything that creates an accounting record, use either a purpose built integration that can be reconciled, or a rule inside Xero itself.
The overview page has the fuller table of what we work alongside and what each system is actually for.
The failure modes
None of these announce themselves. They show up a month or two later as an account that will not agree and a close that keeps slipping.
Any integration that moves money through an intermediary needs a clearing account, and a clearing account doing its job returns to zero. If yours has grown steadily since the connection was switched on, that balance is the accumulated difference between what the app says happened and what the bank says happened. Checking it monthly is the cheapest early warning available.
Before you buy anything
Most files do not need another app. They need the configuration nobody went back and finished after go live.
None of this is an integration, and all of it is usually cheaper than one.

The procedure
Worth running once a year, and worth running immediately after anyone who set up an integration leaves.
Step one
Open the connected apps list in Xero settings and write down every connection, including the ones nobody remembers authorising.
Step two
A named person against each one. If a connection has no owner, that is the finding, before you look at anything else.
Step three
Follow one transaction end to end for each connection. Where it starts, what posts, which account it lands in, and whether that is where you thought.
Step four
Every clearing and suspense account back to zero, or a written explanation of why it is not. Balances without explanations become permanent.

The newest connection
The most recent additions to the app layer are not apps. They are assistants and agents reading directly from your ledger, and they deserve the same scrutiny as anything else that connects.
Xero has its own assistant, JAX, available inside Xero and answering within whatever permissions the user already holds. Alongside it, Xero has built connections that put live ledger data into the tools people already work in: a certified connector for Microsoft 365 Copilot, and a plugin for ChatGPT. Underneath all of it sits a server Xero runs that lets a language model query a Xero organisation at all.
Claude connects through that server, authorised the same way any other connection is. No developer setup, no keys to store, just an approval screen. It gives you around twenty tools covering reports and records. Profit and loss, balance sheet, cash position, aged receivables and payables, the chart of accounts, tracking categories, bank transactions, bills, invoices, purchase orders, contacts. In the current build every one of them reads and nothing writes, which means you can ask a question of your live ledger in plain English and get an answer back in seconds, without exporting anything and without anyone being able to change a figure through the conversation.
Two things to set deliberately. The authorisation follows the login, not the file, so one approval reaches every organisation that person can see. Decide whose login it runs under. And the 1099 endpoint returns legal names, W-9 status and TIN matching results, so contractor identity travels with it.
The part that does not change is the ledger underneath. An assistant answers from what is in the file, at conversational speed and with total composure, whether or not the bank agrees.
The same questions apply without modification, and two of them get sharper:
That last point is why this section sits at the end of a page about integrations rather than at the top of it. The direction of travel is not in doubt: the platform will keep absorbing the mechanical work, and it will keep getting better at it. What it does not absorb is whether the numbers underneath were right to begin with, and that question gets more consequential, not less, as more decisions are made from answers rather than from reports.
Questions
Next
Most files have at least one connection nobody owns and one account that never clears. Tell us what you are running and we will tell you what it is doing to your books.