What an audit trail is
An audit trail is the chronological record of who created, changed, approved, posted, reversed or deleted each accounting record, when they did it, and what the values were before and after. It matters because financial statements are only as reliable as the ability to show how each number got there, and because the audit trail is the first place auditors and investigators look for errors and management override.
An audit trail has two halves that are easy to confuse. The document trail links each ledger balance back through journals to invoices, receipts and contracts. The change trail records every modification to those records. A system can have a perfect document trail and still allow a user to edit an invoice after the fact without anyone knowing; the change trail is what closes that gap. This guide covers both, and shows how Skyline Nexus ERP records them in two complementary logs.
What a good audit trail must capture
Auditing standards do not prescribe a log format, but they shape what a useful one contains. ISA 240 requires auditors to test the appropriateness of journal entries and other adjustments because management override of controls is a risk in every entity, and that testing depends on knowing who posted what and when. ISA 230 expects audit documentation to identify who performed work and when, and ISA 500 asks auditors to consider the reliability of information produced by the entity, which includes whether it could have been altered. In the European Union, Article 233 of the VAT Directive requires the authenticity of origin, integrity of content and legibility of invoices to be ensured from issue to the end of the storage period.
In practice, a change log that supports those tests records seven things for every event. If any is missing, an investigation stalls at exactly the point where it matters.
- Who: the user account, not just a role or a shared login
- What: the record type and reference, such as journal JV-0412 or invoice INV-1045
- Action: created, updated, approved, posted, reversed, deleted, restored
- When: a system timestamp that the user cannot set
- Before and after: old values and new values for each changed field
- Where from: IP address and browser, to separate office work from remote access
- Why: a reason, required for reversals, rejections and deletions
Two logs in Skyline Nexus ERP
Skyline Nexus ERP keeps two logs, one for the ledger and one for the rest of the system. The Accounting Audit Trail, under Fiscal Authority, Reports, Audit Trail, described as Track all changes and modifications, records accounting events: created, updated, deleted, restored, submitted, approved, rejected, posted, reversed and cancelled, each with the user, the entity, old and new values, IP address and browser. Fiscal period status changes are logged there too.
The Activity Log, under Reports, Activity Log, is the system audit trail for operational records. It logs records added, edited and deleted, payments added, edited and deleted, status changes, imports, logins and logouts, notifications sent and GOSI events. Reading both gives the complete picture: the Activity Log shows that an invoice was edited, and the Audit Trail shows what that edit did to the ledger.
Reading the Accounting Audit Trail
The Audit Trail report filters by Date Range, User and Action, with the actions Created, Updated, Deleted, Approved, Posted and Reversed, and lists the Timestamp, Entity, Description and Details. Opening the details shows Old Values and New Values side by side, so a change to a journal's amount, date or account is visible field by field.
Two filters answer most review questions. Filtering by Action Reversed shows every correction, which should each have a reason and a matching new entry. Filtering by a single User over the close period shows what one person did while the books were being finalised. Because journals move through submitted, approved and posted, the Audit Trail also shows who approved each entry, which is the evidence needed for approval testing.
Reading the Activity Log
The Activity Log opens with a summary: users online now, activity counts for today, this week and this month, the Most Active User and Deletions Today. The filters are By (user), Subject Type, Action and Date Range, and each row shows a Risk level, the Reference, the IP address and the Browser. The detail view lists the changes field by field with Old Value and New Value.
Deletions Today is the number to watch. A retail business with a few dozen daily deletions of draft sales may be normal; one deleted final invoice is not. The Risk column and the Subject Type filter let a reviewer go straight to deletions of sales, purchases and payments, and the login entries show whether a change was made from an unusual location or outside working hours.
Why reversal beats deletion
Deleting a posted transaction erases evidence; reversing it adds evidence. A reversal leaves the original entry, a mirror-image entry and the reason in the ledger, so anyone can see that something was recorded, then corrected, and why. Deletion leaves a gap in the numbering and forces the reviewer to trust that the deleted item was a genuine mistake. That is why accounting systems built for audit restrict deletion to drafts.
Skyline Nexus ERP applies this rule in layers. Only draft journals can be deleted; a posted journal is reversed with Reverse Journal Entry, giving a Reversal Date and reason, or replaced with Correct Journal Entry. Deleting a sale is a soft delete: the linked sales journal and each payment's journal are reversed first, so the deletion goes through only while the period is open. Deleted sales go to the Recycle Bin, where they can be restored or permanently deleted, and the deletion is written to the Activity Log. Invoices reported to or cleared by ZATCA stay in place and are corrected by credit or debit note, and a sale that already has a return stays in place and is changed by editing the return. Documents are open for editing within the Transaction Edit Days window set in Business Settings.
Worked example: tracing a disputed invoice
On 3 June a Belgian distributor issues invoice INV-1045 for EUR 2,000 plus VAT of 420 at 21%, a total of EUR 2,420. The customer returns a quarter of the goods on 20 June. The wrong response would be to edit the invoice down or delete it and reissue; either leaves the original figures unrecoverable from the ledger. The right response is a sales return for EUR 500 plus VAT of 105, a credit note of EUR 605, which posts its own reversing journal for revenue, VAT and cost.
When the auditor samples INV-1045 in January, the trail tells the whole story without anyone needing to remember it. The customer's balance is 2,420 minus 605, EUR 1,815, and the Audit Trail, Activity Log and both documents agree.
- 3 June, sale posted: Dr Receivables 2,420 / Cr Revenue 2,000 / Cr VAT output 420
- 20 June, return posted: Dr Revenue 500 / Dr VAT output 105 / Cr Receivables 605
- Activity Log: sale added 3 June, sales return added 20 June, with user, IP address and browser
- Audit Trail: two journals created and posted, neither edited
- Net position: revenue 1,500, VAT 315, receivable 1,815
A monthly audit-trail review routine
Logs only deter misstatement if someone reads them. The review below takes a finance manager under an hour a month in a small business and mirrors the journal-entry tests an external auditor performs under ISA 240. Record the review with a date and initials, so it becomes evidence of a control rather than a private habit. Our guide on journal entry testing and fraud red flags explains the criteria in depth.
- Audit Trail, Action Deleted and Reversed: confirm each has a reason and a replacement
- Audit Trail, Action Approved: entries approved by the person who created them
- Journals posted after the period was reviewed, or dated on weekends and holidays
- Round-sum manual journals and amounts just below the Approval Threshold
- Activity Log, Deletions Today across the month: any deleted final sale or payment
- Activity Log logins from unexpected IP addresses or outside working hours
- Recycle Bin: sales deleted and not restored, with the reason agreed
What auditors will ask for, and how to answer
External auditors rarely read a log on screen. They ask for the full population of journal entries for the year, test that it is complete by agreeing it to the trial balance, and then filter it with their own criteria. Completeness is the step that fails most often: a journal listing that does not add up to the movement in the trial balance cannot be relied on, and the auditor then has to widen testing. Skyline Nexus ERP answers this with the Journal Entries and Journal Lines sheets in the Audit Pack workbook, which come from the same ledger as the Trial Balance sheet in the same file, so the auditor can foot one against the other.
The second request is usually for evidence about who could post and approve. Provide the role list with its permissions, the users in the Admin role, and the Audit Trail filtered by Approved for the year. The third is a sample of changes after the period end, which the Audit Trail's date range and old and new values answer directly. Preparing these three items before the audit starts saves days of back-and-forth; our guide on preparing for an external audit lists the rest of the request.
Retention: keep the logs as long as the books
Statutory retention periods for accounting records commonly run from six to ten years, depending on the country and the record. Logs are only useful for that long if they are kept. In Skyline Nexus ERP, the Accounting Audit Trail clean-up archives logs only when it is run and refuses a retention window of less than 365 days, and the Activity Log removes records older than 365 days when its clean-up runs. Keep a year-end copy of both logs, for example the filtered report views saved to PDF or an extract from your administrator, alongside the Audit Pack, so the evidence for each year is kept for the same period as the books themselves.
Treat these copies as records in their own right: store them read-only, name them by year and log, and include them in the list of documents the auditor receives. Our guide on financial statements and the audit pack in Skyline Nexus ERP describes the rest of the year-end file.
Common questions
What is an audit trail in accounting?
An audit trail in accounting is the record that links every ledger balance to its journals and source documents and logs every change to those records, with the user, action, timestamp and old and new values. An audit trail lets auditors and managers show how each figure was produced and detect unauthorised or unexplained changes.
What is the difference between an audit trail and an activity log?
An audit trail usually refers to the record of changes to accounting entries, while an activity log records user activity across the whole system, including logins, document edits, deletions and imports. In Skyline Nexus ERP, the Audit Trail covers ledger events such as posting and reversal, and the Activity Log covers operational records and user sessions.
Why should posted journal entries be reversed instead of deleted?
Posted journal entries should be reversed instead of deleted because a reversal keeps the original entry, the correcting entry and the reason in the ledger, preserving the audit trail. Deleting a posted journal entry removes evidence and leaves gaps that auditors must investigate. Skyline Nexus ERP only allows draft journals to be deleted.
Can a deleted sale be recovered in Skyline Nexus ERP?
Yes. A deleted sale in Skyline Nexus ERP is soft-deleted to the Recycle Bin, where it can be restored or permanently deleted. Before the deletion, Skyline Nexus ERP reverses the sale's posted journal and each payment journal, and the deletion is written to the Activity Log with the user, time, IP address and browser.
What does the Audit Trail report show?
The Audit Trail report in Skyline Nexus ERP shows accounting events filtered by date range, user and action, with the timestamp, entity, description and details. The details show old values and new values for each change. Events include created, updated, deleted, restored, submitted, approved, rejected, posted, reversed and cancelled.
How long should audit logs be kept?
Audit logs should be kept for as long as the accounting records they support, and statutory retention periods for accounting records commonly run from six to ten years depending on the country. Because application logs may be cleaned after a year, save a copy of the audit trail and activity log at each year end and store it read-only with the year's books.
This guide is general information, not tax, accounting or legal advice. Rules differ from country to country and change over time; confirm the current position with your tax authority or a qualified adviser before acting on anything here.
Ready to run your operation on a single workspace?