Two billing errors sit at opposite ends of the same broken process, and they behave very differently in the wild.

Bill a client twice for the same visit and you will hear about it, eventually, in a tone you will not enjoy. Fail to bill at all and you will hear nothing, ever. The work was done, the client is content, and the revenue simply never appears. Nobody audits an invoice that was not sent.

Most small providers assume they have the first problem. Almost all of them have the second.

Where the leak comes from

The mechanism is mundane. Work happens in the field and billing happens at a desk, and the bridge between them is a person remembering. Turnovers, call-outs and small material purchases accumulate through a busy season, and at month-end someone assembles an invoice from notes, memory and a photographed receipt folder.

Anything that did not make it into the pile does not get billed. The items most likely to fall out are the small, frequent ones, which in aggregate are the margin.

Make the report the billing event

The structural fix is to stop treating billing as a separate act. If the record of the work is also the thing that generates the charge, then work that was recorded is work that gets billed. There is no second step to forget.

In MapleConcierge, submitting a service report is what creates the invoice. The technician's record of the visit, with its photographs and its itemised extras, is the billing document. A visit that was documented is a visit that was charged.

This inverts the failure mode in a useful direction. Under the old process, forgetting produced silent revenue loss. Under this one, forgetting produces a visibly unbilled report sitting in a list, which is a problem you can see.

And then guard the other end

Making billing automatic raises the double-billing risk, so that has to be closed at the same time and closed properly.

A check in application code is not sufficient. Two people clicking at once, a retried request after a timeout, a background job running twice, and the check passes twice before either write lands.

MapleConcierge enforces it in the database. A service report can hold exactly one invoice reference, and the constraint is a unique index rather than a conditional. A second attempt cannot be written, regardless of timing, process or how the request arrived.

Above that sits a stable reference derived from the report itself, sent with every request. If a call times out and is retried, the billing system recognises the reference and returns the original invoice instead of creating a second one. Retrying is safe by design, which means staff can retry without thinking about it.

Why the vacant week matters

One more property of this model is worth naming. If nothing billable happened, nothing is billed.

A vacant week at a rental property with no turnover produces a report, possibly with photographs from a routine check, and no invoice at all. Providers sometimes resist this, feeling that a visit should generate a charge. Clients notice it immediately and it buys more goodwill than the small amount forgone.

The version of this that damages a relationship is the reverse: a turnover fee appearing in a week the property sat empty. Under a report-driven model that cannot happen, because the charge exists only where the work was recorded.

What to measure

If you want to know whether you have this problem, count the completed jobs in a month against the billable lines on that month's invoices. Most operators who run that comparison for the first time find the gap larger than they expected, and concentrated in exactly the small recurring items they assumed were fine.