Ask to see the audit trail before you sign

Ask a vendor whether the system keeps an audit trail and the answer is always yes. It costs nothing to say, and it is almost never tested, because a demo is built to show work being done rather than work being questioned.

This is the question that separates a system of record from a data-entry screen. A data-entry screen holds what is true now. A system of record holds what was true then, and who said so, and when.

Why the question gets skipped#

Demos run forward. Raise an indent, approve it, cut an order, receive the material, pay the bill. Every person in the story does the right thing the first time.

Nothing in a demo shows somebody changing their mind at nine at night, or being asked eleven months later why a rate moved between one Tuesday and the next. That is the day the trail matters, and it is not a day anybody is thinking about while buying. It belongs with the rest of choosing construction software and it is the item most often left off.

The other reason is that buyers ask about features. A trail is not a feature you use; it is evidence you hold. Nobody demonstrates evidence.

The test, in order#

Ask for the keyboard. Then, on the system's main document — a purchase order, a work order, an indent, whatever money eventually follows:

1. Create it. As an ordinary user, with an ordinary user's permissions.
2. Approve it. As the second person, if there is an approval step.
3. Change it. Change something that matters — a rate, a quantity, the vendor.
4. Cancel it. Or reject it, or void it, whatever the word is here.
5. Ask to see the history of that one record. On screen. Logged in as a normal user of that document, not as the vendor's administrator, and not as a query their engineer runs on a laptop turned slightly away from you.

Step five is the entire test. The data almost certainly exists somewhere. The question is whether a person who is not a programmer can reach it in the middle of a disagreement, without anybody's permission.

What to look for on that screen#

• Who. A named person. Not system, not admin, not blank.
• When. A date and a time, and some indication of where the time came from.
• What it was before. "Rate changed" is not a record. The old value and the new one, side by side, is a record.
• From where. Web or phone, office or site, typed or imported. A bulk import that rewrote the whole rate list should not look identical to a storekeeper correcting one line.
• Whether the history itself can be edited. Look for an edit or delete control on the trail. Try to use it.
• What a deletion leaves. Delete the record. Does its history survive, with a line naming who deleted it, or does the whole thing stop existing.
• Whether it covers more than fields. Attachments added and removed, approvals given and withdrawn, comments, status changes.

Two more have to be tried rather than asked. Open a record somebody else created and look for the same screen: some systems show you your own history and nobody else's, which is precisely backwards — your own actions are the ones you already remember.

And get it out. Ask for the trail of one record as a file you keep. If the only way history escapes the software is a screenshot, you own the reading of it and not the record.

The questions about the vendor's own people#

This is the set that gets a longer pause.

What can support see? Most hosted systems let the vendor's staff view customer data, and usually that is how a problem gets fixed. That is reasonable. Not knowing is not.

Can they log in as me? Impersonation is a normal support tool. Ask whether it exists, who may use it, and whether it is announced.

Is their access in the trail I can read, or in a separate log only they can produce?

Can they change data directly? A correction, a data fix, a migration run against your database. Ask what that looks like afterwards.

Press hardest on the last one. A support fix that appears in the history under a storekeeper's name is worse than no history at all: a false record carrying a real person's name, and that person is the one who will be asked to explain it.

How long it is kept, and what happens when it is trimmed#

Trails grow faster than the records they describe, so every system eventually trims, archives or rolls up. Ask how long entries live, what is dropped first, and whether you are told when it happens.

Then check that answer against the life of your disputes. Construction records get questioned at final account, at an assessment, at a handover, sometimes years after the site closed. A short retention period is not wrong, but you should choose it knowingly rather than discover it.

Backups are not an answer to this#

A backup is a copy of everything the system believed at one moment. It answers can the data be recovered after a disaster. It does not answer who changed this, when, and what was it before.

To use a backup as history somebody must restore an old copy somewhere, find the same record and compare by eye. Even then the answer is "it was different last month", not "this person changed it from the site office, and here is the value they replaced". Backups protect data. A trail explains it. Only one of them settles an argument.

The discipline underneath — that a correction adds a line rather than replacing one — is set out in append-only records. The same logic applied to documents rather than fields gives you tamper-evident paperwork.

A trail nobody can read during an argument does not exist#

The dispute you are buying insurance against has a shape. Two accounts of the same event disagree, somebody is being blamed, a payment is held.

In that room a trail is only useful if the person in the argument can produce it in minutes, on their own, from a screen. If producing it needs a support ticket, a vendor's engineer and two working days, then in every dispute that actually happens, you do not have one.

That is also the difference between a trail that protects the organisation and one that protects the person who decided; what an audit trail is for argues the second is why people keep the first honestly.

The short version#

Make a record, approve it, change it, cancel it, then ask to see that one record's history on screen as an ordinary user. Check who, when, the previous value, and whether the trail itself can be edited.

Ask what the vendor's staff can see and do, and whether that sits in the history you can read. Backups are not history. A trail that takes two days and a support ticket to produce is a trail you do not have.