Connecting Xero or MYOB to Your CRM: What to Sync and Why

Most office managers will recognise this one. Someone types a new customer into the CRM, then types them again into Xero or MYOB, and three months later the two lists disagree about the customer's phone number, their billing address and whether they've paid. A good Xero CRM integration (or the MYOB equivalent) fixes that, but only if you decide up front what moves between the two systems, in which direction, and which one wins when they disagree.

This guide covers those decisions in plain terms. It's written for owners and office managers, not developers, though I've linked the developer documentation where a detail matters.

What a Xero CRM integration should actually sync

Four kinds of record do almost all the useful work. Everything else is optional, and most of it is better left alone.

Contacts

Customers are the backbone. Both systems need the business name, a billing contact, an email for invoices, a phone number, a billing address and, for business customers, an ABN. MYOB's API, for example, stores up to five addresses per customer and has a dedicated ABN field for Australian files, according to the MYOB Business API customer reference. The CRM usually holds far more than that (site contacts, notes, job history, how they found you), and that extra detail has no reason to travel into your accounts.

Quotes

Quotes are where people get tangled. If your team builds quotes in the CRM, keep them there and only send the accepted ones across as invoices or draft invoices. Xero and MYOB both have quote records, but running quotes in two places almost guarantees two versions of the same price.

Invoices

Raising the invoice from the CRM when a job is marked complete saves the double handling everyone hates. The CRM sends the line items, the accounting system assigns the invoice number and the tax treatment.

Payments

Payment status should flow back. Your sales and service staff don't need the bank feed, but they do need to see "paid", "part paid" or "overdue" next to a customer before they book the next job or chase a new quote.

Decide which system owns each piece of data

This is the decision that saves the most grief later. For every field you sync, one system is the source of truth. The other system receives updates and doesn't overwrite them. Write it down. A one-page table is enough, and here's the shape we usually start from:

Notice that customer details are split. Sales staff create the customer, but once your bookkeeper has corrected the billing email or the ABN in Xero, that correction should win. Splitting ownership by field, rather than by whole record, sounds fiddly. It's the only arrangement I've seen hold up once real people start editing both sides.

One-way or two-way sync?

Two-way sync sounds like the obvious answer. Edit anything anywhere and it shows up everywhere. In practice it's where most integration headaches come from, because two systems that can both change the same field will eventually change it at the same time.

My honest view: most small businesses are better off with one-way flows per field, and a vendor promising "full two-way sync of everything" is selling the easy bit of the job and skipping the hard bit. The hard bit is the conflict rule. If a receptionist updates a phone number in the CRM at 10:02 and the bookkeeper updates it in MYOB at 10:03, which one stands? A one-way rule answers that before it happens.

Where two-way is genuinely needed (contact details are the common case), set a clear tie-breaker, such as "the accounting system wins for billing fields, the CRM wins for everything else", and log every overwrite so someone can check it later.

How duplicates creep in, and how to stop them

Duplicates are the mess that turns up most often in connected systems, and they nearly always come from matching on names. "Smith Plumbing", "Smith Plumbing Pty Ltd" and "Smiths Plumbing" are one business to you and three to a computer.

The fix is to store each system's own ID against the record in the other system. MYOB gives every customer a unique identifier (a UID) plus a card ID, and Xero gives every contact its own contact ID. Once a CRM record holds the matching Xero or MYOB ID, the integration updates that exact record instead of guessing. Xero is also strict about names: its published API specification says a contact name must be unique across all active contacts, so a careless sync that creates "Smith Plumbing" twice will simply be rejected (see Xero's official OpenAPI specification on GitHub).

A few habits help on top of IDs:

• Clean and merge duplicates in the accounting file before the first sync, not after.
• For the initial match, use ABN or billing email as the key, and send anything uncertain to a person to confirm rather than auto-creating a new contact.
• Stop staff creating customers directly in the accounting system once the link is live, or at least route them through one agreed place.

If you're moving off spreadsheets at the same time, the same matching rules apply. Our article on migrating from spreadsheets to a CRM without losing data covers the clean-up side in more detail.

Timing: real time, scheduled or on demand

Not everything needs to move instantly. Invoice creation usually should happen right away, because someone is waiting to send it. Payment status can often run on a schedule, every fifteen minutes or every hour, without anyone noticing. Bulk updates (reworking every customer's payment terms, say) belong in a quiet window.

The accounting platforms set limits that shape this. Xero's developer FAQ lists a limit of 60 API calls per minute for each connected organisation, plus a daily cap, and returns an HTTP 429 "too many requests" response with a Retry-After header when an app goes over (see the Xero Developer FAQ on rate limits and tokens). The same page recommends asking only for records changed since the last request. In plain terms, a well-built integration asks "what's changed since 2pm?" rather than downloading every invoice each time.

The other timing trap is quiet failure. A sync that stops working on a Friday and isn't noticed until the end of the month is worse than no sync at all, because everyone trusted it. The way we build these, a failed sync is queued, retried automatically, and our team is alerted if it still won't go through. Whatever system you use, ask what happens when a sync fails and who finds out.

What to leave in Xero or MYOB

An integration isn't an invitation to rebuild your accounting system inside the CRM. Plenty should stay exactly where it is:

• The chart of accounts, journals and bank reconciliation.
• BAS preparation, GST reporting and anything your accountant or registered BAS agent works from.
• Payroll, super and employee records.
• Supplier bills and purchase orders, unless your jobs genuinely need cost tracking in the CRM.
• Credit notes and write-offs, which are accounting decisions with tax consequences.

The test I give clients is simple. If your bookkeeper would be annoyed to find it changed by someone in sales, it stays in the accounting system and the CRM only reads it. The tax codes are a good example. Let Xero or MYOB apply GST to invoice lines, and have the CRM display the result rather than calculate its own.

Access, permissions and security

Connecting a CRM to your books means granting another system access to financial data, so it pays to be fussy.

Both platforms use OAuth 2.0 for online files, which means you log in on Xero's or MYOB's own page and approve the connection; the CRM never sees your accounting password. MYOB's API authentication documentation tells developers to request only the scopes covering the endpoints their app will use. Xero has moved the same way: its developer FAQ says apps created from 2 March 2026 use granular scopes, so an app asks for, say, invoice access rather than broad access to every transaction type.

Two practical points follow from that. First, read the permission screen when you connect. If an integration that only needs contacts and invoices is asking for payroll, ask why. Second, connections expire if they sit unused. Xero's FAQ notes that unused refresh tokens expire after 60 days, after which someone has to reauthorise the connection, which catches out businesses that pause an integration over the Christmas shutdown.

Inside the CRM, decide who can see financial fields. Your field technician probably needs "account on hold" but not the customer's full payment history. We build CRMs with role-based access so staff only see what their role needs, and with multi-factor sign-in, because a CRM linked to your accounts is worth protecting as carefully as the accounts themselves. If you'd like to see how integrations fit with the rest of a build, our page on connecting your CRM to accounting and other systems sets out what we connect and how.

A short checklist before you switch it on

Before any data moves, run through these in order:

1. Write the ownership table: every synced field, its owner and its direction.
2. Clean duplicates in both systems and agree the matching key (ABN or billing email).
3. Connect a test or demo company file first, and push a handful of real-looking invoices through.
4. Check GST, rounding and invoice numbering against what your bookkeeper expects.
5. Agree how failures are reported and who fixes them.
6. Switch on for new records first; backfill history only once the new flow is trusted.

That last step matters more than it looks. Backfilling five years of invoices on day one turns every small mapping mistake into five years of small mapping mistakes.

If you're still deciding whether a connected system is worth it at all, our guide to choosing between a custom and an off-the-shelf CRM covers the bigger picture, and auditing your business software subscriptions is a useful first step if half your tools overlap already. And if you'd like a second opinion on what your own Xero or MYOB link should look like, book a 30-minute call with our team and we'll map it out with you.

— Craig Winder, Founder