Meta Title: Xero Plus What? The Software Stack Architects Use for Jobs
Meta Description: Xero handles the ledger, not the job. What architecture practices add on top to run projects end to end, and how the two systems should connect.
Xero plus what? The software stack architects actually use to manage jobs end to end
TL;DR Xero is an excellent general ledger and a poor job costing system, because it is organised by account code and period rather than by project and phase. Architecture practices close that gap by adding a job layer that holds the fee proposal, the hours, the consultant costs and the project record against each project, then feeds clean transactions back into Xero. This article sets out what that layer has to do for a practice specifically, and why the join between the two systems is the part worth getting right.
What Xero is for, and where it stops
Xero answers questions about the practice. What did we bill last quarter, what are we owed, what is sitting in accounts payable, what does the profit and loss look like against last year.
Those are the right questions for a director, an accountant and a bank. They are not the questions you have on a Tuesday afternoon when a client asks whether the additional design work on stage three is within fee.
That question is about one project, at one phase, right now. Answering it requires knowing the agreed fee for that phase, the hours recorded against it, the consultant costs committed to it, and how those three compare. Xero holds none of that in a usable shape, not because it is deficient, but because a general ledger records transactions by account and period. A project is neither.
The gap is structural, and no amount of configuration inside Xero closes it entirely.
The tracking category approach, and where it runs out
Xero does offer a way to slice the ledger by project. Tracking categories let you tag transactions so revenue and costs can be reported against a project code.
For a small practice running a handful of projects, this works reasonably well for the questions that involve money already transacted. It tells you what has been invoiced and what has been spent against a project.
It runs out in three specific places, and all three matter for an architecture practice.
It cannot see unbilled work. Hours recorded but not yet invoiced are not transactions, so they never reach the ledger. The largest single asset in most practices at any given moment is work in progress, and the tracking category view is blind to it.
It cannot compare against a fee. The agreed fee proposal is not a transaction either. Without it, you can see what a project has cost you, but not whether that cost is reasonable against what you agreed to charge.
And it does not scale in structure. A practice running projects across multiple phases, with additional services agreed along the way, quickly needs more dimensions than a flat tracking category list comfortably provides.
The conclusion is not that tracking categories are wrong. It is that they are a reporting convenience layered on a system built for something else, and a practice past a certain size needs the job to be a first class object rather than a tag.
What the job layer has to hold
The second element in the stack is a job management system, and for an architecture practice it needs to carry four things that Xero does not.
A fee proposal that stays measurable
The fee proposal needs to survive as an operational baseline, not just a document sent to the client. That means the phase structure and the effort assumptions behind each phase remain attached to the project.
Quoting and estimating produces quotes with line item pricing, time estimates and cost breakdowns, which is what makes the later comparison possible. A fee expressed only as a lump sum per stage tells you at the end whether the stage made money. A fee expressed as estimated hours by phase tells you which assumption was wrong, which is the thing you can act on next time.
Time captured where architects actually work
Architectural time is not generated at a desk in neat blocks. It accumulates in site visits, contractor meetings, consultant coordination calls and client presentations, most of which happen away from the machine where the timesheet lives.
Two capture points matter more than any others for a practice.
The mobile app covers work away from the office, supporting time entry, cost capture and expense receipt uploads for staff on site or travelling, with entries syncing to the desktop platform so job costing reflects them without a later reconciliation step.
The integrated calendar covers the other half, syncing with Outlook and Google Calendar so meetings can be converted into time entries using their actual durations. For a practice where coordination meetings are a genuine cost of delivery, this is the difference between recording them and estimating them at the end of the week.
Consultant costs attached to the project that incurred them
Architecture practices carry a cost profile most professional services firms do not. Structural, services, fire, acoustic and planning consultants are frequently engaged through the practice, and those costs need to sit against the project rather than arriving as loose bills in accounts payable.
Purchase orders keep supplier costs linked to the work they relate to from the point the order is raised, with partial or full receipts recorded as they arrive. The effect is that a consultant fee is visible against the project as a committed cost before the invoice appears, which is the only point at which it is still useful to know.
The project record in the same place as the numbers
This is the layer most often left out of stack discussions, and for architects it is not optional.
A project generates drawings, specifications, certificates, approvals and correspondence, all of which are the practice's evidence of what was agreed and when. Document management keeps that material centralised against the project it belongs to.
Correspondence can be filed the same way. WorkflowMAX lets a practice set up an organisation email address so that forwarding an email with the job number in the subject line automatically files the message and its attachments against that job, with anything unmatched landing in the Collaboration Manager inbox for manual assignment.
The reason this belongs in a financial stack rather than a separate document tool is straightforward. When a fee dispute arises, the evidence and the numbers need to be in the same place, retrievable in the same search, by the same person.
The join is the part worth getting right
Two systems only beat one system if the connection between them is genuinely automatic. Otherwise a practice ends up running two ledgers and reconciling them by hand, which is worse than either alone.
The Xero integration is native and bi-directional rather than a third party connector. Three details matter more than the headline.
Invoices flow to Xero as either draft or approved, at your choice, which lets a practice decide whether a director reviews before the invoice is live. Payment statuses sync back automatically, so job financials and aged debtor reports stay current without anyone updating them.
Revenue account codes and tracking categories can be mapped at three levels: a generic default, by job category, or down to individual tasks and costs. That last level is what allows a practice to keep a meaningful chart of accounts in Xero while running detailed job structures in the job layer, rather than forcing one to mirror the other.
On the cost side, purchase orders themselves do not sync, because a purchase order is a request to buy rather than a financial transaction. When the order is receipted, the resulting cost entry becomes a bill in Xero as an accounts payable item. The practical result is that a consultant engagement appears against the project immediately, and hits the ledger when it actually becomes a liability.
Two systems, one direction of travel
Assembled properly, the stack has a clear division of labour. The job layer runs the project from fee proposal to final invoice, holding effort, cost, documents and value against each project and phase. Xero runs the practice, holding the ledger, the payables, the receivables and the statutory reporting.
Everything moves in one direction operationally and returns as a status. Work is recorded once, against a project, and arrives in Xero as a properly coded transaction.
The test of whether a practice has this right is not how many tools are in the stack. It is whether anyone in the office ever types the same number into two systems. If the answer is yes, the join is where the problem is, and adding a third tool will not fix it.
See how the join works on a live project
The clearest way to judge a stack is to run one real project through it, fee proposal to invoice, and watch what reaches Xero. WorkflowMAX offers a 14 day free trial, which is enough to connect your Xero account and test the flow on a single live project. If you would rather walk through it with someone, you can book a demo with the team.
