← All posts
How to

Managing Carpenter and Contractor Payments

Managing Carpenter and Contractor Payments: how to run procurement so a PO never goes out at the wrong rate and margin stops leaking between quote and delivery.

7 min read

Material has a bill you can check. Labour has a running account in a diary, a carpenter who says "sir, thoda advance chahiye" every Saturday, and a slow, cheerful erosion of your margin that nobody can quite reconstruct at the end of the job. Paying carpenters and contractors is where a lot of studios lose the most money and keep the worst records, and the two facts are related. This is for studio owners who want to pay their site team fairly and on time without losing track of what they've paid for, so let me lay out how I run it.

The running-account trap

Here's the pattern that catches almost everyone. The carpenter starts work, takes an advance, takes another one two weeks later, then a bit for materials, then some for his labour, and it's all noted in a diary or a WhatsApp thread as lump sums with no clear link to what was actually finished. By the time the wardrobes are up, you've paid a number, and you genuinely cannot say whether it matches the work, because the payments were never tied to measured, completed items.

That's the running-account trap, and it's a first cousin of the leaks I described in how to stop procurement margin leaks. Money paid against a vague sense of progress is money you can't audit, and money you can't audit is money that quietly overshoots. The whole fix is to make every payment answer a simple question: what completed work is this rupee paying for?

Pay against measured work, not against the calendar or the mood

The cleanest principle in the whole topic is this: pay for work that's done and verified, not for time that's passed or pressure that's applied. A carpenter should be paid for the wardrobe carcass that's built to spec, measured, and checked, not for "he's been here three weeks" and not because it's Saturday and he asked.

That means you need a measurement basis, which is where your quantities matter. If you costed the joinery off a proper breakdown, and if you're clear on the difference between what you specified and what's actually installed, you can pay stage by stage against verified quantities. This is exactly why the distinction I drew in BOQ vs BOM in interior projects is practical rather than academic: the quantities you approved are the quantities you pay against, and the furniture, fixtures and equipment that's actually standing on site is what you verify before releasing money.

Structure the payments in stages, and write the stages down first

Vague payments come from vague terms. If you agree the payment stages before the work starts, in writing, the running account stops being a mystery and becomes a schedule. Here's a stage structure that works for most carpentry and contractor scopes.

StageTriggerTypical releaseWhat you verify
Mobilisation advanceWork confirmed, material stagedA modest advanceMaterials on site, right spec
First milestoneCarcasses built and placedAgainst measured workQuantity and spec match the approval
Second milestoneShutters, finishes, hardware fittedAgainst measured workFinish quality, hardware brand
Snag clearancePunch list clearedBalance minus retentionEvery snag closed
Retention releaseDefect period passedFinal retentionNo defects surfaced after handover

The retention line at the bottom is the one studios skip and regret. Holding back a small percentage until the defect period passes is what keeps a contractor coming back to fix the hinge that dropped a month later, instead of disappearing the day the final payment cleared.

Verify with a snag list before the milestone payment, not after

The trigger for a milestone payment should never be "the carpenter says it's done". It should be "we checked it against a list and it's done". A punch list walked before you release the milestone is the difference between paying for finished work and paying for nearly-finished work that stays nearly-finished forever, because once the money's out, the urgency to close the last 10% evaporates.

So the sequence is: contractor reports the milestone, you (or your site lead) walk the snags, the snags get closed, and only then does the payment release. It feels slower for one afternoon and it saves you weeks of chasing across the life of the project, which is exactly the kind of timing the project timeline template is built to hold.

Before you release any milestone payment

  • The work for this stage is measured against the approved quantity
  • The spec, finish and hardware match what the client signed off
  • The snag list for this stage is walked and cleared
  • Retention for the stage is held back, not released early
  • The payment is recorded against this specific stage, not as a lump sum
  • Any TDS you're liable to deduct is accounted for on the payment

Keep labour and material separate, and keep the client's view clean

Two more habits save real money. First, keep labour payments and material payments distinct even when the same contractor supplies both, because bundling them is how you lose the ability to check either. Second, remember that a chunk of these payments correspond to work the client is paying you for, so the milestone you verify on site should line up with the milestone you bill the client.

That alignment is quietly powerful. When the client approves a stage in their portal and you bill that stage, and the contractor's milestone maps to the same stage, your cash in and cash out move together, and you're never funding the contractor out of your own pocket while waiting on the client. Setting that client side up cleanly is what I covered in how to set up a branded client portal for your studio, and the billing side is the same flow that turns a quote into a GST invoice without re-keying.

1
question every payment must answer, which completed work it pays for
5
clean payment stages instead of one unauditable running account
0
milestone payments released before the snag list for that stage is cleared

Where contractor payments should live

The reason contractor payments end up in a diary is that most studios don't have anywhere better, so the answer is to give them somewhere better: a place where each payment is recorded against a stage, tied to the verified work, sitting next to the client billing it corresponds to. That's the everyday case for running the studio in one connected system rather than splitting it across a diary, a chat thread and a spreadsheet, and if you're comparing tools for it, the best software for interior designers in India guide is the broader view.

In Designa, payment requests, approvals and the transactions ledger sit in the same workspace as the project's specs, milestones and client billing, so a contractor payment is recorded against the stage it belongs to and you can always answer what it paid for.

Key takeaways

  • The running-account trap is paying lump sums that were never tied to completed, measured work
  • Agree the payment stages in writing before work starts, and pay against verified quantities
  • Walk the snag list before the milestone payment, because urgency to finish dies once money is out
  • Hold retention until the defect period passes, and align contractor milestones with client billing

Frequently asked questions

How should I structure carpenter and contractor payments?

Agree stages in writing before work starts, a mobilisation advance then milestone payments against measured, verified work, with retention held until the defect period passes, so every payment maps to completed work.

Why is paying contractors in lump-sum advances a problem?

Because lump sums tied to nothing measurable can't be audited against the work done, so payments quietly overshoot the actual progress and you can't reconstruct where the money went.

Should I hold retention on contractor payments?

Yes, holding back a small percentage until the defect liability period passes is what keeps a contractor returning to fix later defects instead of disappearing once the final payment clears.

Can Designa track contractor payments against project stages?

Yes, payment requests, approvals and an org-wide transactions ledger in Designa record each payment against the stage and verified work it belongs to, alongside the client billing it corresponds to.

If your contractor payments live in a diary you can't reconcile, seeing them recorded against real project stages is worth a click through the live setup at demo.designa.work, and when it fits it's one flat founding price for your whole studio, billed in rupees with unlimited free client logins, at go.designa.work.

Run your whole studio on Designa

One flat founding price for your whole team, every module included, with a 7 day money back guarantee. See exactly how it works, then get started today.