Document vs. Evidence: the distinction that matters for audit

A junior downloads a bank statement a client has just uploaded, glances at it, and drops it into the audit folder. Six months later, during file review, a partner asks a plain question: did we actually accept that statement as evidence, or was it just sitting there? In the folder, there is no way to tell. The file that was reviewed and relied upon and the file that nobody ever looked at are the same size, the same colour, the same icon.

That is the whole problem in one scene. Most collection tools treat every uploaded file as if it carries the same weight. Audit work turns on the opposite idea: some files you have accepted and stand behind, and most you have not yet.

Two different things wearing the same clothes

Clivanta keeps them separate on purpose, with two words it uses precisely.

• A Document is a raw file a Client has uploaded against a Request Item. It exists. That is all you know about it. It has not been reviewed, it has not been checked for the right period or the right entity, and nobody at the Firm has put their name to it.
• Evidence is a Document the Firm has accepted against that Request Item. It is a permanent part of the Engagement record, and it carries the reviewer’s identity and the timestamp of the decision.

The distinction sounds academic until you try to defend a file. When an audit is questioned, the reviewer does not want to know which files a client sent. They want to know which files you accepted and worked from. In a shared drive, that information does not exist anywhere. In Clivanta, it is the difference between a Document and Evidence, and it is stored, not remembered.

One item, several Documents

A Request Item is not a slot for a single file. It is one specific ask, and a Client may answer it more than once.

Say you have asked for the year-end bank confirmation. The Client uploads a scan. You look at it, notice it is unsigned, and set the item to needs revision. The Client uploads a signed version. Now the item holds two Documents. The signed one is the current submission; the unsigned one is a previous attempt.

Clivanta keeps both. Superseded and rejected files are retained as previous attempts, never deleted. This matters more than it first appears. If you can only ever see the latest file, you cannot show what you were working from earlier, and you cannot explain why you asked for a correction. The version history is part of the record, not clutter to be tidied away.

So at any moment a Request Item has a clear shape: a current submission, an ordered history of previous attempts, and a status that tells you where the whole thing stands. None of that is derived from what happens to be in a folder. It is the stored, audited state of the item.

Acceptance is the moment that changes everything

Nothing becomes Evidence by drifting into a folder. It becomes Evidence when a Firm User decides it does.

When you accept a Request Item, Clivanta promotes the accepted Document to Evidence on the Engagement record. That act is a decision with a name and a time attached. It is written to the item’s immutable activity log alongside every other meaningful step: the request going out, the submission arriving, the revision you asked for, the acceptance itself.

This is deliberate, and it is where Clivanta draws a hard line around its AI. The pre-checks can classify a document type, read its date and the entity name, flag a likely wrong period, and warn you about a duplicate. What they never do is accept anything. AI never accepts, rejects, moves, or concludes automatically. A Document becomes Evidence only because a person at your Firm looked at it and said so. For audit, the value of the acceptance is precisely that a human made it, on the record.

The reverse case is just as important. A Document that is never accepted never becomes Evidence, no matter how long it sits there. There is no ambiguous middle state where a file is sort of part of the record. It is one or the other, and the system knows which.

Why the audit file is stronger for it

Once acceptance is a real, logged event rather than a filing habit, the workpaper file describes itself.

You can pull an Evidence index export for an Engagement: a clean list of exactly the Documents you accepted, each tied to the Request Item it answers, with the reviewer and the timestamp. Not everything the Client ever uploaded. Not the abandoned first drafts. The Evidence, and only the Evidence. Alongside it you can export a ZIP of the accepted files and a CSV of the metadata, so the file you hand to a reviewer matches the record inside the system.

Compare that with reconstructing the same story from a drive. You would be opening files one by one, guessing at versions, and hoping the naming told the truth. The folder can confirm a file exists. It cannot tell you the one thing collection actually turns on, which is what you accepted and relied upon.

That is the quiet strength of keeping Documents and Evidence apart. Every Document is a claim the Client is making. Every piece of Evidence is a decision your Firm has made and can stand behind. A defensible audit trail is built from the second kind, and you cannot get there if the two look identical.

For firms doing statutory work, this is not a nicety. It is the shape of the file. If you run audit and tax engagements, the acceptance step is where your judgement is recorded, and Clivanta is built so that step leaves a mark.

A folder full of files is not an audit record. The record is the subset you chose to stand behind.