Why does my ServiceTitan revenue number change depending on which date field I use?
Because a job carries several dates that rarely land on the same day: the date it was created, the date it was completed, the date the invoice was posted, and the date payment was received. Revenue reported by completion date, invoice date and payment date will disagree, especially near month end. Pick one date as your reporting spine, state it on the report, and never mix them in the same chart.
One job, four defensible dates
A single job produces a small cluster of timestamps. It was created when the call came in. It was scheduled for a day. A technician completed it. Somebody posted the invoice, sometimes hours later, sometimes after a manager review. Then payment landed, possibly weeks later on a financed or invoiced account.
Every one of those dates is a legitimate answer to "when did this revenue happen." They are just answers to different questions. Completion date answers "when did we do the work." Invoice date answers "when did we book it." Payment date answers "when did we get paid." Operations, accounting and marketing each instinctively reach for a different one.
Where the disagreement gets loud
The gap is invisible in an annual total and brutal at a period boundary. Work completed on the last two days of the month that gets invoiced on the first of the next month moves between periods depending on which field you chose. Multiply that by every technician and the month-end swing is large enough to start an argument.
- Marketing reports usually want completion or invoice date. The question is whether the demand you bought turned into work.
- Accounting wants whatever ties to the general ledger. Usually the posted invoice date, because that is what reconciles.
- Operations wants completion date. That is the day capacity was consumed.
- Commission and bonus calculations often use a fourth rule entirely, which is why payroll disputes are frequently date disputes in disguise.
The diagnostic that settles it
Pull the same period twice, once keyed on completion date and once on invoice date, and compare the totals. A small gap is normal and reflects invoicing lag. A large, persistent gap means invoices sit unposted for days, which is an operational finding, not a reporting quirk. Track the median lag between completion and posting as its own metric; it is one of the cleanest early indicators that back-office throughput is slipping.
When we build reporting on top of a field service system we store all of the dates and let the report declare which one it used. That is standard practice in our ServiceTitan integration work, and it is the reason two dashboards built by the same team still agree with each other.
A rule that prevents most of the pain
Choose completion date as the default spine for operational and marketing reporting, invoice date for anything that has to tie to accounting, and label the axis on the chart with the field you used. Then, when someone says the numbers do not match, the first question has an answer instead of starting a hunt.
Reconciling definitions before reporting them is the unglamorous half of data integration, and it is what makes a number survive being challenged in a meeting.
Topics: reporting · revenue · dates · reconciliation
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.