What is a Xero integration developer, and when do you need one?
A Xero integration developer writes software that moves accounting data between Xero and your other systems through Xero's official API. You need one when your team is re-keying orders, jobs or invoices into Xero, when an off-the-shelf connector posts entries your bookkeeper keeps fixing, or when data needs to flow back from Xero into your own tools.
The signs are usually visible in the month-end close. Someone exports orders to a spreadsheet, cleans them, and imports them into Xero. Invoices are raised twice, once in the job system and once in Xero. The bookkeeper recodes GST on dozens of lines because the connector used the wrong tax type. Nobody in sales knows whether a client has paid without logging into Xero. Each of these is a data-flow problem, and each one can be solved by an integration that runs quietly in the background.
The role is part developer, part accounting translator. Writing API calls is the easy part. The harder part is agreeing, with your bookkeeper or accountant, what should appear in Xero: one invoice per order or a daily summary, which account each product maps to, how discounts and shipping are treated, and where payment processor fees land. A good integration developer asks those questions before writing a line of code.
Do you need a custom Xero integration or an app from the Xero App Store?
A good Xero integration developer will tell you to try an existing app first when your setup is common, and choose a custom integration when your rules are unusual, several systems need to share data, or you need data flowing both ways with checks a connector cannot do.
The Xero App Store lists a large number of connectors, and many of them handle the typical case well: a single Shopify store in AUD posting orders to Xero with standard GST. Automation tools can also move simple records between systems. Neither is wrong. They become awkward when your store sells a mix of GST-free food and taxable goods with bundle discounts, when a CRM and a job system both create contacts that must be matched to the same Xero record, or when a wholesale channel needs different account codes and tracking categories from retail.
We start each enquiry by asking what you already tried. If a connector gets you most of the way, we might suggest keeping it and building only the missing piece, such as a script that applies tracking categories after the connector posts. That is often cheaper than replacing it.
Choose a connector app when
One source system, standard GST, one invoice per order, and your bookkeeper is happy with its output.
Choose an automation tool when
A handful of low-volume flows with simple rules, owned and edited by someone on your team.
Choose a custom integration when
Mixed tax rules, several systems, two-way sync, high volume, or a need for your own audit trail.
How a Xero integration connects: OAuth 2.0 apps and custom connections
A Xero integration developer has two common ways in. A standard app uses OAuth 2.0: your Xero admin signs in, approves the requested access, and the integration receives tokens it refreshes over time. A custom connection is a premium Xero option that uses the client credentials grant to connect to a single Xero organisation, which suits an integration built for one business.
Xero's documentation describes custom connections as available for organisations in Australia, New Zealand, the UK and the US, requiring an additional monthly subscription paid by the organisation, and connectable to the Xero Demo Company free of charge for development. For a single Australian business with its own integration, a custom connection is often the tidiest option, because there is no user sign-in to expire when a staff member leaves.
A standard OAuth 2.0 app makes more sense when the same integration will connect to several Xero organisations, for example a group with separate entities, or when you plan to offer the integration to other businesses. Either way, the integration should request only the access it needs, store its credentials encrypted in your own cloud account, and be listed in Xero's connected apps so your admin can see and revoke it.
Xero's developer documentation on custom connections explains setup and availability.
Xero API rate limits and how a sync should be designed around them
A careful Xero integration developer designs the sync so it never needs to hit the limits: queue work, batch where Xero allows it, and back off when told to. Xero's published limits apply per connected organisation for each app: 5 calls in progress at once, 60 calls a minute and 5,000 calls a day, plus an app-wide limit of 10,000 calls a minute across all organisations.
When a limit is exceeded, Xero returns HTTP 429 with a Retry-After header that says how long to wait. A careless integration handles that by crashing or retrying immediately, which makes things worse. Ours places every outgoing change in a queue, sends it at a steady pace below the per-minute limit, reads the Retry-After value when it appears, and picks up where it left off.
Daily limits matter more than people expect. A store with a busy sale day can generate thousands of orders, refunds and inventory updates. Posting each one as a separate call, then reading it back to confirm, could exhaust the daily allowance by mid-afternoon. Several techniques keep volume sensible: Xero's create endpoints accept multiple invoices in one request, reads can ask only for records modified since the last run using the If-Modified-Since header, and some businesses are better served by a daily summary invoice per channel than by one invoice per order. Which option fits is partly a bookkeeping decision, so we model the expected call volume with you before choosing.
Syncing Shopify orders into Xero without upsetting your bookkeeper
Decide first whether Xero should hold every order or a daily summary, and route payouts through a clearing account so bank reconciliation matches what actually lands in your account. Those two decisions shape everything else in a Shopify to Xero integration.
Per-order invoices give a detailed audit trail and customer-level reporting in Xero, but they use more API calls and create many small contacts. Daily summaries keep Xero lean and are easier to reconcile, with detail staying in Shopify. Many Australian stores choose per-order posting for wholesale and summaries for retail. Either way, the integration needs rules for discounts, shipping, gift cards, partial refunds and orders edited after payment.
Payment timing is where connectors often disappoint. Shopify collects money, deducts fees and pays out later, sometimes grouping many orders into one deposit. A clean pattern posts each sale as paid into a clearing account, then records the payout as a transfer to the bank account with the fees posted to an expense account, so the bank feed line matches a single transaction. Buy now, pay later providers and other gateways follow the same idea with their own settlement reports. Your bookkeeper chooses the accounts; we build the rules.
- Invoice per order or daily summary, per channel
- Discounts as separate lines or reduced prices
- Shipping mapped to its own income account and tax type
- Refunds as credit notes linked to the original sale
- Payouts through a clearing account, fees to expenses
- Gift card sales as a liability, not income
For store builds as well as the sync, see our Shopify developer and WooCommerce developer pages.
Connecting a CRM or job management system to Xero contacts and invoices
A Xero integration developer should match contacts carefully before syncing anything else, because duplicate contacts are the most common mess a CRM to Xero integration leaves behind. Once contacts are matched on a stable key, invoices and payments follow cleanly.
A CRM usually knows a client by email or company name; Xero knows them by a ContactID. The integration stores the Xero ID against each CRM record on first match and uses it from then on. For the first match we look at ABN where you record it, then email, then a normalised business name, and send anything ambiguous to a review queue rather than guessing. That one design choice saves hours of merging later.
Job and booking systems add another layer: quotes that become invoices, deposits taken up front, progress claims, and variations. We agree with you which event creates the Xero invoice (job completed, job approved, or a manual trigger), whether deposits are separate invoices or prepayments, and how variations appear. If your team uses a common trade system that already has a Xero connection, we check whether its built-in sync is enough before proposing custom work. When you need your own pipeline in the middle, custom CRM development covers that build.
Mapping Australian GST tax rates in a Xero integration
Every line an integration sends to Xero needs the right tax type, and in Australia that usually means choosing between GST on income, GST-free income, input-taxed and BAS-excluded treatments, plus the expense equivalents for bills. Your bookkeeper or accountant decides the mapping; the Xero integration developer makes the integration apply it consistently.
Xero's accounting API identifies tax rates by codes such as OUTPUT, INPUT, EXEMPTOUTPUT, EXEMPTEXPENSES, INPUTTAXED, BASEXCLUDED and GSTONIMPORTS. Xero's developer guidance notes that if a line's tax type is not specified, Xero applies the default tax rate on the account the line is coded to, and that system-defined tax types cannot be edited through the API. Relying on account defaults works until someone changes an account setting, so we set tax types explicitly on every line.
Mixed baskets are where mapping earns its keep. A grocery store selling GST-free basic food alongside taxable goods, a clinic with GST-free health services and taxable retail products, or a training provider with some input-taxed lines all need a per-product or per-service tax rule. We hold those rules in a mapping table your bookkeeper can edit, read the organisation's live tax rates at start-up so custom rates are recognised, and flag any product with no mapping instead of guessing. We also set line amounts as tax-inclusive or tax-exclusive to match the source system, because Australian stores normally display GST-inclusive prices and a mismatch shows up as rounding differences at BAS time.
Using Xero tracking categories in a custom integration
For a Xero integration developer, tracking categories are an easy win: they let you report profit by location, channel, division or project without splitting your chart of accounts, and an integration can apply them automatically to every line it posts. Xero's API allows a maximum of two tracking categories on any invoice line, so choose the two dimensions that matter most.
Common Australian setups use one category for location, such as a store or branch, and another for channel, such as retail, wholesale or marketplace. Service businesses often track by division or by project. The integration reads the tracking categories and their options from Xero, maps each order or job to the right option using a rule you define, and creates a new option when, say, a new branch opens, provided your bookkeeper has approved that behaviour.
The trap is renaming. If someone renames a tracking option in Xero, a naive integration that matches by name will stop tagging lines or create a duplicate. We store Xero's option identifiers and check the mapping each day, raising an alert if an option has disappeared or been archived.
Payments and reconciliation: what a Xero integration should and should not do
A sensible Xero integration developer lets the bank feed remain the source of truth for money in the bank, and use the integration to mark invoices paid in a way that reconciles against it, not to invent bank transactions. When an integration and a bank feed both record the same money, you get duplicates that are painful to unwind.
For card and online payments, the clearing-account pattern keeps things clean: sales are marked paid into a clearing account, and the settlement that hits your bank is matched to one transfer. For invoices paid by bank transfer, the integration can apply payments when your payment provider or CRM confirms receipt, or you can let your bookkeeper reconcile them from the bank feed as usual and have the integration read the paid status back.
Reading status back is often the most valued feature. Once Xero shows an invoice as paid, the integration updates your CRM, job system or client portal, so sales staff stop chasing and account managers see who is overdue. The direction of each field, Xero to system or system to Xero, is written down in the specification before the build starts.
Webhooks or scheduled polling for a Xero sync?
As a Xero integration developer, we use webhooks for changes you want to know about quickly, and a scheduled catch-up run for everything else. Relying on either alone leaves gaps.
Xero offers webhooks that notify your endpoint when contacts or invoices are created or updated. Each notification carries an x-xero-signature header, a hashed signature of the payload that your endpoint must verify before trusting it. A webhook tells you which record changed, not its full contents, so the integration then fetches the record through the API. That keeps notifications small but still uses calls, which is another reason to queue work.
Webhooks can be delayed or missed during an outage, so every integration we build also runs a scheduled reconciliation that asks Xero for records modified since the last successful run and compares them with the other system. Anything out of step is either fixed automatically or sent to the error queue for a person to look at.
Error handling, retries and audit logs in a Xero integration
A reliable Xero integration assumes things will fail and makes every failure visible and safe to retry. The goal is that a timeout never creates a duplicate invoice and a validation error never disappears silently.
Xero's accounting API accepts an Idempotency-Key header on create requests, described in its API specification as a way to retry safely without the risk of duplicate processing. We generate a key from the source record, such as the order number and version, so a retried post returns the original result rather than a second invoice. Validation errors, such as a missing account code or an archived contact, go to an error queue with a readable message and a link to the source record.
Every sync action is logged: what was sent, when, which Xero record it created or updated, and the response. When your accountant asks why an invoice looks a certain way in March, you can trace it back to the order and the rule that produced it. Logs are stored in your own cloud account and trimmed on a schedule you choose.
- Idempotency keys on every create request
- Queue with backoff that respects Retry-After
- Error queue with plain-English messages and retry buttons
- Daily summary email: synced, skipped, failed
- Audit log linking source records to Xero IDs
How much does a Xero integration developer cost in Australia?
With BtechWaleTech, a simple one-way Xero sync starts from US$600 and a full two-way integration from US$900. Local developer and agency quotes vary widely; the spread comes from how much discovery, accounting design, testing and support is bundled in rather than from the API code itself.
The biggest cost drivers are the number of systems, the complexity of your tax and discount rules, how many edge cases need handling, and whether you want historical data backfilled into Xero. A Shopify store with standard GST posting daily summaries is at the low end. A business with a CRM, a job system and a store all feeding one Xero organisation, with contact matching, tracking categories and payments flowing back, is at the other.
Running costs are separate and paid directly by you: hosting for the integration, usually a small serverless or container setup in your AWS or other cloud account; a Xero custom connection subscription if you use one; and any connector or automation subscriptions you keep. After two months of free maintenance, optional care starts from US$120/mo.
Security, privacy and who owns the integration
The integration runs in your cloud account, its code lives in your repository, and your Xero admin authorises the connection. We work as invited users and can be removed at any time without breaking anything.
Credentials and tokens are stored encrypted in a secrets manager, never in code or spreadsheets. The integration requests the narrowest access that does the job, logs who changed any mapping, and keeps personal data only as long as it needs to. For Australian businesses covered by the Privacy Act, the OAIC's guidance on security of personal information applies to customer data moving between systems; your adviser can confirm what applies to you, and we build the controls, such as access limits and logs, that support it.
Hosting in an Australian cloud region, such as AWS Sydney, is the default we suggest for Australian clients. At handover you get the source code, deployment notes, a mapping document your bookkeeper can read, and a runbook that explains how to pause the sync, replay a failed batch and rotate credentials.
Hiring a Xero integration developer in India: how it works from Australia
When you hire a Xero integration developer from our team, you work directly with three developers over WhatsApp, email and short video calls, and your bookkeeper joins the calls that decide how entries should look. There is no Australian office or local entity, invoices come from India, and quotes are in USD.
India runs four and a half hours behind Sydney, Melbourne, Canberra and Hobart outside daylight saving and five and a half during it, so our morning meets your afternoon. Brisbane's gap stays the same all year, and Perth sits two and a half hours ahead of India. Integration testing suits this rhythm well: we deploy a change to the test environment during our day, and your bookkeeper checks the entries in the Demo Company or a sandbox file during theirs.
Payments are by Wise, international wire or PayPal, in stages set out in the written quote. How you treat the invoice for tax is for your accountant. You create the cloud account, repository and Xero connection in your business's name and invite us, so there is nothing to hand back when the project ends.
Week one
Discovery call with you and your bookkeeper, sample exports from each system, a written field and tax mapping, and an agreed choice between per-order and summary posting.
Week two
Connection to the Xero Demo Company or a test organisation, the first records syncing, and your bookkeeper reviewing real-looking entries before anything touches the live file.
Worked example: a Xero integration for a store with a wholesale channel
This is a hypothetical scenario, not a client story. Say a Melbourne homewares brand sells retail through Shopify and wholesale to about sixty stockists who order by email, with a bookkeeper who spends two days each month fixing GST and recoding wholesale sales that a connector posted as retail.
The integration would post retail sales from Shopify as a daily summary per payout, through a clearing account, with shipping and discounts on separate lines and fees to an expense account. Wholesale orders would be entered in a small order form that creates one Xero invoice per order against the stockist's existing contact, matched by ABN, with wholesale account codes and 30-day terms. Both channels would tag lines with a Channel tracking category, and a second category for Warehouse would separate stock shipped from two locations.
GST would be set per product from a mapping table, because a few food gift items are GST-free. Paid status would flow back so the wholesale order form shows who is overdue. Built this way, the scope sits in the full integration band from US$900, with around eight weeks including a month of parallel running where the bookkeeper compares the new entries with the old process before switching off the connector.
How to choose a Xero integration developer: questions and red flags
Ask any Xero integration developer how they handle rate limits, duplicates and tax mapping, and who in your business signs off the accounting design. A developer who answers only in terms of API endpoints, without asking to speak to your bookkeeper, is likely to build something that works technically and creates work at month end.
Look for a test-first approach using the Demo Company or a separate organisation, a written specification of which system owns each field, and a plan for what happens when Xero is unavailable. Be wary of anyone who wants to connect straight to your live Xero file on day one, stores tokens in a spreadsheet, or cannot explain how a retried request avoids creating a second invoice.
- Will my bookkeeper approve the tax and account mapping before build?
- How do you stay inside Xero's minute and daily limits on busy days?
- What stops a retry from creating a duplicate invoice?
- Where do errors go, and who sees them?
- Whose cloud account and repository hold the code?
- How do we test before touching the live organisation?
- What happens to the sync if a tracking option or account is renamed?