PolarPath Journal

The Change Order That Nobody Wrote Down: How Unbilled Field Work Quietly Kills Your Margin

The Change Order That Nobody Wrote Down: How Unbilled Field Work Quietly Kills Your Margin

The Change Order That Nobody Wrote Down: How Unbilled Field Work Quietly Kills Your Margin

The tech showed up, found extra work, called the site super, got a verbal go-ahead, did the work, and moved on. Three weeks later, when the invoice went out, nobody billed for it. Not because anyone was dishonest. Because there was no paper trail. Just a conversation in a parking lot that nobody wrote down.

That scenario plays out constantly in HVAC, electrical, mechanical, and facilities shops that run a mixed service-and-project model. The extra work gets done. The customer is happy. The margin disappears.


Why Verbal Approvals Are a Business Risk, Not Just an Annoyance

The verbal approval feels like the path of least resistance in the moment. The super says yes, the tech starts working, the job gets done. The problem is that "yes" lives in two people's heads, and those heads are not attached to your invoice.

By the time billing happens, the chain of custody has broken. The PM doesn't know the scope changed. The dispatcher didn't update the work order. The controller invoices to the original PO. The change order that should have added $800 or $8,000 to the job never gets raised.

This is not a people problem. This is a process architecture problem.

The standard workaround is to ask the field tech to call or text someone back at the office, who then creates a change order in whatever system the company uses, and emails it to the PM, who chases the customer for a signature, and then hopefully tells the controller. Every one of those handoffs is a place where the change order dies.


The Specific Moment Where the Money Goes Missing

Here is the mechanics of the failure, step by step:

  1. Tech identifies scope outside the original work order.
  2. Tech calls or texts the site contact. Gets verbal approval.
  3. Tech does the work and moves to the next call.
  4. No one at the office raises a change order because no one knows the scope changed.
  5. Invoice goes out at original scope. Customer pays it. Nobody notices.
  6. PM finds out six weeks later when reviewing the job cost report and sees labour and materials that don't match the billed amount.

At that point, the conversation with the customer about the unbilled work is awkward at best and a write-off at worst. You did the work. You paid the tech. You bought the materials. You just didn't collect.

This is not a one-job problem. For a shop doing 20 to 50 service calls a week alongside half a dozen active projects, small unbilled change orders compound fast across a month.


A Better Process: Raise It at the Source

The fix is not more follow-up calls or a stronger "remember to bill your change orders" reminder at the Monday meeting. Those work for a week.

The structural fix is to make it easier to raise the change order at the moment the scope changes than to handle it any other way.

Concretely, that means:

  • The tech raises it from the field, right there at the site, before the work starts or as it is happening.
  • Site photos go onto the change order as documentation, not an afterthought. "Here is the corroded valve we found. Here is the extra pipe run." That documentation protects you if the customer disputes the charge.
  • The change order lives on the job from the moment it is created, attached to the work order, visible to the PM and the controller.
  • It sits in an approval queue until someone with authority signs off, and that approval is timestamped and stored.
  • Once approved, it moves to billing automatically, so there is no separate step of "remembering to invoice for the extra work."

That sequence is what PolarPath's change order tracking module does. A tech raises a change order from the field with site photos attached. It sits in an approval queue against the job. When the approval comes in, the change order is already tied to the job record, already visible in the billing workflow. The parking-lot conversation becomes a tracked, documented line item with a signature on it.

The change order is not a separate document floating in someone's email. It is part of the job.


What to Look for in Any Change Order Process

If you are evaluating your current process or building a new one, these are the questions that matter:

Where does the change order get created? If the answer is "back at the office, after the tech reports in," you have already introduced a handoff that can fail. The closer to the field, the less can fall through.

What documentation travels with it? A change order without supporting documentation is a negotiation, not a record. Photos, field notes, and scope descriptions are what turn a disputed charge into a paid invoice.

Is it attached to the job, or floating in email? A change order that lives in an email chain is invisible to anyone not on that chain. It needs to be on the job record so the PM, controller, and billing team can all see it without asking.

Is the approval stored? A customer who approved the work verbally may not remember it clearly when the invoice arrives. A timestamped approval with a name on it is worth more than a text message.

Does approval trigger billing, or is that a separate step? If someone has to remember to take the approved change order and add it to the invoice, that is another place where it disappears.


Practical Takeaway

Unbilled change orders are not a character flaw in your team. They are a predictable output of a process that makes it harder to document scope changes than to skip them.

Start with one rule: no work outside the original scope starts without a written change order, even if the approval comes verbally first. Then build the process so that writing the change order is the easiest thing the tech can do in that moment, not a bureaucratic hurdle they will work around.

If your current tools make field-raised change orders cumbersome, that is the problem worth fixing first.

What does your shop currently use as the trigger for raising a change order: is it the tech's call, the PM's call, or does it depend on who catches it first?