Turn an approved change order into invoices

One action creates the real invoices and invoice lines each division needs, falls back safely when a target is no longer billable, and never double-bills.

What it is

The materialiser walks the change order's divisions and, per routing, appends a line to a draft invoice, appends a new scheduled payment to the project's plan, or creates a standalone invoice. It is idempotent, refuses to run on an already-invoiced change order, and only flips the change order to 'invoiced' when every division succeeded.

Also called: bill the change order · generate the invoice from the extra · change order to invoice

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
The result panel after materialising: each division listed with its requested routing, its effective routing, and a 'fell back to new scheduled payment' note on one. src/components/changeOrders/ChangeOrderEditor.tsx. The real screen, drawn from the product’s own design system. Sample data — no customer information appears here.
How it works
  1. 1Divisions already materialised or paid are skipped and reported as-is.
  2. 2Merge is only allowed into a draft target; a sent or paid target falls back to appending a new scheduled payment, and a missing target falls back to a standalone invoice.
  3. 3Schedule-dependent routings with no project fall back to standalone.
  4. 4A new scheduled payment takes the next stage index and bumps every sibling's stage count, so the plan reads 'Payment 4 of 4'.
  5. 5A division is only stamped done when its invoice or line was actually created — a transient failure leaves it pending so it can be retried.
Why we built it

A draw that has been sent already has its payment amount fixed and may already sit in the builder's accounting package, so it cannot quietly grow by the value of a change order. A merge only ever lands on a draw that has not gone out, falling back to the next available one when the intended target has already been sent. If one bucket fails to land it stays pending and retryable rather than being marked done, because silently dropping a bucket means the customer is never billed for work that was carried out.

The problem
  • Re-running billing creating a second set of invoices.
  • Adding a line to an invoice that has already been sent or pushed to accounting.
  • A failed bucket silently disappearing and underbilling the customer.
Sound familiar?
What you get
Billing a change order is one action with a predictable result.
A partial failure is retryable without duplicating what already worked.
The customer's already-sent invoices are never altered underneath them.

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 →