Backfilling work you already did

A backfilled visit is a real completion recorded after the fact, on its true date. It bills at the price you originally agreed — which can differ from the forward price on the service line — and you choose whether it creates a contractor payment at all. Because it is a genuine completion, the client's billing cadence responds to it exactly as it would to work done today.

A backfilled visit is not a note-to-self that work happened. It is a real completion, recorded on its real date — which means everything downstream treats it the way it treats work finished this morning. It flows into the client's billing cadence, it lands in the job history, and it can draft an invoice.

That is the whole point. Migrating a business means the work you did last month has to become billable in the new system without pretending it happened today.

Which price does a backfilled visit use?

Its own. A backfill carries a legacy rate that is set on the visit itself, separate from the forward rate on the recurring service line. The two coexist deliberately:

  • the backfilled visit bills at what you charged when you actually did the work;
  • the service line carries the price that applies from now on.

This is what makes a price rise painless mid-migration. Agree a new rate with the client, set it on the line, and still bill June's outstanding visit at June's price. Both numbers are true at once, and neither overwrites the other.

Who gets paid for a backfilled visit?

You choose, per backfill, and the choice matters:

  • A normal pending payment — the contractor did the work and hasn't been paid yet.
  • Already settled outside the system — the contractor did it and you paid them before migrating. The payment is recorded and closed, so it can't be paid twice.
  • No contractor payment at allyou did the work, before you engaged anyone. This is the common case when a business migrates its own historic book, and getting it wrong invents a debt to a contractor who was never involved.

What happens to the invoice?

Nothing special — which is the design. The completion event fires and the client's cadence decides, exactly as described in when completing a job bills the client. A per-job client gets an invoice per backfilled visit. A consolidating client accrues them into one invoice for the period.

One consequence worth planning for: back-dating a visit back-dates the invoice date too, so a freshly-drafted catch-up invoice can be born already overdue against the client's terms. Set the due date explicitly to something sensible from today before you send it.

Verify the artifact, not the success message

The most valuable habit in any backfill: re-read the invoice afterwards and count the lines.

Composite operations report on what they attempted. When several service lines are settled into a single consolidated period — two sites, or two services at one site — it is possible for the visits to be created correctly while a line fails to reach the invoice, and for the summary to still read as success. The failure is silent precisely because the part that failed is not the part being reported on.

The general principle applies well beyond backfilling: when an operation's success flag and the artifact it produced are two different things, check the artifact. A missing line found now is a thirty-second fix; found by a client three weeks later, it is a credit note and an awkward conversation. The same reasoning underpins one write path, many callers — trust the path that actually emits the event, and confirm what it produced.

Related

Last updated 2026-08-05