How Accounting Integration Works in Field Service Software
Accounting integration is where your operations software meets your bookkeeper, and it is the most common source of friction in the whole stack. Most of the trouble comes from two decisions made at setup and never revisited.
Integration means four record types moving between systems: customers, invoices, payments and items. Each has a direction, and getting the direction wrong creates duplicates that take months to untangle.
The two setup decisions that cause most problems: which system owns the customer record, and how your services map to accounting items. Both are hard to change later.
Desktop and cloud versions are not the same thing
Worth establishing first, because it narrows your options more than any other factor.
Cloud accounting platforms expose modern APIs, so integrations are generally live, two-way and maintained by the software vendor. Desktop accounting software typically requires a local sync utility running on a machine that has to be switched on, and the connection is more fragile.
| Cloud accounting | Desktop accounting | |
|---|---|---|
| Connection | Direct, over the internet | Local sync tool on a specific machine |
| Timing | Near real-time or scheduled | Batch, when the machine is on |
| Reliability | Generally good | Depends on that machine staying available |
| Platform support | Nearly all field service software | Fewer platforms, and depth varies a lot |
If your bookkeeper uses a desktop version and will not move, that constraint should shape your shortlist from the beginning rather than being discovered during implementation. Some platforms handle desktop integration well and many handle it barely at all.
What moves, and in which direction
Customers — one direction only
Almost always from field service software into accounting, because that is where customers are created — by a CSR taking a call.
Do not enable two-way customer sync. It sounds convenient and it is how you end up with “Martin, J.” in one system and “J Martin” in the other, both syncing, both creating partners for each other. Untangling a duplicated customer list across two systems is a job measured in weeks.
Pick one system of record for customers, and enter them only there. This is the same principle that governs running a CRM alongside field service software.
Invoices — one direction, and usually final
Created in field service software when the work is done, pushed to accounting for the books.
The question to ask: what happens if an invoice is edited after syncing? Some platforms push an update. Some create a second invoice. Some silently do nothing, leaving the two systems disagreeing about what the customer owes. Find out which before you need to know.
Payments — one direction, with a reconciliation catch
Payments captured on site sync to accounting. Straightforward in principle, with one wrinkle worth understanding: bundled card processing usually deposits net of fees.
So a $1,200 invoice arrives in your bank as roughly $1,163 after processing costs. Your accounting software needs to record the full $1,200 against the invoice and the difference as a fee expense, or your bank reconciliation will not balance and your revenue will read low. Good integrations handle this automatically. Ask specifically, because it is tedious to fix by hand every month. The scale of those fees is covered in payment processing fees.
Items — the other direction
Accounting software holds the item or product list that determines which account each line of revenue lands in. Your field service price book has to map onto it.
This is the second setup decision that causes lasting problems.
A price book with 800 tasks does not need 800 accounting items. It needs a manageable set of revenue categories — service labour, maintenance, replacement equipment, parts, agreements — that your bookkeeper can actually report on.
Map many tasks to few items. Too granular and your profit and loss becomes unreadable. Too coarse and you cannot tell replacement revenue from service revenue, which is the one split that matters most in this business.
Agree the categories with your bookkeeper before configuring anything, because remapping after six months of transactions means restating the history.
Sync timing
Real-time. Each record syncs as it is created. Cleanest, and it means the two systems never diverge by more than a moment.
Scheduled batch. Every hour, or nightly. Adequate for most shops and gentler on desktop setups.
Manual. Someone presses a button. Fine if it happens daily. It never happens daily.
Whichever applies, one question matters more than frequency: where do failures surface? A sync error that appears in a log nobody opens is a discrepancy that grows for a month before anyone notices. You want failures visible to a person who will act on them.
What breaks, and why
| Problem | Usual cause | Prevention |
|---|---|---|
| Duplicate customers | Two-way sync, or the same customer entered in both systems | One system of record. One direction only |
| Invoices not appearing | An unmapped item, a missing tax code, or a required field left blank | Complete the item mapping before going live |
| Bank reconciliation off | Net deposits not split into revenue and fees | Confirm the integration handles processing fees |
| Revenue in the wrong account | Price book tasks mapped to a default catch-all item | Map deliberately, with the bookkeeper |
| Desktop sync stops | The host machine was switched off, updated, or moved | A dedicated always-on machine, and a monitoring habit |
| Tax calculated differently | Two systems with independent tax settings | Decide which system calculates tax and disable the other |
That last row deserves attention if you operate across multiple tax jurisdictions. Two systems each computing tax their own way produces invoices that do not match the books, and it is a genuinely unpleasant problem to unwind.
What to verify before choosing a platform
Six questions, and get them answered before shortlisting rather than during implementation:
- Which accounting products and versions are supported? Including desktop, specifically, if that is what you use
- Which records sync, and in which direction? Ask for it in writing
- How are processing fees handled on deposit? Automatically split, or manual
- What happens when a synced invoice is edited?
- Where do sync errors appear, and who gets told?
- Which system calculates tax?
And one thing to do rather than ask: have your bookkeeper sit in on the demo. They will spot in five minutes what you would discover in month three, and their objections are usually the ones that matter.
Frequently asked questions
Should customer records sync in both directions?
Does desktop accounting software integrate as well as cloud versions?
How should price book tasks map to accounting items?
Why does my bank reconciliation not balance after integrating?
What happens if I edit an invoice after it has synced?
Which system should calculate sales tax?
What to do next
- Ask your bookkeeper which product and version they use, and whether they will move. That answer constrains your shortlist.
- Agree your revenue categories with them before configuring any item mapping.
- Confirm in writing which records sync and in which direction, and disable two-way customer sync.
- Have your bookkeeper attend one demo. Five minutes of their attention saves months of reconciliation.
- How flat-rate price books work — the structure that has to map to accounting items
- Payment processing fees — why deposits arrive net
- How data migration works — moving customer records without duplicating them
Integration capabilities, supported versions and sync behaviour vary considerably between field service platforms and change with releases. This guide describes general patterns rather than any specific product. Confirm what a given integration actually does — in writing — before committing, and involve whoever maintains your books.