If your business runs on FileMaker and your accounts run on Xero, someone in your office is almost certainly retyping data between the two. Invoices raised in FileMaker get keyed into Xero. Payments recorded in Xero get copied back into FileMaker. It works, in the way that carrying water in a sieve works — eventually, with losses.
A proper integration removes that job entirely. We've built FileMaker-to-Xero connections for UK businesses, and this guide explains how it works in practice: what actually syncs, what OAuth 2.0 means without the jargon, and where the traps are.
What can sync between FileMaker and Xero?
Xero's API exposes most of what you'd want:
- Contacts — customers and suppliers. Create them in FileMaker, they appear in Xero. No more duplicate customer records with three spellings of the same company name.
- Invoices — the big one. Raise an invoice in FileMaker with line items, VAT, and references, and it lands in Xero as a draft or approved invoice, your choice.
- Payments — when a payment is reconciled in Xero, FileMaker can pull it back so your team sees who's paid without opening the accounts package.
- Credit notes, purchase orders, and bills — all reachable through the same API if your workflow needs them.
The direction matters. Most of our clients want FileMaker to be the operational system — where quotes, jobs, and invoices are created — and Xero to be the financial record. Data flows one way for invoices, the other way for payment status. Deciding that flow is half the design work.
OAuth 2.0 in plain English
Xero doesn't let software log in with a username and password. Instead it uses OAuth 2.0, which sounds intimidating and is actually quite sensible.
Here's the idea. You, the business owner, authorise the FileMaker integration once, through Xero's own website. Xero then hands the integration a pair of tokens: a short-lived access token (think of it as a day pass) and a longer-lived refresh token (the ability to collect a new day pass without bothering you again). Your Xero password is never stored in FileMaker, and you can revoke the connection from your Xero settings at any moment.
The practical consequence: the integration has to manage those tokens carefully. Access tokens expire quickly, refresh tokens rotate when used, and if the refresh cycle breaks — say, two scripts try to refresh at the same time — the connection dies and someone has to re-authorise. A well-built integration handles all of this silently. A badly built one phones you on a Friday afternoon.
Common pitfalls (the ones we've actually hit)
The tenant connection. A single Xero login can be connected to several organisations — accountants live like this. When your integration authorises, it must record which organisation (Xero calls it a tenant) it's talking to. Get this wrong and you'll see authentication errors that look like a bad token but aren't. We learned to check the tenant first, every time; it's the cause of far more "the integration's broken" calls than expired tokens are.
Error handling that actually tells you something. When Xero rejects an invoice — a missing account code, a contact validation issue, a VAT rate it doesn't recognise — it sends back a detailed explanation. An integration that swallows that message and just says "sync failed" is worse than useless. Every call should log what was sent, what came back, and what the error code was, so problems take minutes to diagnose instead of afternoons.
Rate limits. Xero caps how many API calls you can make per minute and per day. Fine for normal use; a problem if you naively push five years of history in one go. Bulk migrations need pacing built in.
Draft vs approved. Decide early whether FileMaker-created invoices arrive in Xero as drafts for your bookkeeper to approve, or go straight in as approved. Both are fine. Changing your mind after 2,000 invoices is less fine.
Xero's own developer documentation is genuinely good, and it's what we validate every build against.
What a typical project looks like
A FileMaker–Xero project with us usually runs like this:
- A conversation about the workflow. Who creates invoices, where, and what needs to come back. This is free — it's our initial consultation.
- Mapping. Your FileMaker fields matched to Xero's — account codes, VAT rates, contact details, invoice references. Boring, essential, and where most future problems are prevented.
- The build. Authorisation flow, token handling, the sync scripts themselves, and logging. We build error handling in from the start, not as an afterthought.
- Testing against a Xero demo company. Xero provides a free demo organisation precisely so nobody tests against live accounts. We use it.
- Go-live and a settling-in period. The first month reveals the edge cases — the customer with no email address, the invoice with 200 lines. We expect them and fix them as part of the job.
We invoice monthly for completed work, and you can stop at any point — there's no contract locking you in. More on that on our how we charge page, and more on integrations generally at API integrations.
Is it worth it?
Do the maths on the retyping. If someone spends 30 minutes a day moving data between FileMaker and Xero, that's roughly two and a half weeks a year of paid time spent being a human photocopier — plus the errors, which cost more than the time. An integration typically pays for itself quietly and then keeps doing so.
We've been building FileMaker systems since 1998, and integrations like this are a large part of what we do now. If you'd like to talk through whether it makes sense for your setup, the initial consultation is free and refreshingly free of sales patter.
Call us on 0330 113 0958 or email info@flaresoftware.co.uk.