# When completing a job bills the client

> Finishing a job can mean four different billing outcomes, chosen per client: draft an invoice for each job as it completes, accrue and consolidate a period into one invoice, hold until the period's last scheduled job completes and bill then, or never auto-bill. The completion event carries the decision; the cadence setting decides what happens.

URL: https://biloh.com.au/docs/concepts/when-completing-a-job-bills-the-client
Category: Explanation | Audience: operator | Updated: 2026-06-26

Completing a job doesn't have one billing meaning — it has four, and which one applies is **set per client**. The same recurring service can bill one client per visit and another once a month, because the cadence lives on the client, not the service. Here are the four outcomes a completion can produce.

## The four cadences

- **Per job, on completion.** Each completed job immediately drafts its own invoice. Best for one-off or ad-hoc work where the client expects to be billed as things are done.
- **Period, consolidated.** Completed jobs accrue across a period (say a month) and are drafted as a single invoice for that period — one line per visit. Best for clients who want one tidy bill, not a stream of them.
- **Last job of the period triggers it.** The invoice drafts automatically when the *final scheduled job of the period* is completed. The schedule itself is the trigger: when the work for the month is finished, the bill exists. This is the powerful one for monthly contracts — there is no separate "run month-end billing" step to forget, because finishing the work *is* the month-end step.
- **Manual.** Completion never auto-bills. The operator raises invoices by hand. Best where billing is negotiated, milestone-based, or handled outside the normal flow.

> The most under-appreciated option is the third: let the act of finishing the last visit be the thing that bills the month. The event you already emit becomes the trigger you'd otherwise have to schedule.

## How the decision is actually made

Completion emits an event — the canonical signal that a job is done. A cadence-aware handler reads the client's setting and decides: draft now, accrue for later, hold until the period's last job, or do nothing. Nothing about the *completion* changes between clients; only the handler's response to the event differs.

That design is why getting the write path right matters so much. If a job is completed through a path that doesn't emit the event — see [one write path, many callers](/docs/engineering-notes/one-write-path-many-callers) — none of these cadences fire, and the most visible symptom is a completed job that never bills. And if the handler is implemented but never subscribed, you get the same silence for a different reason: [a handler nothing subscribes to does nothing](/docs/engineering-notes/wiring-an-event-to-its-handler).

## Why per-client, not per-platform

Billing preference is a relationship fact, not a software fact. A property manager with twenty sites wants one consolidated monthly invoice; a one-off storm-damage cleanup wants billing the day it's done. Forcing both into a single platform-wide cadence would mean working around the tool for half your clients. Making cadence a per-client setting keeps the software out of the way of the commercial relationship. The schedule that produces these jobs is described in [scheduling jobs by the day](/docs/concepts/scheduling-jobs-by-the-day).

## Related

- [One write path, many callers](/docs/engineering-notes/one-write-path-many-callers)
- [A handler nothing subscribes to does nothing](/docs/engineering-notes/wiring-an-event-to-its-handler)
- [Scheduling jobs by the day, not the minute](/docs/concepts/scheduling-jobs-by-the-day)