Three ways a change order reaches the customer's bill

Bill it on its own, give it its own payment plan, or fold it into the agreed schedule — each explained in plain language before you choose.

What it is

Delivery_mode is one of separate, split or merge, each with a human label and a blurb: 'Bill it on its own — One standalone invoice. Leaves the agreed payment schedule untouched — the safest option, and the most common'; 'Give it its own payment plan — The change order gets its own titled schedule of payments'; 'Fold it into the payment schedule — Spread across the remaining stages of the agreed schedule. Changes amounts the customer has already seen.' Underneath, divisions let one change order be split into free-form buckets each with its own routing.

Also called: how do I bill extras · separate invoice · add to payment schedule · change order invoicing

See it
New Change Order — Line Items
Line Items+ Add Line
KindDescriptionSupplierQtyUnitUnit PriceTotal
Material12×12 insulated overhead doors (2)Kaufman Door Supply2ea2480.00$4,960.00×
LaborFrame openings, headers, jamb & track installUnassigned18hr68.00$1,224.00×
Credit (subtracts)Delete one 3068 walk door from base scopeUnassigned1ea640.00-$640.00×
Markup %
12
Tax %
6
Subtotal$5,544.00
Markup (12%) + Tax (6%)$1,037.84
Total$6,581.84
Schedule+3 days
Three labelled radio cards with their blurbs, and below them the division rows with per-bucket routing selects. ChangeOrderEditor.tsx. The real screen, drawn from the product’s own design system. Sample data — no customer information appears here.
How it works
  1. 1Choose a delivery mode on the change order; divisions can split the total into titled buckets summing to the change-order total.
  2. 2Each division routes independently: separate invoice, a new scheduled payment, or merged into a target invoice.
  3. 3materializeChangeOrder() turns divisions into real invoices or invoice lines and flips the change order to 'invoiced'; it is idempotent, skipping already-materialised divisions.
  4. 4Fallback rules are explicit: merging into a non-draft target appends a new scheduled payment; any schedule-dependent routing with no project falls back to standalone.
  5. 5A trigger keeps the legacy included_in_total boolean in sync so 'the two can never disagree about whether a change order is in the project total.'
Why we built it

Migration 156 explains why a boolean wasn't enough: '`included_in_total` was carrying that meaning implicitly as a boolean, which cannot express "not decided yet" and gave no room for a third option later.' The blurbs exist because the consequences differ — merging 'Changes amounts the customer has already seen', which is a decision a builder should make knowingly.

The problem
  • One hard-coded billing behaviour for every change order
  • Silently changing payment amounts a customer already accepted
  • No 'not decided yet' state for billing
Sound familiar?
What you get
The billing choice is explicit and explained
The agreed schedule stays untouched unless you choose otherwise
One change order can split into differently-routed buckets

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →