Let the Payment Close the Job

Money reached our records three different ways. Somebody taking a payment inside the app, a customer paying by card from their own page, and the import from the system we used before.
Only the first one closed the job. The other two settled the bill and left the work sitting open.
The shape of the failure
Twenty jobs, just under ten thousand dollars, sitting at the wrong status. One of them was a five figure fraction of that on its own, marked as completed but never closed. Another was still showing as scheduled after it had been paid for.
None of that was visible from anywhere you would normally look. The invoices were settled. The money was in the bank. Every report that counts money was correct. Only the reports that count work were wrong, and nobody cross checks those two against each other unless they have already been burned.
The card path is the dangerous one, and it is the one most shops are adding right now. A customer pays from their own page, the bill settles itself, and the work stays open forever. It is dangerous precisely because it is the path with no employee in it, so there is nobody to notice.
Fix it where it cannot be forgotten
We fixed the payment route. Then we fixed it again, as a rule living with the data itself.
The reasoning is simple and it applies to any shop system that lasts more than a year. The next way money arrives will be written by somebody who has not read the existing file. A new gateway, an integration, a bulk import, a script somebody writes on a Friday. A rule attached to the data catches all of those. A fix inside one route catches exactly one of them.
The rule does not touch a cancelled job and it does not close anything on a part payment. Both of those were proven with a real part payment followed by the balance, because a rule you have only tested one way is a guess wearing a lab coat.
A finished job with no finish date is invisible
The other half of the same problem, and the half that took longer to see.
Our finish date was stamped only when a job was explicitly marked completed. A job going straight from estimate to paid never got one. That is not a rare path. It is every single job settled at the curb, which for a mobile operation is most of them.
So the work was done, the money was in, and it counted toward nothing, because there was no date for it to be counted on. Six hundred and seventy two jobs were in that state.
The symptom is the confusing part. It does not look like missing data. It looks like your dashboard is wrong, and you go looking for a bug in the dashboard.
Stamp the date on every finished state
The fix is to stamp a completion date on all of the ways a job can be finished, not just the tidy one.
For the backlog we filled it in from the best available evidence in order. The date the invoice was issued, then the first payment, then the date the record was created. That is not perfect history and it does not pretend to be. It is close enough to make a month of work countable, which is the job.
Two queries to run on your own system tonight
First, pull every paid invoice and check the status of the job attached to it. Anything open is this exact bug.
Second, pull every finished job and check it has a completion date. That list is usually longer than the first one, and it is the one quietly making your reporting lie to you.
Both take minutes and neither requires changing anything. If both come back empty you have learned something worth knowing for free.
Own a shop or a mobile operation?
Your free MechanicRank listing is one of the citations this article talks about. Claimed listings get an owner badge, a photo gallery, and a green star on the map.
Claim Your Free Listing →