Reconciliation and reporting · Live · since August 2026
The profit ledger.
A load counts as profit only if the hand-off email exists and the TMS shows a carrier. The agreed rate is read from the thread, because the database field lies.
The problem
What did the desk actually make this morning? The honest answer needed the email thread, the TMS and the bot's records to agree, and the quick answer from the database was wrong often enough to matter.
How it works
- Two gates before a load counts: the internal hand-off email exists, and the TMS shows the load advanced with a carrier attached. Either missing means no deal yet.
- The agreed rate is read from the email thread, not the bot's record, because a carrier can accept a different number than the one the bot last offered.
- Every run records to a persistent ledger, so booked-versus-settled drift is visible: an unpriced load lands in settled but not booked, and a load unbooked later shows as a hole, not a mystery.
- Attribution per line: the operator, the bot, or a colleague, so a bonus question has one answer.
// a load is never counted on the database's word alone; the email and the TMS must both agree
The result
A morning and a lunch report the desk trusts, and a 30-day history: 141 loads verified through both gates in the first window.
Related systems
Your version of this exists.
Different industry, same shape: a repetitive workflow, a fragile spreadsheet, an inbox someone babysits. Tell me what the manual work looks like and I can usually name the first build in one conversation.