The short answer
A Xero or QuickBooks integration connects your website, POS or custom software to your accounting file so invoices, payments, credit notes and contacts move without double entry. AR Digital Solutions builds these from Brisbane, including tax code mapping, duplicate protection and alerts when a sync fails.
What we usually sync
- Orders or jobs out to invoices, with the right account codes.
- Payments and refunds, matched to the invoice they belong to.
- Credit notes and adjustments, in the direction they happen.
- Customers and suppliers, with a rule for which system owns the record.
- Payouts and fees, so the bank feed reconciles.
Reconciliation is the whole job
Any competent developer can call the Xero API and create an invoice. That's a day's work and a demo that looks finished.
The real job is one question asked every month: does the accounting file agree with the system that took the money. Every order has exactly one invoice. Every payment sits against the invoice it paid. Credit notes and refunds exist on both sides. The tax on each line is what the accountant expects. When something fails, somebody knows that day.
Get it right and reconciliation takes twenty minutes a month. Get it wrong and your bookkeeper spends two days hunting a $340 difference that turns out to be a duplicated invoice from March.
The duplicate invoice problem.
This is the failure built into most first attempts. Your system sends an invoice to Xero. Xero creates it, then the response is lost on the way back. Your side never hears yes, so it tries again. Now there are two invoices for one order, both real, both affecting your revenue and your GST position. It happens without a network fault too, when someone clicks sync twice.
The fix is idempotency. Before sending, your system generates a key identifying that operation, and the key travels with the request. Where the platform supports idempotency keys, a repeat with the same key returns the original invoice instead of a second one. Where it doesn't, keep your own ledger: this order produced that invoice ID, so check before creating anything. Either way the record is written before the call goes out, because the point is surviving a crash in the middle.
Reading payments back follows the same principle. Match on the platform's identifiers, not amount and date, because two customers paying $250 on one Tuesday will eventually happen.
Tax codes are where Australian builds come unstuck.
Your sales system thinks in prices and a GST flag. Your accounting file thinks in tax rates tied to codes, and separates things that look identical from outside: GST on income, GST free income, export sales, input taxed. Hardcode one rate and most invoices look fine while a few are quietly wrong, which is worse than all of them being wrong, because nobody catches it.
So the mapping is written as a table, line by line, before any code, and signed off by whoever prepares the BAS. Prices need a clear position on whether they include GST, because a cent of rounding per line becomes a reconciliation difference across a thousand orders. Account codes and tracking categories work the same way: if revenue should split by product line or location, decide during scoping, because retrofitting means re-coding history.
Failures have to be loud.
The worst accounting sync isn't the one that errors, it's the one that stops. Every sync we build records what went across and when, retries what's retryable, holds the rest in a visible queue, and alerts a human when a run doesn't happen. You should hear it from an alert, not your accountant.
How we do it
1. We map the objects and tax codes with your bookkeeper in the room, before anyone writes code.
2. We agree scope and price.
Fixed number, dates in writing.
3. We build against a demo company and test the ugly cases: timeouts, part payments, refunds, credit notes.
4. We run both in parallel for a month end before switching anything off.
Who it's for, and who it isn't
It suits businesses whose orders live in a website, a POS or billing system or custom software, and whose staff rekey those into the accounting file.
It isn't needed if a connector already does the job. Shopify and WooCommerce have accounting apps that handle standard setups, and our eCommerce web design team uses them when they fit.
Why bring this here
Developers in house, and the same team runs the hosting. More of our work sits on the apps page.
We stay after launch.
API versions change and credentials expire, which the custom integrations page covers. No lock in contracts, and the code is yours.
"We tried this and the numbers didn't match."
Usually duplicates, tax mapping, or payments matched on amount instead of ID. We'll find which before quoting a rebuild.