Audit trails your accountant actually likes: job costs, changes, and who approved what

Month-end should not mean stitching CSVs from dispatch, inventory, and billing. The reason it usually does is that each system holds a fragment of the job’s truth in an incompatible schema, and the ‘report’ is a human join across those fragments performed under deadline. Accountants want a coherent story—job ID, costs, changes, approvals, invoice state—and they want to trust that it reconciles.

The architectural root cause is that most stacks store current state and throw away history. You can see that an invoice is $6,840 but not the sequence of events that produced it. An audit trail is not a feature you bolt on at close; it is a consequence of storing the events instead of only the latest snapshot.

Traceability is cheap if the system is event-sourced and expensive if it is not. When every state change—an estimate, a change order, a parts pull, an approval, an invoice send—is an immutable, ordered event, the audit trail is simply the log itself. You never ‘generate’ it; you query it. Current state (the invoice total, the margin) becomes a fold over that history, so state and audit trail can never disagree because one is derived from the other.

Private deployment adds the property that matters for trust: the log lives inside your boundary, append-only, with each entry recording actor, action, inputs, resulting diff, and—critically for AI actions—which policy version and model version produced it. That is table stakes for serious operators, not an enterprise upsell, and it is the difference between ‘we think a human approved that’ and ‘user X approved it at 4:12 p.m. under policy v7.’

Labor estimated vs. actual, parts used, change orders, and invoice status belong on one timeline because they are all events on the same aggregate: the job. Reconstructing ‘why did margin move on this job’ becomes a temporal query over that timeline rather than a forensic exercise across systems. You can literally replay the job to any point in time and see what the numbers were then—useful when a customer disputes a total or an auditor asks about a specific date.

Because current values are projections, adding a new report is adding a new projection over existing events—not a migration and a backfill. When someone asks why margin dropped, you answer in minutes by reading the ordered causes, not by exporting and diffing snapshots.

An audit trail is only as good as its integrity guarantees. For a log to stand up to review it needs tamper-evidence (append-only storage, ideally with hash-chained entries so a silent edit is detectable), defined retention aligned to your tax and legal obligations, and access controls so the log records reads and writes without letting the wrong role rewrite history.

These are the same controls you would expect on any regulated system of record, and keeping them inside a private deployment means the audit data itself is not shipped to a third party where you can no longer vouch for it. The log is evidence; treat its storage and access like evidence.

If capture happens continuously—approvals, notes, and attachments recorded as events during the month—then close is a read, not a reconstruction. The heroic weekend of figuring out who signed off on what disappears because the system never lost that information in the first place.

This is the practical payoff of the event-sourced approach for a trade business: the accountant gets a coherent, queryable story per job; the owner can answer margin questions on the spot; and nobody spends a Sunday stitching CSVs to reverse-engineer decisions the system should have recorded as they happened.