Simpro + ServiceM8 integration
Simpro and ServiceM8 integration that finally reconciles the van and the office.
We build the middleware that makes Simpro, ServiceM8 and the ledger agree on a single job record. Australian trades and field service businesses quote in Simpro and dispatch in ServiceM8. The office re-keys labour, parts and variations on a Friday morning before the invoice goes out. The database-first move stops that reshape by making the dispatch ticket and the quote read from the same job record, then reconciling against Xero overnight, so a T&M change the tech made on the van on Tuesday is on the invoice the office sends on Wednesday.
Where Simpro and ServiceM8 break the join
Simpro holds the front-of-house spine: quote, catalogue, scheduling, scope, retention. ServiceM8 holds the field spine: dispatch ticket, labour entered on the van, parts used, photos, sign-off. Xero holds the ledger. The agreement breaks at four specific places, and the office only catches the silent drops once Friday's invoice run pulls the week's numbers together.
Quote to dispatch ticket
The scope that arrives on the van wrong
Labour updated on the van
The variation that never gets back
Parts and stock movement
Inventory that never matches the floor
Xero invoice reshape
Where the office loses Friday
How we approach Simpro and ServiceM8 integration
Discovery before anything else
We map where each piece of job, labour and parts data lives today, who edits it, and what "right" actually means. Which Simpro fields drive the ServiceM8 dispatch, which tech is the silent reconciler, where the workaround spreadsheet sits that the official systems never caught. That conversation is where the real data model comes from, not from reading the Simpro or ServiceM8 API docs in isolation.
Model the job-to-invoice join, not the API
The database-first move. Before we build anything, we write down the contract between a quote, a dispatch ticket, a labour entry, a parts movement and a Xero invoice line. Integration then becomes a question of reading from Simpro and ServiceM8, not negotiating between them after the fact. Reconcile at rest, in one place, not in the air between two vendor APIs while a tech is mid-job on a roof.
Reconciliation as a contract
Three-way reconciliation runs on a nightly schedule. The Simpro quote, the ServiceM8 ticket and the Xero invoice are compared every night. Any variance is surfaced to the office the next morning, with the job, the variation, the cost centre and what changed where. Retries, idempotency and dead-letter handling are written down before the first line of integration code. If a T&M update on the van disappears between systems, somebody finds out on day one, not in the fortnightly Xero reconciliation.
Middleware that handles vendor failures
Simpro and ServiceM8 each misbehave in specific ways. Rate limits, auth-token refresh quirks, silent payload changes on a quarterly release, the ServiceM8 mobile app failing over to offline mode and queueing labour entries for hours before they sync. We build the integration on real infrastructure with queues, monitoring and alerts, so a throttled vendor or an expired token raises a hand rather than quietly dropping a tech's labour entry. Failures show up on a morning queue tagged to the job and the cost centre, so the office catches the broken sync at standup rather than at the Friday invoice run.
AI-ready as a side-effect
The reconciliation layer we just described is also the data shape an AI agent would need to act on the business safely later. One canonical record per job, audit trail by default, permissions modelled in the database, the agent reading from the source of truth rather than reconciling Simpro and ServiceM8 each time it acts. We do not bolt agents on in this engagement, but the work leaves the business ready when the AI question lands.
We have done this since 2007. See who we are.
What this typically looks like in practice
A field service business we worked with was running Simpro for quoting and ServiceM8 for dispatch, with Xero on the ledger. Techs updated labour on the van during the job. Office staff re-keyed the variations into Simpro at the end of the week so the invoice would match. The pattern that triggered the call was a quarterly margin review where the owner noticed that T&M jobs were running consistently under-billed against actual labour. The end-of-week reshape was eating variations the techs had captured correctly on the van, and nothing in the workflow reconciled the two.
The Friday catch-up moved to a Wednesday glance at the exceptions list. A middleware layer reconciles the Simpro quote, the ServiceM8 ticket and the Xero invoice overnight, and the office picks up any drift the next morning, down to the job and the line that moved. Simpro and ServiceM8 kept doing what they already did well; the reconciliation slotted in underneath them. The office stopped re-keying variations to make the invoice match.
T&M variations stopped going missing between the van and the invoice. The quarterly margin review surfaced fewer surprises.
From the Simpro + ServiceM8 reconciliation case study
Pattern story, anonymised. No named client, dates or dollar amounts. We will publish a named case study once an Australian trades engagement has consented.
Common questions about Simpro and ServiceM8 integration
Why not use the native Simpro-ServiceM8 connector if there is one?
Try it first. If your job catalogue is clean, your T&M rates are standard and your variations follow the templates, whatever native sync Simpro and ServiceM8 ship is the cheapest correct answer and we would rather you keep the money. We bring middleware in when the native option loses labour updates that techs entered on the van, drops the conditional invoice lines that the office had to re-key, cannot model the variation-and-retention sequence the way your contracts actually work, or breaks on after-hours callouts that need to flow back to a different cost centre. The diagnostic looks at what your existing tools already cover before we quote anything new.
How does quote-to-job-to-invoice reconciliation actually work after integration?
Three places hold the truth today. The Simpro quote holds the agreed scope and price. The ServiceM8 dispatch ticket holds the labour, parts and photos captured on the van. The Xero invoice holds the billed line items. The middleware makes one of them canonical and reconciles the other two against it every night. Any variance between what was quoted, what was done and what was billed is surfaced to the office the next morning, with the job, the variation, and the cost centre. A T&M reshape that the tech did on Tuesday is in the invoice on Wednesday rather than getting lost in the fortnightly Xero reconciliation.
What if we are moving off ServiceM8 to AroFlo or Fergus?
The integration shape is the same. Quote canonical in one place, dispatch ticket canonical in one place, invoice canonical in the ledger. The vendor-specific code sits in one layer, so a migration becomes a question of rewriting that layer rather than rebuilding the whole field-to-office sync. We have built integrations into and out of ServiceM8 and AroFlo on the field side for trades businesses migrating their stack. Usually we run both feeds in parallel for a month so no job loses its history on the cutover, and the office can compare the two on a real job before signing the migration off.
How long does a Simpro and ServiceM8 integration build take?
Four to nine weeks, depending on cleanup scope. Four weeks if your Simpro catalogue is tidy, ServiceM8 dispatch templates are conventional and the variation rules are written down. Nine weeks if the catalogue has drifted for years, every senior tech has a different way of capturing labour on the van, and the back-history needs reconciliation before the nightly job can start running cleanly. The diagnostic puts a real number on the table before you commit to anything bigger. Most builds we ship sit in the five to six week middle.
Does this set us up for AI agents on top later?
Yes. Step 5 above covers the same point. The integration leaves the business with a database it controls, one canonical record per job, audit trail by default, permissions modelled in the data layer. That is the shape an agent would need to act on the field safely; adding agents later becomes a scoping question rather than a foundation question. We do not build the agents in this engagement.
Does this fix the office-vs-field visibility gap?
Yes, as a downstream second-order win once quote-to-invoice is reconciling cleanly. The same middleware that reads from Simpro and ServiceM8 can surface real-time job state to the office board: which jobs are still on the van, which ones have come back with variations, which ones are stuck waiting for a part, which ones are ready to invoice. Most trades businesses we see have the data already across both systems; nothing is collating it where the office can act on it on Wednesday morning instead of Friday afternoon. The integration is what makes that board possible without somebody rebuilding the whiteboard from scratch each week.
Not sure if your business needs middleware or a sharper Simpro setup?
Start with a conversation. We will look at how Simpro, ServiceM8 and the ledger talk today and tell you whether you need overnight reconciliation, a smaller fix, or a better Simpro setup.