Audit Logs

Purpose

Audit Logs (/audit-logs) helps an ADMIN trace who attempted or completed a change, when it happened, which application route handled it, and what outcome was returned. Audit records support investigation and accountability. They do not prove that the underlying business event was complete, correct, approved, or professionally reviewed.

Supply Weave records audit events for requests that can change data, including POST, PUT, PATCH, and DELETE. Ordinary read-only page views are not audit events.

Important: An Audit Log records application activity. It is not an accounting posting, financial report, inventory movement, source document, approval, or backup.

Open And Filter The List

Open Admin > Audit Logs or go to /audit-logs. The route requires the ADMIN role.

The list shows:

Timestamp: when the event was recorded;
Actor: the identified user, or System when no user is attached;
Entity Type and Entity ID: the kind of record and its identifier when known;
Action: the operation, such as CREATE, UPDATE, POST, CLOSE, or CANCEL;
Status Code: the application’s HTTP result code; and
Outcome: SUCCESS or FAILED.

Use Filter by request ID when a user, support engineer, or error response provides a request ID. The filter expects the complete ID and is the best way to connect one reported attempt with its audit evidence.

The Filters dialog supports:

Filter	Use
Entity Type	Enter the target type, such as `FISCAL_YEAR` or `OPENING_BALANCE_IMPORT`. Camel-case input is normalized, but use the value shown in an existing record where possible.
Action	Enter the exact action, such as `CREATE`, `VALIDATE`, `POST`, `CLOSE`, or `REOPEN`.
Outcome	Show all events, only `SUCCESS`, or only `FAILED`.
Date From / Date To	Limit results by the audit timestamp.
Sort by	Sort by Timestamp, Entity Type, Action, Outcome, or Status Code.
Order	Sort ascending or descending.

The underlying audit service also supports exact actor-user and entity-ID filters. Links from an entity’s Audit History may open Audit Logs with those filters already applied even though the main filter dialog does not provide actor or entity-ID fields.

Results are paginated. Clearing filters returns to the default newest-first list.

SUCCESS And FAILED

Outcome	Meaning	What it does not mean
`SUCCESS`	The request returned a successful status and the recorded operation completed according to the application workflow.	It does not prove the input was correct, authorized under external company policy, supported by source evidence, or approved by a CA.
`FAILED`	The request returned an error. The detail normally includes the status code and application error message.	It does not mean a partial business change occurred. Controlled transactions normally roll back their business changes when they fail.

Common status-code groups are:

2xx: successful request;
4xx: authentication, permission, validation, missing-record, conflict, or workflow rejection; and
5xx: unexpected server failure requiring technical investigation.

Always read Outcome, Status Code, and Error together. A status code alone does not explain the business condition.

Actor Or System

When a signed-in user is identified, Actor shows the user’s name and email. Login events can identify the actor from the successful login response.

System means the audit event has no attached user identity. It can occur when the request was unauthenticated, identity was unavailable, or an internal action supplied no actor. It does not automatically mean the application initiated the business event without human involvement. Use the request ID, path, timestamp, metadata, and related records before reaching a conclusion.

Open The Detail

Select a timestamp or View Details to open /audit-logs/:id. The detail groups the evidence into these areas.

Request Context

Request ID is the correlation key for one application request. Supply it to the system administrator when escalating a failure.
Actor shows the identified user or System.
Timestamp is the audit event time displayed in the user’s browser locale.

The same request ID may be useful in application or infrastructure logs, but those external logs may have different retention and access controls.

Entity Action

Entity Type describes the resource category.
Entity ID identifies the affected record when the route or successful response provided one. A failed create may have no entity ID because no record was created.
Action is derived from the route and operation. For example, a route ending in /close is normally shown as CLOSE.
Outcome records success or failure.

Entity and action labels are routing classifications for investigation. They are not accounting classifications.

HTTP Details

Method shows POST, PUT, PATCH, or DELETE.
Path shows the application API route that handled the request.
Status Code shows the returned result.
Error shows the application error text when captured for a failed request.

Method and path help a system administrator identify the exact workflow endpoint. They do not by themselves show every internal operation performed by that endpoint.

Before, After, And Metadata

Before is a captured summary of the relevant state before a controlled change.
After is a captured summary or successful response state after the change.
Metadata contains supporting context such as sanitized request input, query parameters, request environment details, counts, totals, hashes, reasons, or linked journal IDs where the workflow supplies them.

These fields are optional. No before snapshot captured or No after snapshot captured does not by itself indicate an error. Generic request auditing often has the successful response as After but no Before. Controlled accounting lifecycle events can provide compact purpose-built snapshots and metadata.

Do not treat snapshots as complete copies of database records. They are investigation summaries and may omit fields, related rows, file contents, or information that was not available to the auditing layer.

Transactional Lifecycle Events And Request Failures

Some sensitive accounting actions, including opening-balance lifecycle actions, period close or reopen, and fiscal-year close or reopen, write their successful audit event inside the same database transaction as the controlled change.

In simple terms:

if the controlled change commits, its SUCCESS audit event commits with it;
if that transaction fails, neither the business change nor its in-transaction success event commits; and
the request-level audit layer can still record a separate FAILED attempt after the error response is produced.

This avoids a misleading success record for a transaction that rolled back. A successful controlled lifecycle request suppresses the duplicate generic success event, so one request does not normally produce two success records for the same action.

Other successful mutations are captured at request level after the application returns its response. Audit Logs therefore combine controlled transactional lifecycle evidence with general request-level evidence. Use the action, entity, before/after data, metadata, and related domain records to understand which kind you are viewing.

Redaction And Opening CSV Omission

Audit data is sanitized before storage. Sensitive keys such as passwords, current or new passwords, confirmation passwords, tokens, session tokens, authorization values, cookies, and set-cookie values are replaced with [REDACTED]. Very long strings may be shortened for storage safety.

For OPENING_BALANCE_IMPORT events, complete rows, raw row data, raw CSV, and file contents are deliberately omitted or redacted. Opening-balance Audit Logs retain compact evidence such as:

import ID, date, method, status, and source filename;
row and error counts;
exact debit and credit totals;
validated or posted content hashes;
resulting original or reversal journal references; and
applicable reason or idempotency context.

Retain the original CSV, approved workpaper, mapping, approval, and reconciliation outside the Audit Log. See Opening Balances and the Detailed Opening-Balance Import Guide.

Redaction reduces exposure but is not a reason to enter unnecessary confidential information into free-text reasons, descriptions, or metadata fields.

Immutable Traceability

Audit Logs are append-only application records and have no edit or delete workflow. They preserve the event as recorded, including failures and earlier states. A later correction creates new business, journal, and audit evidence rather than rewriting the original event.

This immutability supports traceability, but it has limits:

it does not prove that no activity occurred outside Supply Weave;
it does not capture ordinary read-only views;
it cannot supply a source document or approval that was never attached or retained;
a missing actor, entity ID, before snapshot, or after snapshot may reflect the request context rather than wrongdoing;
it does not replace database backup, infrastructure logs, access reviews, or legal retention controls; and
it does not certify accounting correctness or audit assurance.

Audit Log Versus Other Records

Record	Main question answered	What it contains
Audit Log	Who attempted or completed an application change, when, through which route, and with what result?	Actor, request ID, method, path, entity/action classification, outcome, status, error, and optional sanitized snapshots or metadata.
Journal Entry	What debit and credit did a posted business or settlement event create?	Accounting source, date, accounts, debit and credit lines, reversal status, and source reference.
General Ledger	Why did one account or account group balance change over a date range?	Canonical system and manual postings, opening and closing balance, running balance, and drill-down references.
Stock Ledger	How did a stock event change on-hand, reserved, on-order, and cost values for a product and size?	Inventory movement type, document, quantity delta, and before/after inventory values.

One operation can produce several records. Dispatching a Delivery Challan can create an Audit Log for the request, Stock Ledger movement for inventory, and Journal Entry for cost of goods sold. General Ledger later presents the journal lines by account. None of these records replaces the Delivery Challan or its delivery evidence.

Investigation Procedure

Record the reported time, user, screen, action, entity number or ID, visible error, and request ID.
Open /audit-logs and search the complete request ID. If it is unavailable, narrow by date, entity type, action, and outcome.
Open the detail and compare Actor, Timestamp, Method, Path, Entity Type, Entity ID, Action, Outcome, Status Code, and Error with the report.
Review Before, After, and Metadata without assuming they are complete source records.
Open the actual business document or configuration record. Confirm its current status, date, party, amount, currency, and workflow history.
For accounting effects, inspect the linked Journal Entry, relevant General Ledger, Trial Balance, and financial report. For inventory effects, inspect the Stock Ledger and inventory item.
Compare application records with independent evidence such as approved documents, bank records, supplier or customer records, stock evidence, workpapers, and authorizations.
If a failed request was retried, locate each attempt. Confirm which attempt, if any, succeeded and whether it used the same entity and approved input.
Correct through the proper workflow. Do not edit an export, create an unsupported journal, or repeat an action blindly to hide the original issue.
Retain the evidence package and escalate unresolved technical or accounting questions to the appropriate owner.

Evidence To Retain

For a material investigation, retain:

audit-log ID and request ID;
timestamp, actor or System, method, path, entity type, entity ID, and action;
outcome, status code, and error;
relevant before/after summaries and metadata, subject to access and privacy policy;
source document IDs, statuses, and external supporting documents;
related journal-entry, General Ledger, Stock Ledger, opening-import, period-close, or fiscal-year-close references;
screenshots or exports showing the reviewed filters and generated times;
explanation of missing or redacted evidence;
correction, reversal, retry, and approval references; and
investigator, reviewer, conclusion, unresolved limitations, and escalation record.

Do not retain passwords, session credentials, raw authorization headers, or other secrets in an investigation package.

Common Limitations And Mistakes

Treating SUCCESS as proof that the transaction was commercially or professionally correct.
Treating FAILED as proof that no later retry succeeded.
Assuming System always means an automatic background process.
Searching only by date when a request ID is available.
Assuming no Before or After snapshot means the event did not occur.
Expecting an opening-balance Audit Log to contain the complete CSV or every row.
Confusing an Audit Log with a Journal Entry or Stock Ledger movement.
Using Audit Logs as the only evidence for a period close, fiscal-year close, opening balance, reversal, or adjustment.
Ignoring external evidence and activities performed outside Supply Weave.
Sharing audit metadata without applying company privacy and access controls.

Return to the Accounting User Guides index.

Reviewed against the application on: 2026-08-21