Skip to content

Audit Log Review

Applies to: All subscriptions

Purpose

Turn the audit trail from a stored record into an actual control: reviewed on a schedule, by someone who knows what an unexpected entry looks like.

Audience

Compliance and internal audit, with the system administrator.

Prerequisites

  • Audit visibility, which every role holds
  • A change log to reconcile against
  • Monthly Checks, where this review sits

Reference

The audit trail is not the application log

Audit trail Application log
Purpose Accountability Diagnosis
Audience Auditors, compliance Engineers
Answers Who did what, when Why it failed
Accessed through The application The log platform
Retention 8 years after the financial year; cannot be edited or deleted Operational

Do not substitute one for the other. An auditor will not accept a log file as evidence of who cancelled a document, and an engineer cannot diagnose a failure from an audit trail.

Retention and tamper-evidence

Property What Complifly guarantees
Retention Every audit entry is kept for 8 years after the end of the financial year in which it was written — the same period that applies to invoices, IRNs and e-Way Bills. A registration can extend this; it cannot shorten it.
Append-only Entries are only ever added. There is no path in the application — for any role, administrators included — to edit or delete an audit entry.
Controlled deletion An entry leaves the live system only by moving to a compressed archive, and is deleted only after its 8 years expire, by a scheduled housekeeping job. Each run of that job writes its own audit entry, so the removal of aged entries is itself on the record.
Legal hold A hold — for litigation, a GST appeal or investigation, or an order to preserve — suspends deletion for the entries it covers and overrides the retention expiry until the hold is lifted. Placing and lifting a hold are audited.
Write-once storage Optional, off by default. A registration that must demonstrate undeletability to its own auditors can enable an additional write-once copy of the archived trail. Enabling it narrows the options for a later data-erasure request over the same records.

This is the standard enterprise records-management pattern — retention matched to the business records, immutability enforced by the application, deletion only on expiry and only on the record, with legal hold as an override. It is what lets the trail stand as audit evidence.

What is recorded

Category Examples
Authentication Sign-in, sign-out, failures
User administration Creation, role changes, access changes, disabling
Configuration Feature flags, provider assignment, routing rules, policies
Document actions Registration, cancellation, correction, promotion
Approvals Approve, reject, override
Data operations Uploads (invoice and e-Way Bill document files), exports, deletions, opening a signed e-invoice
Integration Credential issue and revocation, consent-link issue, ingest by machine credential or desktop agent
Privacy administration Notice versions, webhook registration, data-principal records
Support access Each search and each document opened in Support Investigation (SUPPORT_INVESTIGATION_*) — who looked at whose documents
Integration limits Each change or removal of a global, company or connection policy, with the values before and after (API_POLICY_UPDATE, API_POLICY_REMOVE)
Access review Each run of the quarterly access-review export (ACCESS_REVIEW_EXPORTED)
Access governance Segregation of duties relaxed with its reason and who was told (ACCESS_WIDENED); every change to which registrations a person can use, including cross-company grants (GSTIN_ACCESS_CHANGED, GSTIN_ACCESS_GRANTED_AT_CREATE) and refused ones (GSTIN_GRANT_REFUSED). Written to the customer's audit log even when a Complifly Super Admin made the change. Edits and deletions of a person are filed against that person's company from 15 October 2026; before then a Super Admin's edit was filed under the Super Admin's own company
ERP mapping Rule saves, rollbacks, renames, enable / disable, delete and restore — each also kept as a version on the template
TDS TAN profile changes, deductions, challans, return filing, approval, and a refused self-approval
Browser-reported events Always prefixed CLIENT_. An entry without that prefix was written by the server and cannot have been sent from a browser

Machine actions are attributed to the credential that performed them, which is one reason each ERP should hold its own credential: a shared credential makes an action attributable to "the integration" rather than to a system.

What your audit trail does not contain. It records what your organisation's people and systems did. It does not contain Complifly's own internal records about your company: our reviews of your account, follow-up tasks, go-live and company-status decisions, and commercial-record changes. Those are kept by Complifly, are available only to Complifly's Super Admins, and are not shown on your Audit Log screen, on a document's audit view or in the audit count on your dashboard, whatever your role. If an auditor asks for evidence of a change to your agreement or your company's status, Complifly provides it on request; it will not appear in your own export.

Reading what changed

On the Audit Logs tab, use the View changes / View details button on any row (next to the User column) (clicking the row also works). A panel opens with the event's timestamp, user, organization, GSTIN, action, status and IP address, and — for changes — a table of Field Name | Old Value | New Value showing only the fields that differ, for example Max Concurrent Sessions: 1 → 2 or Override Allowed: No → Yes.

What you can expect, by kind of entry:

Entry What the panel shows
User, feature-flag, session-policy, mapping-template, e-Way Bill change, TDS return and approval changes The old → new table
Session-policy changes made before 2026-10-01 The same table for the limit; the "override" setting appears under Additional Details because those entries recorded only its new state
Entries with no before state (sign-in, uploads, most other actions) The recorded details as labelled rows, with the raw record in a collapsed Raw payload section

An entry with no comparison does not mean nothing changed — it means that action does not yet record the previous value. For review purposes, reconcile it against your change log as usual.

The Layout Management button above the table hides, shows and reorders columns, and adds Module, Log ID, Session ID and Browser / Client (a Super Admin also gets Organisation). Presets: Default, Full, Support Investigation, Audit / Reconciliation and Compact. The layout is saved to the user's account, so it follows them to another browser. Timestamp, Action, Status and the View button are always shown.

For an investigation, add Session ID and sort by it: every action taken in one sign-in shares the same value, which reconstructs what one person did in one sitting.

Narrowing to one module

Audit actions carry a module prefix — IRN_, EWB_, CEWB_, MV_, IGM_, GL_, TDS_, PRIVACY_, ERP_, API_ — and the All Modules filter on the Logs tab selects on it. The filter is applied in the query rather than to the rows already returned, so it searches the whole history rather than the most recent page.

Core is the inverse: every action with no module prefix. Logins, user administration and refused access live there, and they disappear the moment you choose any single module. If you are investigating "who changed this user", Core is where it is.

Two modules were added to the audit trail on 2026-08-30 and carry no history before that date:

Module What is now recorded
IGM_ Invoice Generation Customer, item and rate masters; invoice create, update, delete and post; credit and debit notes; approve, reject, request cancellation and approval override; numbering series; receivable write-offs
GL_ General Ledger Accounts and journals; posting rules; period close and reopen; year-end close; opening balances; receipts; provisions and bad-debt events

Before that date these operations happened without an audit entry. Invoice Generation kept its own narrower trails — a document change log, an approval request record and a fiscal-period audit — and those remain, but they are not visible on the Logs tab and never were. Do not read an absence of IGM_ rows before 2026-08-30 as an absence of activity.

What to look for, monthly

Review in this order. It runs from highest to lowest consequence.

# Look for Why it matters
1 Segregation of duties relaxed: search ACCESS_WIDENED; then search accessBasis for what was done under it Changes who can commit transactions. The entry carries the reason and who was told. Every action done only because it was relaxed carries accessBasis: SOD_RELAXED, so you can list them without knowing the date it was switched
2 Cross-tenant access used: search GSTIN_ACCESS_CHANGED and read crossCompany A person given another company's registration. Should be rare and justified every time. An empty crossCompany is the normal case
3 Feature flags changed Some change legal behaviour, such as automatic registration
4 Provider assignment changed Affects where new documents go
5 Role changes Especially anyone gaining transactional authority
6 New administrators Should be deliberate and few
7 Credentials issued or revoked Each should map to a known integration
8 Approval overrides Each should have a business reason
9 Cancellations Each should have a reason; a pattern is worth investigating
10 Deletions and bulk exports Both are worth a second look
11 Authentication failures A spike, or an unusual source
12 Actions by departed staff Should be impossible; if present, the leaver process failed

The quarterly access review

Run it from Admin & Logs > Access > Review, once a quarter, and keep the CSV files. It answers the three questions an access auditor asks, from the system rather than from memory.

Question Where in the export
Who could approve, issue or administer on a given date? People, with the as of date set. Each sensitive permission reads ENFORCED, RELAXED_ONLY or NONE
Did anyone hold a right only because segregation of duties was relaxed? People, the column Held only because SoD is relaxed; and Registrations, which says when and why each registration was relaxed
What changed, and who did it? Changes: every role, approval-role, activation, registration and segregation-of-duties change in the period, with what it replaced, and any registration of another company
What was done under a relaxed rule? Done under a relaxed rule: actions per person and kind

An "as of" date is reconstructed, and the export says how sure it is. It undoes every later change that recorded what it replaced. A person who could not be fully reconstructed is marked Unverified with the reason: a change before 15 October 2026 may have recorded only which fields were edited, and a deletion before that date did not record who the person was. From 15 October 2026 every change records enough. For dates before then, treat an Unverified person as a question to answer from your own records, not as an answer.

The export is itself audited. Each run writes ACCESS_REVIEW_EXPORTED against your company, whoever ran it (an auditor included), because the file lists every person's access.

Reconcile against the change log

The review is only meaningful if there is something to compare against. Every control-relevant change should appear in both the audit trail and a change record. An entry in one and not the other is the finding:

Situation Meaning
In both Expected
In the audit trail, not the change log An undocumented change. Find out who and why
In the change log, not the audit trail It did not happen, or it happened somewhere else

Keep attribution intact

Attribution survives only if accounts do. Disable departed users; never delete them. A deleted account makes their past actions unattributable, and a compliance system must be able to say who registered a particular document years later.

This is the single most damaging avoidable act in audit terms, and it is usually done with good intentions — tidying up the user list.

Validation

Check Pass condition
The review happened Logged, with date and reviewer
Every control-relevant change reconciled Present in both the trail and the change log
Unexpected entries investigated Each has an explanation
Attribution intact No deleted accounts; departed users disabled
Cross-tenant access justified Each use has a reason
Findings have owners Each with a name and a date

Troubleshooting

Symptom Cause Action
A past action cannot be attributed The account was deleted Disable, never delete. Attribution may not be recoverable
A configuration change nobody recognises No change log discipline Establish one. Every control-relevant change gets a record
Segregation relaxed with no record A change from before 15 October 2026 (no reason was required), or one made by a path that does not go through the Operational Controls API Check ACCESS_WIDENED and the control's Audit History. If neither explains it, re-enable, then decide properly with the control owner
Machine actions attributed vaguely One credential shared across ERPs Issue one per ERP
The trail is too noisy to review Reviewing everything rather than control-relevant actions Use the twelve-item list; it is ordered by consequence
Evidence unavailable for an audit period The entry predates the module's addition to the trail (see the 2026-08-30 note), or it is older than the 8-year retention Check the module start dates first; aged entries are retrievable from the archive — raise it with Complifly
The review is skipped when busy It competes with reactive work Schedule it as a fixed monthly appointment