← Journal

AI with Xero, QuickBooks and Sage: what "integrates" actually means

A bookkeeper working at a laptop and second monitor at home

Every AI tool sold to accountancy practices claims to integrate with Xero, QuickBooks and Sage. Almost all of them do, in the narrow sense that a connection exists. The claim is nearly meaningless, because "integrates" covers everything from a genuine two-way sync to a nightly CSV export somebody wrote once.

This post deliberately does not contain a feature comparison. Integration capabilities change on the vendors' release schedules, not ours, and a matrix published today would mislead somebody in six months. What does not change is the set of questions that separate a real integration from a logo on a marketing page.

Start from the ledger, not the tool

The three major packages all publish developer documentation describing what third parties can and cannot do — Xero's Accounting API documentation is public, as are Intuit's and Sage's developer sites. Any claim a vendor makes about your ledger is constrained by what those APIs permit.

That gives you a useful stance in a sales conversation. You are not asking whether the tool is good. You are asking which documented API operations it uses, and a vendor who cannot answer that quickly is telling you something.

The six questions

A finance director and an adviser evaluating software options on a tablet

1. Does it read, write, or both?

This is the big one and it is routinely fudged. Reading is easy and low-risk. Writing to a client's ledger is neither. A tool that reads to produce a summary is a very different proposition from one that creates or edits transactions, and the pricing rarely reflects the difference in risk.

Ask directly: does this write to the ledger, and what exactly can it write?

2. What happens when the connection breaks?

It will. Tokens expire, clients revoke access, APIs deprecate versions, a client changes their subscription. The question is whether you find out immediately or discover it three weeks later when figures do not reconcile.

A vendor with a good answer here has clearly been through it. A vendor who has not considered it is selling you a demo.

3. Is it per-client or per-practice?

Some integrations authorise once at practice level. Others require a separate connection per client, each with its own consent and its own expiry. The second kind is entirely workable, but it is an ongoing administrative load that nobody mentions in the demo, and it scales with your client list.

4. What happens to the data?

Client financial data leaving your systems is a data protection question before it is a functionality one. Where is it processed, where is it stored, how long is it retained, is it used to train anything, and who is the controller.

This is not paranoia. If the answer is unsatisfactory it does not matter how good the tool is, because the obligation is yours and it does not transfer.

5. Does it handle your actual client mix?

Most tools demo beautifully against a clean limited company on a current software version. Practices do not have a client base of those. They have sole traders on spreadsheets, a partnership on a package nobody supports, and someone still on desktop.

Ask what happens to the awkward third of your list, because that is where the work is.

6. What does it do that you could not do with a rule?

A fair share of what gets sold as AI is a conditional statement with better marketing. That is not automatically a criticism — a well-built rule is reliable and cheap, and often preferable. But it should be priced like a rule.

If a vendor cannot explain what the model is doing that a rule could not, you are paying a premium for the word.

Where integration genuinely earns its keep

The strongest case is not analysis. It is removing the gap between the ledger and the client.

A practice knows which records are missing because the ledger shows it. The client knows nothing until somebody tells them. Most chasing exists to bridge that gap by hand — a person reads the ledger, works out what is outstanding, and composes a message.

An integration that closes that loop automatically, so the client is asked for precisely what the ledger says is missing, removes real recurring work and requires no professional judgement. It is also the case most vendors undersell, because it is unglamorous next to a demo that categorises transactions.

The migration question nobody asks

A calm accountant overseeing a careful data migration on a laptop

One more worth adding to the list, because it only becomes visible when it is expensive: what happens if you stop using the tool.

If an integration has been writing to client ledgers for two years, its output is now part of the record. Removing the tool does not remove what it wrote. So ask what leaving looks like — whether the data it holds is exportable in a usable form, whether anything it created in the ledger is identifiable as its work, and whether the practice can reconstruct decisions made on its output.

A vendor confident in their product answers this without discomfort. It is also a fair proxy for how they will treat you as a customer, since a tool that is difficult to leave rarely has to compete for the renewal.

What to do before buying anything

Work out where your time actually goes first. Practices routinely buy a categorisation tool when the bottleneck was that clients send documents late, which no ledger integration fixes.

Then ask the six questions above, in writing, and keep the answers. A vendor who answers them cleanly is worth talking to. One who answers with case studies is not answering.

We cover the wider practice picture on our AI for accountants page, and the record-chasing problem specifically in automating client record chasing before 31 January.

The short version

"Integrates with Xero" is not a specification. Ask whether it reads or writes, what happens when it breaks, whether it is per-client or per-practice, where the data goes, how it handles your messiest clients, and what it does that a rule could not. Check the answers against the vendors' own published API documentation, which is public and binding in a way that marketing copy is not.