Guide · Buildertrend and Xero
Buildertrend and Xero,
before you rely on it.
Buildertrend connects to Xero, and for an Australian builder the useful question is not whether it connects but what crosses, which way, and which system is right when the two disagree. This guide sets out what Buildertrend publishes about its own Xero connection, what it leaves unstated, and the checks worth running on a demo organisation before a live job depends on the answer.
Written by Brad Caldon, Founder, VIABUILD. Licensed builder (NSW) · Registered Building Practitioner (Class 1 to 9) · B.Construction Management (Hons) · Last reviewed 19 September 2026
01 / The basics
In plain English
The arrangement is the ordinary one. Buildertrend runs the build, Xero stays the accounting ledger, and a connection between them is meant to stop the same number being typed twice. The part that decides whether it works for an Australian builder is narrower than the brochure question: which records cross, in which direction, and what happens to GST and job coding on the way.
What Buildertrend publishes about it
On its own Xero integration page, Buildertrend answers the two-way question directly. Its FAQ states, in full: “Yes, there is two-way sync for certain information. Some data including contacts from jobs, invoices, subs, vendors and bills can transfer automatically from Buildertrend to Xero. Additionally, financial data comes back to Buildertrend from Xero.” Read that sentence closely rather than past it. Named records move out to Xero; what comes back is described as financial data and is not itemised.
The same material sets two setup conditions, and they are the conditions that decide whether your job costing survives the trip. Buildertrend jobs must be linked to the corresponding Xero contact, and Buildertrend cost codes must be linked to the corresponding products and services in Xero. In other words the mapping between your job structure and your ledger is something you build by hand at setup, and everything downstream inherits it. Checked September 2026, and vendor documentation changes, so confirm the current wording with Buildertrend before you act on it.
What it does not say
Two things an Australian builder would want confirmed were not documented on the pages we read. Xero tracking categories are not mentioned, which matters because tracking categories are how job-level reporting works inside the ledger itself. And the integration overview describes calculating sales tax rather than GST. Neither is evidence that the product cannot do these things. It is evidence that the vendor does not document them, which makes both a question to put to Buildertrend rather than an assumption to make.
If what you actually want is the object-by-object picture across the market, that is a different page: our comparison of construction software for Xero checks eleven platforms against their own documentation and sets Buildertrend’s sync table beside the rest. If you are weighing Buildertrend itself rather than its ledger connection, the VIABUILD and Buildertrend comparison and the Buildertrend alternatives roundup cover that ground.
02 / The reality
Where builders get stuck
No agreed source of truth
Two systems hold a version of the same job. Until someone decides which one is right about budget, committed cost and claimed revenue, every report is an argument rather than an answer.
Cost codes mapped in a hurry
The cost code to Xero mapping is built once at setup and inherited by everything after it. Mapped loosely, it produces a ledger that balances and job numbers nobody trusts.
GST assumed rather than tested
Most Australian builders handle at least one mixed-treatment invoice a month. Assuming tax codes carry across correctly, rather than running one through, is where the BAS surprise starts.
Job-level reporting that stops at the seam
If job identity does not survive into the ledger, your accountant can tell you what the business earned but not which job earned it. That is a reporting question to settle before you connect.
Progress claims treated as ordinary invoices
A staged claim against a contract sum is not the same object as a sales invoice. How it lands, and whether the contract position still reconciles afterwards, is worth watching on a real claim.
Edits made on both sides
Once a record exists in two systems, somebody eventually edits the wrong copy. Sync rules resolve that quietly and not always the way you would have chosen.
03 / The fix
A workflow that holds up
- 01
Write down which system owns what
Before connecting anything, decide on paper who owns the budget, the committed cost, the claim schedule and the payment record. A connection cannot settle an ownership question you have not answered.
- 02
Connect a demo Xero organisation first
Xero lets you work in a demo organisation. Use it. A live ledger is a poor place to discover which records a connection creates and which it duplicates.
- 03
Map cost codes deliberately
Buildertrend requires cost codes linked to Xero products and services. Do that mapping against how you actually report on jobs, not against whatever list already exists in either system.
- 04
Push one mixed-GST invoice end to end
One document with a GST-free line and a taxable line tells you more than any feature list. Check the tax codes that arrive in Xero, not just the total.
- 05
Run one progress claim and reconcile it
Raise a staged claim, send it across, then check the contract position still adds up on both sides. Retention, if you hold it, is the line most likely to need handling outside the connection.
- 06
Agree the editing rule with your bookkeeper
Decide which system a correction gets made in, write it down, and tell whoever does the books. This single rule prevents most of the reconciliation work a connection is supposed to remove.
04 / The tooling
How software helps
It is worth being precise about what a build-to-ledger connection can and cannot do, because the disappointment is usually a mismatch of expectation rather than a fault. A connection moves records and preserves the mapping you gave it. It does not reconcile two different views of a job, and it cannot invent a job dimension in the ledger that nobody configured.
So the depth that matters is specific. Does job identity survive into the ledger, so your accountant can report per job rather than per company? Do tax codes carry across intact, so a mixed-treatment invoice does not need re-coding at BAS time? Is the direction of travel per record defined, or does it depend on which system wrote last? Those three answers separate a connection that removes work from one that relocates it, and they are answerable on a demo organisation in an afternoon.
The related discipline is your own, not the software’s. Cost codes that map cleanly to the ledger, and a cost code structure you have not changed mid-project, do more for the quality of a sync than any feature on either side of it. The same goes for how GST and BAS work on building work, which is worth understanding independently of any product, because the connection will faithfully carry whatever treatment you configured.
05 / In practice
Where VIABUILD fits
How VIABUILD approaches the same seam.
For completeness, and with our cards up: VIABUILD is a competing product, so weigh this accordingly. VIABUILD connects to Xero, which stays your accounting system. We took the view that the ledger is not ours to replace, and that the interesting work is upstream of it, in the build.
The mechanics of our own sync, object by object and direction by direction, are set out on how the VIABUILD Xero sync works, which is the right page to hold us to the same standard this guide applies to anyone else. Whichever way you go, run the checks above on a demo organisation before a live job depends on the answer.
- Xero stays the accounting system
- Checks worth running on any connection
- Same standard applied to our own sync
06 / FAQ
Common questions.
That is a decision for you, not the software, and it is the one worth making first. A build system generally holds the budget, the commitments and the claim schedule because that is where the work is managed, while the ledger holds the statutory position. Problems start when both are treated as authoritative for the same number, because then a disagreement has no tie-breaker and month end turns into an investigation.
Buildertrend’s own setup material requires cost codes to be linked to the corresponding products and services in Xero, so the alignment is something you build rather than something you inherit. How that mapping then relates to your chart of accounts is worth asking Buildertrend directly, because it determines whether your accountant sees construction cost the way you do. Checked September 2026; confirm the current process with the vendor.
Buildertrend’s integration overview describes calculating sales tax; GST is not named on the pages we read in September 2026. That is a statement about the documentation, not about the product’s capability, and the reliable way to settle it is a test rather than an assumption: push one invoice carrying both a GST-free line and a taxable line into a Xero demo organisation and read the tax codes that arrive. Ask Buildertrend to confirm GST and BAS handling for Australian organisations before you connect a live ledger.
Worth watching on a real one. A staged claim against a contract sum carries a contract position with it, and ledgers generally receive it as an invoice, which is a simpler object. Raise one claim, send it across, and check that the claimed-to-date and remaining figures still reconcile on both sides afterwards. If you hold retention, check that separately, since retention is commonly handled outside this kind of connection.
Read the vendor’s own integration and help pages rather than a review site, and note the date you read them. Where a vendor names an object and a direction, that is documentation. Where a marketing page says only that it integrates with Xero, that is evidence a connection exists and nothing more. Then test the two things documentation rarely settles: tax treatment and job identity, both on a demo organisation.
About the author
Brad Caldon
Founder, VIABUILD
Brad Caldon is the founder of VIABUILD and a builder and property developer with nearly two decades across residential construction and development. He holds a NSW Home Builder Licence, is a Registered Building Practitioner across Class 1 to Class 9 buildings, and holds a Bachelor of Construction Management (Building) (Honours) from the University of Newcastle.
More about VIABUILD →07 / Keep reading
Related guides & features
See it on your own jobs.
Start with 7 days free: the full platform, your real data. $299 for your first month, then $555/mo. Month-to-month, no lock-in.