A list of named stages with percentages — 30 down, 60 on delivery, 10 final, out of the box: deposit, delivery, final, the way post-frame buildings are actually paid for. The schedule lives with the job, not in one person's browser. It freezes the moment the estimate is approved, and it is what the invoices get built from. Your customer sees the same schedule on the estimate and on every bill.
Also called: draw schedule · progress payments · deposit delivery final · payment stages · instalments
The percentages always come to 100, and the number you typed stays put
Try itType 40 into the deposit and the last open stage takes the difference. A stage you typed earlier is pinned and does not move. Adding or removing a stage rebalances the same way. A schedule cannot be saved at 97% or 104% — which is the arithmetic a spreadsheet lets through, and a customer eventually finds.
Deposit 30, delivery 60, final 15, and nobody notices until the last bill goes out $4,300 over the total the customer signed.
Nobody should find out on the last bill that the percentages never added up. The rebalance takes the difference from the last stage nobody typed into — a typed percent is a decision, an untouched one is slack — so the final draw absorbs it, the one furthest from being asked for.
The schedule is stored on the job, not on the machine that typed it
Try itStages save against the job itself, under a second after you stop typing. Whoever opens the billing next reads the same three rows — different desk, different login, same schedule. Attach a job to a new bill and the draws are already on it.
The estimator sets 30/60/10 on his laptop, the office manager opens the invoice editor on hers, finds no schedule at all, and works the delivery draw out on a calculator.
Whoever does the billing should see the plan the estimator set, on any desk. Saving the schedule against the job, not the browser, means the office manager and the estimator always read the same three rows.
Save the terms you actually use and apply them in one click
If you always do 30 / 60 / 10, save it as a named preset and load it onto the next job. The estimating side and the invoice editor read the same list, so the terms your customer approved on the estimate are the terms the bill is built from — not a second version typed somewhere else in the office.
Every estimate gets its terms retyped from memory, and the one where somebody typed 25/65/10 is only found when the deposit lands short.
Your standard terms should take one click, not a memory test. A loaded preset seeds the job and is then yours to edit — so the usual deal is fast and the odd one never fights a template.
A percentage is only worth something against a number
Every stage is multiplied by the same total the customer is quoted — the one figure carried across the estimate, the card and their own page. Move the markup and the draws move with it, because no draw was ever typed in dollars.
The deposit is typed in as $18,000, the job then grows by a porch and a slab, and the customer pays a deposit figured against a price that no longer exists.
A customer trusts a deposit that matches the price he was quoted. Percentages are stored and dollars worked out, so a change in price can never leave the schedule quietly contradicting the quote.
The customer reads the same rows you typed, in his own money
On the quote the schedule is its own block — stage name, percent and the dollar figure, under a line saying payments are tied to build milestones. It sits above the signature on the estimate page he opens, so nobody signs a total without seeing when it is due.
He approves a price with no idea when any of it is owed, then rings the office the morning the deposit invoice lands asking why he is being billed already.
A customer who knows when he owes money before he signs doesn't ring the office when the bill lands. The stages sit above the signature, in his dollars — and the dots stay neutral because nothing there tracks what he has paid.
Approval freezes the schedule with the rest of the deal
Try itThe moment he signs, the payment stages lock alongside colours, markup and labour, and each stage is written down with a dollar figure against it. Changing them after that is a deliberate unlock, and the customer approves the new version — it is a re-negotiation, not an edit.
Somebody nudges the deposit from 30 to 40 a week after approval, and the first the customer hears of it is a bill $9,000 bigger than the one he agreed to.
What the customer approved is a deal — changing it should feel like re-opening one. The lock sits on the panel and every unlock is logged with a name and time, so the day the deal really changes is the only day anyone clicks it.
The stages you typed are the terms in the signed agreement
The agreement's Payment Schedule section is built from these stages — name, percent and amount, in your order. This page is the plan for the money; the document, its clauses and the signatures are on contracts that write themselves from the estimate.
The estimate says 30% down, the contract says 50% at framing, and in an argument the contract is the one that counts.
In an argument, the signed agreement is the one that counts — so it must say what the estimate said. The agreement is built from the job's own stages, and only falls back to a written 50/50 when a job truly has none.
Regenerating the schedule skips any draw that already took money
Try itBefore anything is generated, every bill already on the job is read, and any stage holding a paid or part-paid one is left out. If that leaves nothing to generate, you are told which stages were skipped, by name, instead of quietly getting a shorter list. This came out of a customer writing in to say they had already paid that — while a regenerated schedule was lining up to bill it again.
The deposit was paid in November, somebody regenerates the schedule in February, and a second deposit invoice goes to a man holding the receipt for the first.
Billing a customer for money he already paid is the fastest way to lose his goodwill. A stage with any payment on it is left out, and the skipped stages are named so a shorter list never reads as a bug.
The customer's bill says which draw it is
Try itEvery generated invoice carries its stage name, its position and how many stages there are, so it reads Stage 2 of 3 instead of arriving as another bill out of nowhere. From inside one draw you move straight to the job's others, each with its own tint, rather than closing back to the list and hunting for your place again.
Four bills for one build all read "Invoice", the customer pays the same one twice, and the office loses an afternoon working out which draw is actually still owed.
A customer who can see "Stage 2 of 3" knows exactly what this bill is for. The plan travels on the bill itself, and each stage has its own colour, so nobody pays the same draw twice.
Delivery payment, not Invoice 4
Try itThe name you typed on the estimate is the line the customer reads on his own copy of the bill — a page at its own link, no login, printable. From the moment a draw becomes a draft it is an ordinary bill: choosing the lines, sending it and recording what came in are all invoicing.
A page arrives reading "Invoice 4 — $22,384" with nothing on it saying what the money is for, and the customer's first move is to ring and ask.
A bill that says "Delivery payment" gets paid; one that says "Invoice 4" gets a phone call. The stage's name is stamped on when the bill is made, so renaming a stage later never rewrites a bill someone already paid.
Every draw sits on their dashboard, with the balance on top
Try itThe same draws appear on the project page he already has a link to — unpaid first, settled folded underneath, and what is outstanding answered before he scrolls.
He cannot remember whether the delivery draw went out, so he emails the office to ask, and somebody goes digging through the books to answer him.
A customer should never have to ask whether a draw went out. What he owes is on top and settled draws fold underneath — kept, not dropped, because a paid bill is his receipt.
A change order can join the plan instead of arriving beside it
An extra can be billed on its own, merged into a draw that is still a draft, or added to the schedule as its own payment — and when it joins, every sibling's "of 4" becomes "of 5". Each piece is entered in dollars or as a share of the change, and how each extra is delivered sets which route it takes.
The invoice goes out in March for a change the customer agreed to in November, on its own, related to nothing he signed — and now it is a conversation.
An extra that arrives as "Payment 5 of 5" gets paid; one from nowhere gets questioned. Joining the plan makes the change part of the deal he already understands, and merging only goes into drafts he hasn't seen.
- 1Set your stages and percentages on the estimate.
- 2Type one number and the rest rebalance — the total is always 100.
- 3Your customer approves, and the schedule freezes with a dollar figure on each stage.
- 4One button turns it into one draft invoice per draw.
A payment schedule that lived in one person's browser was visible to whoever built the estimate and to nobody else. The invoice editor opened on a different machine, found no schedule, and the builder doing the billing worked the draw out on a calculator. Stages live with the job now. The schedule your estimator set is the schedule the invoice reads — on any device, for anyone on your team.
- Manually working out each draw amount from a percentage.
- A schedule that lived only in one person's browser.
- Stage percentages drifting off 100%.
Save your payment terms as presets
Your named sets of terms, shared by both designers. Each one lists its stages and percentages in the dropdown, so you pick by what it does rather than by what somebody called it. Rename or delete them at any time.
Ticking an instalment books the money
The tick and the money are bound together. Tick it and a payment is recorded for the agreed amount, with the method picked right there on the row and a reference naming the instalment. Un-tick it and that payment comes back out, not just the tick.
The schedule at a glance on the card
A strip on the order card, under the journey line. It shows how many instalments are paid, how many are late, and the amount and date of the next one. Each segment is as wide as its share, so a big up-front payment looks like one.
Reminders that still make sense weeks later
The reminder opens with the due date set and a title naming the amount and the supplier. Under it, the facts: which payment of how many, the supplier, the project, the order and its total, and what is still outstanding. It also warns you when the order has material recorded short or damaged — worth settling before you pay.
Percentages that always total 100
Type a number and it sticks. The last open stage takes whatever is left. Add a stage or drop one and it rebalances the same way. The list cannot be saved at 97% or 104%.
Saved payment terms
Each preset is a full set of named stages with your percentages already on them. Terms you saved under the old three-box setup still work — they are carried forward instead of dropped.
Never re-bill a draw that was already paid
Before generating, every bill on the job is read. Any stage with a paid or part-paid one against it is left out. If that empties the run, you get the stage names back in plain English, not a shrug.
