Version control for audit working papers matters because a file named something like final_v3_ACTUALFINAL.xlsx is direct evidence that the firm has no system tracking which version was actually reviewed, which specific changes were made between versions, and who made them — and in a quality review, a regulatory inspection, or a dispute, the inability to answer those three questions is itself the finding.
Why the naming pattern exists in the first place
The filename ladder — v1, v2, v2_reviewed, v3, v3_final, v3_ACTUALFINAL — is what happens when multiple people need to edit the same working paper and the only available tool is 'save as' plus email. Each person protects their own edits by saving a new copy rather than risking an overwrite, which is a reasonable individual instinct that produces an unreasonable collective outcome: nobody can say, looking only at the final file, what changed since the reviewer last looked at it.
What specifically breaks without real version control
- A reviewer signs off on what they believe is the file they reviewed, but a later edit — intentional or accidental — changes it after sign-off with no record that it happened.
- Two staff editing separate copies converge on a merged file where it's unclear whose number is the current one when the two versions disagree.
- A dispute or inspection months later asks 'what did this figure say at the time of sign-off' and the firm has no reliable way to answer, because the file that currently exists may not be the file that was signed.
- Prior-period comparisons rely on a prior-year file that itself went through an uncontrolled chain of 'final' versions, compounding the uncertainty year over year.
Regulatory requirement
Working papers need to be capable of supporting what was concluded and when, which is the substance behind documentation requirements under SA 230. A file history that cannot show what the file looked like at the point of sign-off weakens that support directly, regardless of how good the final content looks.
What real version control looks like
- 01One file, one location, edited in placeNot emailed copies, not duplicated to a personal drive — a single file or record that every reviewer edits directly, so there is only ever one current version.
- 02An automatic, immutable change historyEvery edit recorded with who made it and when, without relying on anyone remembering to save a dated copy manually.
- 03A locked state at sign-offOnce a reviewer signs off, the file (or that section of it) should be locked against further silent edits — any post-signoff change should itself be a visible, logged event, not an invisible overwrite.
- 04Review comments attached to a specific version, not floating freeA comment referencing 'the number in column F' is meaningless once three more versions have passed. Comments need to be anchored to the version they were made against.
Common practice, not a requirement
A quick audit of the firm's own shared drives for files containing 'v2', 'v3', 'final', or 'copy' in the name is an uncomfortable but useful exercise — it tends to surface exactly how widespread the uncontrolled-version problem actually is before anyone decided to look.
How we think about this
Lekhya keeps one working paper per item with a full, automatic change history and a locked state after sign-off, specifically so the question 'what did this look like when it was signed' always has a direct, checkable answer rather than a filename as a proxy for one.
This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.
Related resources
- Audit documentationReviewing and signing off audit working papersWhat a reviewer is responsible for, a defensible review order, writing points that get cleared properly, and why approval must lapse when the paper changes.
- Audit documentationAudit working papers: what they should containThe anatomy of a paper that stands on its own: objective, population, sample basis, procedure, results, exceptions, conclusion and sign-off, and what each must establish.
- Audit documentationAudit trails: the client's, and your ownThe edit log the Companies Act now requires in the client's software, and the record of what the audit team did to its own file. What each must show, and how to test the first.
Free tools, no signup
Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.
- Purchase register checkDuplicate payments, round-sum amounts, weekend-dated invoices, incomplete records.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.