Connecting Xero or QuickBooks to your other systems

Almost every established SME we speak to has an accounts package sitting on its own island. Xero, QuickBooks or Sage holds the invoices, the payments and the VAT. Something else entirely holds the work that produced them: a job system, a booking diary, a website, a CRM, or, more often than anyone admits, a spreadsheet. Between the two sits a person, retyping.

If you have searched for how to integrate Xero with your system, you will have found a wall of connector apps promising it in a couple of clicks. Some of those are genuinely good and you should check whether one of them already does what you need before paying anybody to build anything. But the integrations that disappoint people rarely fail because of the API. They fail because of decisions nobody made at the start.

Here is what the work actually involves.

Be specific about which problem you are solving

"Connect Xero to our system" is not a requirement, it is a wish. Under it there is almost always one of three quite different jobs.

Stop the double keying. Something happens in the operational system (a job completes, an order ships, a session is delivered) and an invoice needs to exist in Xero. Today someone types it twice. This is the most common case and usually the cheapest to solve.

Get the operational system to see money. Your team needs to know whether an invoice was paid without switching to the accounts package or asking finance. That is a read in the other direction, and it is a different piece of work.

Get one honest picture. You want reporting that spans both, so you can see margin by job or by customer rather than revenue in one place and costs in another. This is the most valuable of the three and the one that exposes every inconsistency in your data.

Pick one to start. Integrations that try to do all three at once take longer to build and much longer to agree, because every disagreement about what a customer or a product is has to be settled before anything ships.

The hard part is identity, not the API

Xero and QuickBooks both publish proper, documented, versioned APIs. Reading and writing invoices, contacts and payments is well-trodden ground. That part is not where the time goes.

The time goes on matching. Your job system has "Smith & Sons Ltd". Xero has "Smith and Sons". Are they the same customer? Is the account reference the customer, or the site, or the contract? When a new customer appears in the operational system, should the integration create them in Xero automatically, or wait for somebody to approve it?

The same question applies to products, nominal codes, VAT treatment and units of measure. An integration is only as good as the agreement about what each side means, and that agreement is a business decision, not a technical one. Expect to spend real time on it, and expect it to surface duplicates and rubbish in your existing data that nobody knew about. That is not the project going wrong. That is the project doing its job.

What the accounts platforms will and will not let you do

Two practical constraints worth knowing before you plan anything.

There are rate limits. Xero allows 60 API calls a minute and 5,000 a day per connected organisation, with a wider limit across all the organisations an app connects to, and it publishes the detail on its rate limits page. QuickBooks Online throttles at 500 requests a minute per company and rejects more than ten concurrent requests to the same company, which Intuit documents here. For a typical SME moving tens or hundreds of records a day, neither is anywhere near a problem. It matters if you were imagining a nightly job that re-reads five years of history, which is a design worth avoiding anyway.

You are a guest. These are somebody else's systems, and they change. A supplier can alter an API, deprecate an endpoint, or change how authentication works, and no integration can prevent that. What a well-built one can do is fail loudly rather than silently. That distinction is the single biggest quality difference between integrations, and it is worth asking about directly.

Where these projects come unstuck

Silent failure. The integration stops working on a Tuesday and nobody notices until the month-end numbers do not reconcile. By then there are three weeks of missing invoices to unpick by hand. Anything that cannot be delivered should be queued and retried, and anything that still cannot get through should be logged somewhere a human will actually look.

Duplicates. A retry that is not safe to repeat creates a second invoice. The fix is designing so that sending the same thing twice produces one record, not two, and it is far easier to build in at the start than to bolt on after somebody's customer has received two bills.

One-way assumptions in a two-way world. You sync invoices out to Xero, and then someone edits one in Xero. What should happen? Deciding that up front is five minutes. Discovering it in production is a fortnight.

Automating a process you do not like. If the current sequence of steps is a mess, wiring it together faster just makes the mess permanent. The same warning applies to spreadsheets, and it is the last section of our guide to the signs your business has outgrown spreadsheets for the same reason.

Integration, or a system that does not need one?

Sometimes the honest answer is that connecting the two systems is treating a symptom. If the operational side is a spreadsheet held together by one person, an integration bolts a reliable pipe onto an unreliable source. It may still be worth doing, but be clear that is what you are buying.

The alternative is to replace the operational system with something purpose built and connect that to the accounts package as part of the same project. That is a bigger piece of work, but you only go through the data-matching argument once, and you end up with one system rather than two plus a bridge. Our guide to how long bespoke software takes sets out realistic timescales. Our replace spreadsheets page covers what that looks like in practice.

What it costs

A single connection between two systems that both have proper APIs is usually the smallest thing we take on, and it sits well below the £15k that starts the bands on our bespoke software cost page. Cost climbs in three situations: when one side has no API and the data has to be reached another way, when records must be reconciled rather than simply copied, and when the two systems fundamentally disagree about what a customer or a product is.

Those are also, usefully, the same three things that make an integration worth having. If your two systems already agree about everything, you probably do not need one.

A sensible first step

Before you speak to anybody, count the handoffs. Write down every point where a piece of information is typed into one system having already been typed into another, and how often each happens in a week. That list is the specification, and the total is the number the project has to beat.

If it would help to have someone go through it with you, that is what our system integration work usually starts with, and the free process audit covers it. Sixty minutes, and you will get a straight answer, including "an off-the-shelf connector already does this" where that is the truth. Get in touch if that would be useful.