In this guide 6 sections
An audit trail is a time-stamped log of who did what in your software, with the value before and after each change, kept by the system itself. Auditors expect it for edits to posted entries, deletions, price and credit limit changes and role changes, because the log stops staff quietly rewriting history.
The five fields every log line needs
Each log line answers five questions: who made the change, which record was touched, when it happened, what the old value was and what the new value is. Many systems add a sixth field, the device or IP address, which helps when a login has been shared between two clerks or stolen outright.
A line reading Invoice updated is useless. A line reading Asha, Invoice 4471, 14 March 16:42, credit days 30 changed to 90 can be questioned, explained and signed off by a reviewer before the audit. Time zones deserve a note: if staff work across offices, store UTC and display local time, otherwise two entries on one invoice look out of order.
- User name tied to a personal login, never a shared one
- Record type and number
- Date and time from the server clock
- Old value and new value, field by field
- Device or network address of the session
Which actions must always be logged
Logging everything produces noise, and logging too little leaves gaps exactly where fraud and error live, so start from the actions that move money or access.
Edits to posted entries come first, since a posted journal voucher or sales invoice should never change quietly and any correction should arrive as a visible reversal. Deletions should be soft deletes that keep a record of what vanished and who removed it, with the reason typed beside the line.
Price lists, discount rates and credit limits deserve logging too, as do changes to roles, such as someone gaining approval rights the week before a payment run. Read access matters too for payroll and supplier bank details, because a log of who opened a salary register answers questions that an edit log never will.
- Edits or reversals of posted ledger entries
- Deleted or cancelled invoices, orders and receipts
- Price, discount and credit limit changes
- Role, permission and approval limit changes
- Failed logins and password resets
What an auditor actually asks to see
Auditors work by sampling, not by reading everything. They pick a handful of transactions and expect each one to carry a story: who raised it, who approved it and whether anyone changed it afterwards.
They also test access, so expect questions on who can post journals, who can approve their own supplier bills and whether a leaver’s login was switched off. This is segregation of duties.
Your auditor sets the scope. This is software guidance, not audit advice. What you can do is make sure the answers exist, export cleanly to a spreadsheet and sit beyond the reach of the people being checked.
How to read the log before the auditor does
Filter the log by action, not by person. Start with deletions in the last quarter, then list every edit made to an entry after its posting date and every voucher reopened after the month was locked.
Look for patterns. Several changes to one customer’s credit limit in a day deserve a question, and so does a user who approves their own purchase orders. Midnight edits by day staff stand out.
Most findings are harmless, such as a typing fix in a customer name or a rate revised after a signed contract amendment, but each needs a recorded reason. Write the reason beside each one. That note outweighs the raw log line once the auditor asks why a figure moved, because the log shows what changed but never the reason behind it.
Protect the log itself
A log that an administrator can edit proves little, so check that nobody, owner included, can alter entries from inside the application. Retention should match your records policy.
Keep a monthly export in a read-only folder. Name it by month. Note the reviewer.
Your first step this week: pick ten posted invoices at random and trace each one through the log, from creation to payment.
Audit trail review sheet
Each high-risk action gets its own line, covering posted entry edits, deletions, price changes, credit limit changes and role changes, in the order a reviewer would test them. Columns hold the date range reviewed, log lines found, exceptions queried, reason recorded, reviewer’s name and sign-off date, with a spare row for anything odd spotted along the way. The footer names the export folder.
Open a blank worksheet to printQuestions owners ask
What is the difference between an audit trail and a backup?
A backup restores data to an earlier day. An audit trail explains how the data reached its present state, line by line, with the person and the moment behind each change.
Can staff switch the audit trail off?
In well-built software, no. The system writes the log itself, and even administrators can only view it, never edit a single line or switch the recording off. If a setting can disable logging, ask who holds that permission, whether its use is itself logged and whether the owner reviews the list of holders each quarter.
How long should audit logs be kept?
Keep audit logs for as long as your accounting and tax records must be kept in your country, which your accountant or auditor can confirm for you. The software should retain them without manual effort.
Does an audit trail slow the system down?
Not noticeably in daily use. Logs are written alongside each transaction, so posting an invoice or a receipt takes no visible extra time for the clerk at the counter. Reports on a very large log can take longer to open, which is why date and action filters matter when you review a whole year of postings.