Simpro + ServiceM8 integration
Simpro and ServiceM8 integration that finally reconciles the van and the office.
If you run Simpro alongside ServiceM8 and the office re-keys labour, parts and variations every Friday before the invoice goes out, here is how we would approach it. Australian trades and field service businesses quote in Simpro and dispatch in ServiceM8, and the reshape eats a Friday morning every week. A database-first move would stop 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 lands 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 would approach Simpro and ServiceM8 integration
Discovery before anything else
We would 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 building anything, we would 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 would run on a nightly schedule. The Simpro quote, the ServiceM8 ticket and the Xero invoice get compared every night. Any variance surfaces to the office the next morning, with the job, the variation, the cost centre and what changed where. Retries, idempotency and dead-letter handling get 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 would 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 would 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 described above 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 would not bolt agents on in an integration engagement, but the work would leave the business ready when the AI question lands.
We have done this since 2007. See who we are.
What this would typically look like in practice
Picture a field service business running Simpro for quoting and ServiceM8 for dispatch, with Xero on the ledger. Techs update labour on the van during the job. Office staff re-key the variations into Simpro at the end of the week so the invoice will match. The pattern that usually triggers the call is a quarterly margin review where the owner notices that T&M jobs are running consistently under-billed against actual labour. The end-of-week reshape eats variations the techs captured correctly on the van, and nothing in the workflow reconciles the two.
A database-first approach would put a middleware layer in the middle of that. Each night it would reconcile the Simpro quote, the ServiceM8 ticket and the Xero invoice against each other, and the office would pick up any drift the next morning, down to the job and the line that moved. Simpro and ServiceM8 would keep doing what they already do well; the reconciliation would slot in underneath them. The aim is to move the Friday catch-up towards a Wednesday glance at an exceptions list, so the office stops re-keying variations to make the invoice match.
The aim of a database-first approach: T&M variations stop going missing between the van and the invoice, and the quarterly margin review surfaces fewer surprises.
From the Illustrative Simpro + ServiceM8 reconciliation case study
Illustrative pattern, not a specific client engagement. The database-first approach above is how we would take it on.
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. Middleware earns its place 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 anyone quotes anything new.
How would quote-to-job-to-invoice reconciliation work if you built it?
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 pattern we would propose 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 would surface 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 would be 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 would be the same. Quote canonical in one place, dispatch ticket canonical in one place, invoice canonical in the ledger. A database-first shape keeps the vendor-specific code in one layer, so a migration becomes a question of rewriting that layer rather than rebuilding the whole field-to-office sync. The sensible approach during a stack change is to 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. If you are mid-transition between field tools, the honest first step is a discovery call to map what you run today before we say anything about shape or scope.
How long would a Simpro and ServiceM8 integration build take?
A realistic range is four to nine weeks, depending on cleanup scope, with the five to six week middle the common case. 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. We do not quote a build before we have mapped your actual data.
Does this set us up for AI agents on top later?
Yes, in principle. Step 5 above covers the same point. A database-first integration would leave 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 would not build the agents in an integration engagement.
Would this fix the office-vs-field visibility gap?
It would, as a downstream second-order win once quote-to-invoice is reconciling cleanly. The same layer that reads from Simpro and ServiceM8 could 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 talk to already have the data across both systems; nothing is collating it where the office can act on it on Wednesday morning instead of Friday afternoon. A database-first layer is what would make 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.