What to Do Before You Buy Any Field Service Software

Most field-service software purchases fail for a reason that has nothing to do with the software. The business buys a tool before it understands its own data, and the new system faithfully digitises the same mess the old one had, just faster. This guide is the audit to run first, built from a real accounts-receivable cleanup done for a fire-safety inspection contractor before any software was chosen.

Start with the question nobody asks: what is your invoice number actually a key to?

Most owners assume their invoice number uniquely identifies one invoice. It is worth testing that assumption before you trust any migration, integration, or reporting feature that relies on it, because a lot of field-service software quietly relies on invoice number as if it were a primary key.

On the fire-safety engagement, a full historical sweep of the client’s invoice and quote numbering found it had never been a designed system. Invoice numbers had reached the 5,500s by late one year, then restarted in the 2000s range the next year. Quotes peaked in the 6,000s one year while the following year ran three concurrent numbering blocks at once. When the accounts-receivable audit tried to use invoice number alone to identify legacy documents, it found 10 numbers reused across genuinely different invoices within a single year’s sheet, and 106 numbers shared across two historical sheets where essentially none of the collisions were actually the same document. The real identity of an old invoice had to be reconstructed from number, site, and amount together. Number alone told you almost nothing.

If your business has more than a year or two of paper or spreadsheet history, run this test before you buy anything: pull every invoice number you have into one list, sorted, and count duplicates. If you find any, your numbering is not a key, it is a label, and any software that assumes otherwise will import garbage or silently merge two real invoices into one record.

Find out where double entry actually lives

“Double entry” usually gets described vaguely, as a general sense that staff type things twice. It is more useful to find the specific handoff points where one document becomes another document by a human retyping it, because those are exactly the points where numbers drift and errors compound.

On the paper process mapped before the fire-safety build, the pattern was: a paper work order, completed by hand in the field, came back to the office as a photograph or scan, and was manually transcribed into an Excel invoice template, which was then manually numbered. A separate Word template held the quote, assembled per client and site from boilerplate scope-of-work paragraphs. Three different document formats (paper, Word, Excel), each requiring a human to carry information from the previous one into the next by hand.

To find your own version of this, trace one real job from first phone call to paid invoice, writing down every place the information gets written down again in a different format or different tool. A phone intake note that gets rewritten into a scheduling board. A technician’s paper form that gets retyped into an invoice template. A quote that gets copied into an invoice instead of referenced by it. Every one of those handoffs is a place where the new software needs to either eliminate the retyping or, if you’re not replacing that step yet, at least not make it worse.

Which forms are actually load-bearing, and which are just habit

Not every field on your current paper form or spreadsheet earns its place. Some fields exist because someone genuinely reads them later for pay, billing, or compliance. Others exist because the pre-printed form came that way from the printer twenty years ago and nobody ever questioned it.

Before the fire-safety build, the paper work order was mapped field by field: 28 distinct fields including arrival and departure times, hours split across pay-rate classes for up to two technicians, a checklist (was the monitoring agency told, was the system disabled before work, were keys required and where), work performed, materials, and a signature. Nearly every field survived into the digital system because nearly every field had a real reader downstream: payroll needed the hours split, the office needed the checklist for liability, the customer needed the signature as proof of visit. The two fields that didn’t carry over one-to-one were merged into a single system-assigned job number, because the reason they’d existed (tracking across two separate paper books) stopped applying once the software assigned one number itself.

Do the same exercise on your own forms before buying software. For every field, write down who reads it and why. If you cannot name a reader, it is a candidate to drop. If you can, it has to show up somewhere in whatever you buy, or you will find out the hard way, usually during a payroll dispute or a customer billing complaint, that you quietly lost something that mattered.

Audit your receivables before you migrate them, not after

This is the step businesses skip most often, because it is unglamorous and it is tempting to just “bring the spreadsheet over” into the new system. On the fire-safety engagement, that temptation was resisted, and it is worth understanding exactly why.

An independent, adversarial audit of the client’s two hand-maintained Excel receivables workbooks, involving five separate re-derivations of every figure directly from the raw files, found real, business-relevant problems that a glance at the spreadsheet’s own totals would never have surfaced:

• An outstanding-receivables total in the seven figures across roughly 500 rows, of which a couple of confirmed duplicate rows were inflating the real number.
• Invoice numbers that were not a reliable identifier at all, as described above.
• Roughly 8% of the book, well over $100,000 across dozens of rows, hidden in the spreadsheet and silently included in every total while being invisible on screen, because the sheet’s autofilter range had gone stale relative to the actual data.
• 23 invoices appearing as both outstanding and paid at once, some directly contradicting each other, including one invoice with a partial-payment note for one amount while a separate payments sheet recorded two cheques totalling a different, larger figure, flagged internally as “get back to this” and never resolved.
• Roughly two-thirds of rows with no reliable “bill-to” entity recorded, only a job site address, which is not always who actually gets billed.
• A meaningful share of the outstanding book more than 90 days overdue, concentrated heavily in a small number of client relationships.

None of these defects were visible from the spreadsheet’s own summary numbers. They only surfaced because someone deliberately re-derived every figure from the raw underlying data, rather than trusting a total that already looked plausible. Every import defect found this way was resolved by an explicit decision, not a silent guess: the rule applied throughout was that ambiguity creates a question for human review, never an assumption baked in quietly.

If you are moving your own receivables into new software, do not let the migration tool decide what to do with duplicate rows, mismatched bill-to entities, or contradictory payment status. Find those problems first, decide what’s correct by hand, and only then migrate. A fast import of bad data is not a faster business, it is the same mess with a nicer interface.

The audit checklist

Run this before you sign anything, not after:

1. Pull every invoice number from your last two years and count duplicates. If you find any, invoice number is not a reliable key in your data, and you need to know that before any vendor’s “auto-import” promises to make it one.
2. Trace one real job start to finish and mark every handoff where a human retypes information into a new format. That list is your actual double-entry map, not a guess.
3. Field-map your current forms. For every field, name who reads it later. Drop what nobody reads. Carry forward what someone does.
4. Re-derive your receivables totals from raw data, independently of the spreadsheet’s own summary formulas. Look specifically for hidden or filtered rows, duplicate rows, and invoices marked both paid and outstanding.
5. Decide your numbering cutover date now, before you buy software, so you’re not making that decision under deadline pressure during a live migration.

This audit takes real time, usually longer than most businesses expect. It is also cheaper than finding these problems after they’ve been imported into a new system and are now presented back to you with a more confident-looking interface. Software cannot fix a receivables ledger it never got the chance to question.