The Audit Log Is for the Day Someone Asks You to Prove It
Nobody has ever chosen a piece of software because of its audit log. It is the least interesting line on any feature list, sitting between "bulk upload" and "priority support", and it converts precisely nobody.
Then one Tuesday a client says the quote was never sent, or an insurer asks when you received the claim form, or an accountant wants to know why a supplier invoice was entered twice — and the audit log stops being a feature and becomes the only thing that matters.
This post is about what a trail needs to contain to actually help you on that Tuesday.
What people reach for instead, and why it fails
When there is no log, everyone reconstructs. The usual materials:
Email. The single most common substitute, and the weakest. Email proves you sent an attachment to an address. It does not prove which version, what happened to it afterwards, or that the file on your disk today is the file you attached in March. Threads get pruned, forwarded, and re-sent with edits.
File timestamps. A file's modified date changes when anything touches it, including a backup restore, a sync client, or opening it in the wrong application. It is not a record of events, it is the residue of the last one.
Memory. You will be extremely confident and occasionally wrong, and the other party will be extremely confident in the other direction. This is how ordinary disagreements become expensive ones.
None of these are records. They are traces, and traces are what you assemble when you did not keep a record.
What a usable trail actually contains
A log that helps under pressure answers four questions about every event, and it does so in a form you can hand to somebody:
- Who. Which account performed the action. Not "the office" — an identity.
- What. Which specific document, by a stable identifier that survives a rename.
- When. A timestamp written at the moment of the action, not derived afterwards.
- What kind of action. Uploaded, viewed, extracted, exported, sent, deleted. A viewed event and a deleted event are different facts and cannot share a row.
Two properties matter as much as the contents:
- It is append-only in practice. A record you can quietly edit is a record the other side can argue you quietly edited. The value of a log is that it was written before you knew you would need it.
- It leaves. A trail you can only look at inside a dashboard is useless in a dispute. It has to export, because the person who needs to read it does not have your login and will not be getting one.
On the Business plan, the audit log records those four fields per action across your documents and exports when asked. That is the whole feature. It is not glamorous and it is not meant to be.
The three situations it earns its keep
The dispute. A customer says they never received the invoice, or received a different one. A trail that shows the document created on the 4th, sent on the 4th, and opened on the 6th converts an argument into a fact. It does not make you right — it makes the timeline not up for debate, which is usually enough for the conversation to end.
The claim. Insurance and warranty processes run on chain of custody. When did you take receipt of the paperwork? Who handled it? Was it altered between receipt and submission? Adjusters ask these questions as a matter of routine, and "I'm fairly sure it was the Monday" is not an answer that closes a file.
The audit. Not necessarily a tax audit. Any time a third party reviews your books — a lender, an acquirer, a franchise, a grant body — the question behind every question is "can this business account for its own paperwork". A business that can produce a document history in ten minutes is a different risk profile from one that produces a shoebox.
Retention is a decision, not a default
There is a real tension here, and it is worth stating rather than glossing over.
A log is a record of activity. Records of activity are useful evidence and they are personal data when they involve identifiable people. Keeping everything forever is not automatically the safe choice — under most privacy regimes, holding data longer than you have a reason to is its own exposure.
So the sensible position is a deliberate one:
- Decide how long you actually need the trail. Most small businesses land on the same period as their tax record-keeping obligation, because that is when the questions arrive.
- Know what the log contains about other people, and be able to say so if asked.
- Do not treat "we log everything indefinitely" as a security posture. It is a storage decision that someone should have made on purpose.
If you are working through what a document tool should and should not keep about you, our privacy and security checklist covers the questions worth asking of any vendor, including us.
The thing you cannot do retroactively
Here is the uncomfortable property of audit trails: they are the one feature you cannot start using after you need it.
Encryption you can turn on late. A backup you can start today and be glad of next year. A trail is different — its entire value is that it covers the period being questioned, and that period is always in the past. On the day someone asks you to prove it, the log either already covers March or it does not, and there is nothing you can do in that moment to change which.
That is the argument for having one running quietly on a plan you already pay for, on documents you are already scanning, doing nothing at all, for years.
Until the Tuesday.
