Invoicing App Starter · Industry version
Progress claims, retainage, and change orders modeled the way jobs are actually billed — in a codebase your firm owns.
Construction billing isn't 'invoice on completion' — it's claiming this month's percentage of each line on a schedule of values, watching retainage accrue, and folding approved change orders in without losing the paper trail. This starter models that machinery and gives you the code.
01 · The problem
A progress claim is not an invoice with a different name. It bills percent-complete per line of a schedule of values, shows previous claims against each line, and must reconcile to the contract sum every single month. A generic invoice — description, quantity, rate — has nowhere to put 'previously billed' or 'balance to finish', so contractors rebuild the claim in a spreadsheet and the invoicing tool becomes a PDF printer.
Retainage breaks generic tools outright. When the owner holds 5 or 10 percent of every claim until substantial completion, each invoice is issued at one amount and collectible at another, and thousands of dollars sit in a 'paid but not paid' state for months. Tools without a retainage concept force a choice between overstating receivables and understating revenue — both wrong, both audit findings.
And the contract sum won't sit still. Change orders add and deduct scope mid-job, each needing approval before it can be billed, and claims must distinguish original contract from approved changes. Tracked in email, unbilled change orders are the classic way trades leave five figures on a finished job.
02 · Data model
Everything in the base Invoicing starter —
clientsestimatesinvoicesline_itemspaymentsexpenses— plus the entities this industry actually runs on:
| table | what it holds |
|---|---|
jobs | The contract — client, site, original sum, retainage rate, and every claim and change order attached to it. |
schedule_of_values | The contract broken into billable lines, each carrying scheduled value, percent complete, and previously-billed amounts. |
change_orders | Scope additions and deductions with status from proposed to approved — only approved ones join the billable contract sum. |
03 · Screens
Enter this period's percent complete per line and the claim assembles itself: work completed to date, less previous claims, less retainage, equals amount due. The arithmetic that gets progress payments rejected when it's off by a dollar is computed, not copied.
Every claim's withheld amount accrues to the job's retainage balance, visible per job and in total. At substantial completion, the release invoice generates from the ledger — the money contractors most often forget to collect, kept on a screen instead of in memory.
The aging report reads the way site money actually moves — claim submitted, certified, paid — per job and per client. A GC who certifies promptly but pays slow shows a distinct pattern from one who sits on certifications, and you price the next bid accordingly.
04 · In practice
On the 25th, the foreman's percent-complete numbers go into each job's schedule of values. Claims generate with previous-billed and retainage computed, PDFs go to each GC, and the office knows exactly what was claimed where — no spreadsheet reconciliation on the 26th.
The owner wants a second panel upgrade mid-job. It's logged as a proposed change order with its price; on written approval, its status flips and it appears as a new line on the schedule of values — billable on the next claim, traceable to the approval.
Substantial completion is certified on a job that accrued eleven months of retainage. The release invoice generates from the ledger's balance, and the aging report tracks it like any receivable — because until it's paid, the job isn't done in the books.
Yes — that's the core of the variant. Each job carries a schedule of values, claims bill percent complete per line with previous claims and balance-to-finish computed, and the claim PDF presents it in the format certifiers expect.
The retainage rate lives on the job, each claim's withheld amount accrues to a per-job ledger, and the release invoice generates from the balance at completion. Different rates per job — or per line, if a contract demands it — are edits to your own schema.
Yes — change orders carry positive or negative amounts, and only approved ones alter the billable contract sum. Claims show original contract and approved changes as separate figures, which is exactly what a fussy certifier wants to see.
No — it's the money side of the job. RFIs, daily logs, and subcontractor management belong to the construction management starter; the two share conventions, so a job there and a job here can line up one-to-one.
Dual7 App Starters
Progress claims, retainage, and change orders modeled the way jobs are actually billed — in a codebase your firm owns. Describe your version to start — the output is a project you own.