The fix: stop invoicing for the second payment and start releasing it. Fund the full project value into an escrow account up front, split it into milestones, and tie each release to a specific deliverable the client can verify. The money is committed before you pick up a tool. The second payment isn't "late" anymore because it was never sitting in the client's account to begin with.
Most contractors read a dragging second payment as a client problem — a slow payer, a bad apple, a cash-flow issue on their end. Sometimes it is. But when it happens on almost every job, across different clients, that's not a client pattern. That's a structural gap in how you collect.
Why the first payment always clears and the second one doesn't
The first payment is easy because the client wants something they don't have yet: your commitment to start. The money buys motion. Every incentive points toward paying.
By the time the second payment is due, the incentive has flipped. You've already started. Material is on site, the demo is done, the framing is up. From the client's chair, they already have most of what they're paying for. Paying you now buys them nothing new — it just moves money out of their account. So it drags. Not out of malice, usually, but because nothing is pushing it forward. You're now a creditor chasing a debtor, and you're doing it while trying to keep the job on schedule.
That's the whole trap: the point where your leverage is lowest is exactly the point where you need the client to act.
I stopped thinking of it as a payment I had to collect and started thinking of it as a release I had to unlock. That reframe changed how I wrote every contract after.— GC, remodeling
Milestones move the leverage back to the front
Escrow with milestone releases fixes the incentive, not just the paperwork. Here's the mechanic:
The client funds the full contract value into a neutral escrow account at signing. That's the hard part, and it's the part that filters out clients who were never going to pay the back half anyway — if they can't fund the project, better to know that before demo than after.
Once funded, you define release triggers: rough-in complete, inspection passed, cabinets set, final walkthrough. Each one is a verifiable event, not a calendar date and not a vibe. When you hit the milestone and it's confirmed, that portion releases to you. You're not asking the client to write a check mid-job. You're asking them to confirm work they can see — a much smaller ask, and one with a clear yes/no answer.
The result: your payment schedule stops depending on the client's willingness to part with money they already have, and starts depending on whether you did the work. That's a fight you can win every time.
What to do this week
Pull your last five jobs and mark which payment slipped. If it's consistently the middle or back payments, you have a structure problem, and no amount of politer reminder emails will fix it.
Then rewrite your next proposal around release triggers instead of invoice dates. Define three to five milestones. Attach a dollar amount to each. Make each one something a client can look at and confirm in a sentence. Front-load nothing you can't defend and back-load nothing you'll be waiting on.
The goal isn't to squeeze clients. It's to remove the moment where a client has to choose between paying you and keeping money in their account — because in that moment, you lose more often than you should.
If you want to see how milestone-based escrow terms get structured for contractor work specifically, that's worth a look before your next contract.