PolarPath Journal

The Change Order Nobody Billed: How Mixed Service and Project Shops Lose Margin Without Realizing It

The Change Order Nobody Billed: How Mixed Service and Project Shops Lose Margin Without Realizing It

The Change Order Nobody Billed: How Mixed Service+Project Shops Lose Revenue Without Knowing It

There is a specific kind of revenue loss that does not show up as a bad debt, a disputed invoice, or a customer who never paid. It shows up as margin that was lower than expected on a job you thought went fine. The work was done. The crew was on-site. The scope changed. Nobody billed it.

This is the unbilled change order, and in shops that run both reactive service calls and planned projects, it is the quietest and most consistent revenue leak in the business.


Why Mixed Shops Are Especially Vulnerable

A pure service shop has a relatively simple loop: a call comes in, a tech goes out, the ticket closes, an invoice goes out. The scope is usually what it was dispatched as, or close to it.

A pure project shop has formal change order processes baked in from the start. The contract structure demands it.

A mixed shop, which is the reality for most HVAC, electrical, mechanical, and facilities contractors in the GTA and across Ontario, is running both models simultaneously, often with the same people. A project manager is tracking a two-month mechanical fit-out while dispatch is fielding three emergency service calls on the same afternoon. The disciplines bleed into each other.

When they do, the change order process is usually the first thing to slip.

The Three Moments When a Change Order Gets Lost

Understanding where the leak starts is more useful than any invoice audit after the fact. In mixed shops, unbilled change orders almost always escape at one of three moments:

1. In the field, when the tech or crew lead makes a judgment call.

A technician arrives on a planned maintenance job and discovers corroded wiring that was not in scope. She fixes it because it is the right thing to do and the customer is standing there. She notes it verbally on the way out. It never makes it into the work order in a way that triggers a billing line. The invoice goes out for the original scope. The extra hour and materials are absorbed silently.

2. In the handoff between field and office.

The crew submits their time and materials at the end of the day. Someone in the office is processing work orders from six jobs and a dispatch queue that has already moved on. The notes say "added two breakers, customer approved." There is no clear path from that note to a change order document to an invoice line. It falls through.

3. When a project transitions from planned to reactive mid-stream.

A facilities client calls with an urgent repair during an active project. The PM pulls a tech off the project to handle it, intending to bill it as a separate service call. By the time the project closes out, that service call has either been absorbed into project costs or simply forgotten in the final invoice reconciliation.


What the Leak Actually Costs

Here is a way to think about the scale without inventing numbers. Picture a shop doing 20 projects per year, mixed with ongoing service volume. If even one modest change order per project goes unbilled, and those change orders average two to four hours of labour plus materials, the compounding effect over a year is real and material. It does not show up as a line item anywhere. It shows up as a margin question at year-end that nobody can fully answer.

The problem is not that the work was too small to bother with. The problem is that the process had no moment where someone was forced to look at scope versus what was actually done and reconcile them before closing the job.


How to Catch Unbilled Change Orders at the Source

The fix is not a policy memo. Policies do not survive contact with a busy dispatcher or a tech finishing a job at 6 p.m. The fix is a process that makes it structurally difficult to close a job without addressing scope changes.

Step 1: Give the field a specific, low-friction way to flag scope additions in real time.

This means a mobile-accessible work order or field log where adding a line item is as easy as adding a note. The trigger question is: "Did you do anything today that was not on the original work order?" If yes, it should take less than two minutes to document it on the spot, with a materials list and a labour note. If it takes longer than that, it will not happen consistently.

Step 2: Create a "pending change order" status that blocks job closure.

This is the structural guardrail. If a field log has a scope addition flagged, the job cannot move to "ready to invoice" until someone has reviewed that addition and either created a change order or made a conscious decision to absorb it. The key word is conscious. The current state in most shops is unconscious absorption: it happens without anyone deciding it should.

Step 3: Separate the approval workflow from the billing workflow, but link them.

Customer approval of a change order and the billing of that change order are two different steps, but they need to be connected in the same record. A common failure mode is verbal approval in the field that never makes it to a document, or a document that gets approved but sits in a folder instead of triggering an invoice line. The change order document, the approval, and the invoice line should all live in the same thread.

Step 4: At project close-out, run a scope reconciliation before finalizing the invoice.

On any planned project, the final invoicing step should include a mandatory comparison: what was in the original contract versus what was actually done, including all change orders. This is not a post-mortem. It is a billing checkpoint. The question is simple: is there anything that was done, approved, or flagged that is not on this invoice?


A Simple Pre-Invoice Checklist for Mixed Shops

Before closing any job or project, run through these:

  • Does the final invoice total match the original contract or quote plus all approved change orders?
  • Are there any field notes, crew log entries, or material requisitions that do not correspond to a billing line?
  • Were any emergency or reactive tasks performed during this project that were billed separately? If yes, are they accounted for?
  • Were any change orders verbally approved in the field but not documented in writing?
  • Did the job require any permit, inspection, or compliance work outside the original scope?

If the answer to any of these is "I'm not sure," that is the leak.


Where the Operational Layer Makes the Difference

The underlying issue in most mixed shops is not discipline. The people running these businesses are disciplined. The issue is that the tools they use were not built for the handoff between field execution and project billing. A dispatch tool does not know what is in the project contract. A project management tool does not see the field log from yesterday's service call. The connection between them is a human, usually under pressure, trying to reconstruct what happened.

PolarPath was built specifically for this operational reality: the shop that runs service work and project work out of the same team, where a change order on a mechanical fit-out and an emergency call from a facilities client are both live at the same time. The platform keeps the scope record, the field log, and the invoice in a single continuous workflow. When a tech documents a scope addition in the field, it surfaces as a pending item in the project record, not a note buried in a text message.

That kind of structural visibility is what makes "the change order nobody billed" something you can actually catch before it disappears into margin.


The Practical Takeaway

You do not need to overhaul your billing process to stop this leak. You need one well-placed structural step: a moment in your workflow where someone is required to look at what was done versus what was scoped, before the invoice goes out. Build that moment into your job closure process, make it mandatory, and give your field team a fast way to flag scope additions in real time. The revenue is already being earned. The goal is making sure it gets collected.

If you want to see how that workflow looks when it runs in one connected platform, polarpath.ca is a good place to start.