Wrong period, wrong entity: the document errors that create audit risk

The item on your list says “bank confirmation, FY2025.” A file arrives, it is a bank confirmation, and you tick the box. Three months later, during review, someone notices the letter is dated for the prior year. It was the FY2024 confirmation, sent again by a client who grabbed the wrong PDF from their own folder. Nobody was chasing it any more, because as far as the tracker was concerned, it had been received.

The document was present. It was just wrong. And the errors that are present but wrong are far more dangerous than the ones that are simply missing.

Missing is loud, wrong is quiet

A missing document announces itself. It sits on the list as outstanding, the reminders go out, someone follows up. The process is built to close gaps, and a gap is visible.

A wrong document does the opposite. It satisfies the surface test — a file exists, it is roughly the right kind of thing — so it slips into the engagement record looking complete. There is no alarm, because nothing is missing. The failure only surfaces later, if it surfaces at all, when a reviewer happens to read the date or check the name at the top of the page.

The common failure modes are worth naming, because they recur across every firm:

• Wrong period. The FY2024 statement filed against the FY2025 ask. The Q1 VAT listing sent again for Q2. Numbers that look plausible until you check the header.
• Wrong entity. The parent company’s bank letter uploaded under the subsidiary. A director’s personal proof of address standing in for the company’s. Right group, wrong legal person.
• Duplicate. The same file sent twice against two different items, or re-sent after a correction was already provided, so you are now holding two versions and relying on the wrong one.
• Incomplete. Page one of a three-page agreement. A statement with the reconciling section cut off. Present, but not the whole thing.

Each of these is a small human slip on the client’s side. None of them is caught by asking “did we receive something.”

Why email and folders make it easy to miss

The reason these errors survive is structural. When documents arrive as email attachments or land in a shared folder, nobody is checking the date and entity on every single file at the moment it comes in. The person receiving it is often not the person who will eventually rely on it. The file gets saved, the item gets marked done, and the check that would have caught the error is deferred to a review that may be weeks away and rushed.

A folder makes this worse, not better, because a folder only tells you a file exists. It has no memory of what you asked for. It cannot compare the document in front of it against the period and the entity the ask belonged to, because it does not know there was an ask. The context that would flag “this is the wrong year” lives in someone’s head, or in a spreadsheet cell, not next to the file.

So the wrong document and the right document look identical in the folder. They are the same size, the same format, sitting in the same place. The only thing that distinguishes them is content nobody has read yet.

Naming the exact ask

The first defence is structural, and it is quiet. In Clivanta every ask is a Request Item that names exactly what it wants — the specific document, for a specific Period, under a specific Engagement for a named Client. “Bank confirmation, FY2025 Audit” is not a folder into which any bank confirmation fits. It is a slot with a period and an entity attached to it.

That context matters because it gives every incoming file something to be measured against. The ask knows which year it belongs to and which legal person it concerns. The file, on its own, does not. Putting the two next to each other is what makes an error checkable at all.

Reading the date and the entity, before you rely on it

On top of that context, Clivanta runs AI pre-checks when a client uploads. Asynchronously, in the background, they classify the document type, extract the document’s own date and the entity name it carries, detect duplicates by file hash, and compare what they find against the Period and Engagement the Request Item belongs to. When the extracted year does not match the period, or the entity on the page is not the one the item is for, the item is flagged as a likely wrong period or wrong entity.

The flag is the whole point, and so is its limit. The pre-check does not accept the file, reject it, move it, or conclude anything. It raises a concern for a person to look at. A Firm User still reads the document and makes the decision, exactly as they would have — but now with the suspicious cases surfaced instead of buried. When a check cannot run, it says so plainly rather than blocking review. This advisory-only design is deliberate, and we explain the reasoning in how Clivanta’s AI pre-checks documents without ever auto-deciding. Judgement stays with your team; the machine just makes sure the header gets read.

Why this is a workpaper-integrity question

It is tempting to treat wrong-period and wrong-entity slips as minor administrative noise. They are not. The integrity of a workpaper file rests on the documents in it actually being what they claim to be. A prior-year confirmation relied on as current, or a parent’s evidence standing in for a subsidiary, is a defect in the evidence itself, not a formatting problem. It is precisely the kind of thing an inspection or a second reviewer is meant to find — and much better found at upload than after sign-off.

Structured collection does not remove the need for professional scepticism, and it is not a substitute for reading the file. What it does is move the first check to the earliest possible moment, attach it to the specific ask, and make sure the person accepting a Document as Evidence is doing so with the obvious discrepancies already on the table. For audit and tax work, where the same period and entity confusions recur every cycle, that shift is where a lot of quiet risk is taken off the file.

The request-and-response loop cannot read a document for you. It can make very sure you looked before you relied on it.

A file that exists is not the same as a file that is right.