Split the payment before the inspection ever enters the conversation. Your labor and your ability to pass a code inspection are two different deliverables, and they should be tied to two different payments. The moment you let both hang on a single final check, you've handed the client a free reason to hold your money.
Here's the situation you're in: the work is done, it's correct, and the client says they'll release the balance "once the city signs off." Now you're waiting on a permit office that schedules inspectors two weeks out, reschedules for weather, and reinspects for a re-tie the client's own designer changed. None of that is your labor. All of it is now sitting on your cash flow.
Whose risk is it, actually
A municipal inspection is a scheduling variable owned by the city. You don't control the inspector's calendar, the backlog, or whether a plan reviewer flags something outside your scope. When a client conditions your final payment on that event, they are transferring a risk they accepted — the risk of dealing with the permitting authority — onto you, and paying you nothing to carry it.
That's the part worth being clear-eyed about. It's not that the client is refusing to pay. They fully intend to. But they've structured the deal so that your money is captive to a third party's timeline, and they have zero incentive to chase the inspector because the delay costs them nothing. It costs you.
If your payment depends on an event you can't schedule, you're not a contractor anymore — you're an unpaid lender to the permit office.— operational rule of thumb for trade contractors
The structural fix: separate the completion from the sign-off
Milestone-based escrow solves this by decoupling the two deliverables at the money level, before the job starts.
You define the milestones in writing. "Rough-in complete and workmanlike" is one milestone, funded and released when the physical work is done and verifiable. "Passes city inspection" is a separate, smaller milestone. The client funds the full amount into escrow up front, so the money already exists — you're not negotiating over whether they'll pay, only over when each portion releases.
When your labor milestone is met, that portion releases on the work, not on the inspector's calendar. The inspection milestone stays held until the city acts. If the inspector kicks it back for something in your scope, fair — you fix it and it releases. If the delay is a backlog, a weather reschedule, or a change the client's team made, you're not floating the entire job's value while the clock runs.
Why this changes the client's behavior
The most useful part isn't the protection — it's the incentive shift. Once the money is already in escrow, the client stops treating the inspection as a reason to sit on your check and starts treating it as a task to complete. They funded it. It's committed. Now getting the inspector out benefits them, because they want their own funds resolved and their project closed.
You've also removed the single most common excuse in the book. "I'll pay when it passes" only works as a stall when the money is still in the client's account. When it's in escrow with clear release conditions, the conversation moves from *whether* to *what the inspector actually said.*
Set it up once, use it on every job
This isn't extra paperwork per project — it's a template you build once and reuse. Standard milestones for your trade, standard release language, standard split between labor and third-party sign-off. After that, every contract you write already has the inspection carve-out baked in, and you never have another job where a permit backlog quietly becomes your financing problem.
If you're structuring milestone terms that keep your completed labor from getting held hostage by an inspector's calendar, it's worth looking at how the plans are set up for exactly this kind of split.