Skip to content

Document Management | Document Versioning

Replace a document. The old version stays. The auditor can still find both.

Every upload, edit, replacement and delete is captured with user, timestamp, IP and reason. Old versions stay alongside the current one. The audit trail is hash-chained for Rule 11(g). Auditors and the courts see the chain of custody, not just the latest file.

Document Versioning screenshot

How it works

From upload to versioned, audited archive.

Step 01

Every upload captured

User, timestamp, IP, file hash and reason are stored with each upload. The current version surfaces by default; prior versions remain accessible.

Step 02

Edits and replacements tracked

Replacing a document creates a new version. The prior version moves to history with the replacement reason. Both versions remain accessible to the auditor.

Step 03

Delete requires reason

Soft delete requires a reason and an authoriser. The deleted document remains in the audit trail; only the active surface hides it. Hard delete is locked except for explicit data-retention or DPDP erasure cases.

Step 04

Hash chain links every event

Every upload, edit, replacement and delete chains into the audit log. The chain root is signed; tampering with the history is detectable.

What the system does

Capability, input, output.

  • Upload capture

    Input
    File + user + IP
    Output
    Versioned archive entry
  • Replacement flow

    Input
    Replacement file + reason
    Output
    New version, prior moved to history
  • Soft delete

    Input
    Reason + authoriser
    Output
    Hidden from active surface; in audit log
  • Hash chain

    Input
    Every event
    Output
    Chain root with signature
  • Auditor view

    Input
    Read-only role
    Output
    Full version history visible

Compliance + integrations

A version history the auditor can rely on.

Rule 11(g) of the Companies Act requires an audit trail of every change. Document versioning extends that requirement from the ledger to the underlying source documents. The chain of custody is end-to-end.

Regulations we work within

  • Rule 11(g), Companies Act

    Audit trail across document changes.

  • Section 128, Companies Act

    8-year retention applies to versioned archive.

  • IT Act 2000, Section 65B

    Electronic records admissibility supported.

Connects to

  • Auditor read-only access Full version history
  • DPDP-aligned erasure Right-to-erasure execution

Document Versioning FAQ

What buyers ask.

If a vendor sends a corrected invoice that replaces the original, can the auditor see both?

Yes. The replacement creates a new version, with the original preserved in history. The auditor sees both the original (with its capture date) and the corrected version (with its replacement date and reason). The bill record links to the version active at the time of posting.

How is GDPR or DPDP right-to-erasure handled when a document must actually be deleted?

DPDP and GDPR right-to-erasure trigger a hard-delete workflow with the controller's authorisation, the reason and the legal basis recorded. The audit trail captures the erasure event itself; the document content is removed but the metadata of the erasure event is retained for regulatory accountability.

Can the auditor verify that no file has been tampered with post-upload?

Yes. Each file's hash is captured at upload and chained into the audit log. The auditor verifies any file by re-computing its hash and comparing against the chain. Any tampering breaks the chain.

Upload a document. Replace it. See both.

Free trial. Upload a vendor invoice. Replace with a corrected version. The audit trail surfaces both with timestamps, users and the replacement reason.