One trading entity is in Xero. The other is in Sage 50, or a second Xero, or QuickBooks. Month-end is somebody exporting from both and stitching them together in a spreadsheet that only they understand. And job margin is read off invoices, which feels rigorous right up until you ask where the payroll went.
Accounting systems do not talk to each other. Xero will not read Sage, Sage will not read Xero, and neither has any idea the other entity exists. So the group view is built by hand, late, and cannot be checked by anyone but the person who built it.
The subtler problem is job costing. If cost per job is read from invoices, then anything that never arrives on an invoice is invisible to it — payroll, depreciation, foreign-currency revaluation, journal adjustments. Those costs are entirely real in the P&L. They just never reach the job margin.
The result is a board pack that reconciles at the top and is quietly wrong underneath, and nobody finds out until a project that looked profitable turns out not to have been.
A two-entity UK group (anonymised)
Built for a UK group with two trading entities — one in Xero, one in Sage 50 — working directly with the managing director, the COO and the finance lead. The client is anonymised and its own figures are withheld. What is shown is the proof that the engine is correct.
Figures are read from the production system, not estimated. Where something has not been measured, this site says so rather than filling the gap. How we count · All case studies →
A read-only connection to what you already run, and a reconciliation you can check yourself.
A read-only Xero connection that survives real conditions — one consent across organisations, token rotation handled, nothing ever written back to your books.
Sage 50 exports ingested as dated snapshots, so every figure on screen traces to the file it came from.
A group view across both entities with intercompany transactions eliminated rather than double-counted.
Job costing per project — cost to date against quoted budget — with the jobs that have no budget surfaced as a headline, not hidden in a footnote.
A reconciliation page that compares the dashboard to your accounting system's own report, cost centre by cost centre, and shows you where they match exactly and where they do not.
No. The Xero connection asks for read-only consent and the tool cannot request more. Sage is read from its own exports. Your books are the source of truth; the dashboard only reads them.
Any combination. Two Xero organisations is the simplest case, since one consent can cover both. QuickBooks has a comparable API. Sage 50 is the one that has to go through exports, and the production build handles exactly that.
Because the reconciliation is on the page, not in a promise. The dashboard is compared to the accounting system's own per-cost-centre report. In the production build, 55 of 97 cost centres match to within a penny, and every invoice in the period was accounted for on both sides. That exactness is what proves the engine correct — and it means any remaining divergence is a real feature of how the business records work, not a bug in the tool.
The client is under NDA, so the figures stay with them. In category terms: a substantial amount of real cost — payroll, depreciation, adjustments — sitting in the P&L outside invoice-based job costing, and a large share of projects with no quoted budget to measure against. Both were structural, verified by which accounts the cost sat in rather than inferred.
In a database you own, on an account you own. Tokens are stored with a lease so a crash mid-refresh cannot orphan the connection. Nothing is sent to a third party.
It depends on the systems involved and whether job costing is in scope. You get a fixed price and a delivery date before anything starts.
Tell me which system holds which entity and what month-end looks like now. If a consolidation report inside Xero would do the job, I will say so and save you the build.