Audit Trail

A figure on a document is not what someone expected, and you need to find out what happened to it. By the end of this guide you will have found the exact change: who made it, when, and what the value was before. You will also know how to read what you find and what to do with it, which matters just as much when you are the one being asked. Plan on about 15 minutes.

Meet GadgetSphere Sdn Bhd

GadgetSphere Sdn Bhd runs 22 consumer-electronics branches across Malaysia. This morning a corporate customer forwarded the sales invoice they received last week and asked why the total on their copy, RM 12,400, is not the RM 11,900 now showing in BigLedger. Nobody in the sales office remembers touching it. Finance wants an answer before the payment run on Friday, and the audit trail is where you will find it.

The audit trail answers what changed and who changed it. It does not tell you why, and it does not judge whether the change was allowed. Treat what you find as evidence rather than a verdict, because you will still need to talk to the person whose name comes back.

Finding a change, at a glance

Open Audit Trail in the applet the document lives in. It holds only changes made from that applet; Tenant Admin, open to OWNERs and ADMINs only, shows every applet. If the menu shows and the list stays empty, the permission is the cause (Before you start, Step 1).
Search the document number, or, for a document that is not recent, search a Date Updated range, press ALL, then filter the Doc No column: the Doc No search can miss older changes, and an empty result does not mean nothing changed (Step 2).
Open the row and read the changed fields, old value beside new. The view shows the header only, so a line change appears only through the totals it moved (Steps 3 and 4).
Read Action By and Date Updated. Unknown User is a question to answer, not an answer, and a change you expected but cannot find may have come from another applet or from no applet (Step 5).
Treat what you find as evidence, not a verdict: the trail says who and when, never why or whether it was allowed (Use cases).

The job runs across three pages. Steps 1 and 2 are on this one, Steps 3 to 5 are on Read the change, and the questions people bring to the trail, the tenant-wide screen in Tenant Admin and what the trail will not do are on Use cases and Tenant Admin.

Two ways in

Every audited change is one record, and you can reach the same records from two places.

	Inside the applet (this guide’s main route)	Tenant Admin → Audit Trail
Use it when	You know which document you are asking about	You are looking across applets, such as everything one person changed this week
Shows	Changes made from that applet, newest first	Changes made from any applet, and changes made with no applet at all, newest first
Find a document by	Its document number	Applet code, table name, the person and dates
The change	Only the header fields that changed, old value beside new	The same view
Who can open it	OWNER or ADMIN, or anyone given the audit trail menu permission	OWNER or ADMIN only

Start inside the applet. It is faster, it finds a document by its number, and it is the only route open to a supervisor who is not a tenant admin. Go to Tenant Admin when the change you expect is not there, because an applet’s trail only holds changes that were made from that applet (see Step 5).

Audit trail: a few terms to get straight

Audit record. One row for one change to one record somewhere in BigLedger. It holds a snapshot of the record’s data before and after the change, plus who and when. For a trading document the snapshot is the whole document, lines included, but both screens show you only its header (see Step 3). One save can write more than one row, which is why you will often see two or three UPDATED rows for the same document a second or two apart.
Action. What happened: CREATED, UPDATED or DELETED. On screen this is the Action Name column.
Table name. Where the changed record lives. bl_fi_generic_doc_hdr is the document header: the customer, the dates, the totals and the status of a sales invoice, a purchase invoice or any other trading document. Most of what you will investigate is on that table.
Status and posting status. Two different things on a document. Status says whether the record is live: TEMP from the moment someone opens the form to create it, ACTIVE once it is first saved. Posting status is where it is in its life: DRAFT, FINAL, VOID or DISCARDED. Most investigations turn on posting status.

Before you start

You need access to the Audit Trail menu. It appears in the applet’s sidebar for tenant OWNERs and ADMINs, or for anyone given a permission whose code ends in SHOW_AUDIT_TRAIL_REPORT. The menu permission alone is not quite enough, because the list behind the screen also asks for an audit trail permission, and at the moment it accepts only the OWNER, ADMIN or CREATE one, not READ. If the menu appears but the list stays empty, that is why.
The menu can be hidden per applet. Each applet has a HIDE_AUDIT_TRAIL_MENU switch under Settings → Application Settings → Sidebar Menu. It hides the menu from OWNERs and ADMINs, but not from someone who holds the menu permission, because the permission wins.

The HIDE_AUDIT_TRAIL_MENU switch in the Sales Invoice applet's settings — Settings → Application Settings → Sidebar Menu. The switch is per applet: hiding it in Sales Invoice leaves it visible in Sales Order.

Know the document number, and roughly when the change happened. A week is fine. You will need the dates if the document is not recent (see Step 2).

Step 1: Open the applet’s audit trail

Sales Invoice → Audit Trail

Open the applet the document belongs to, here the Sales Invoice applet, and click Audit Trail near the bottom of its sidebar. The item comes with BigLedger’s shared sidebar, so an applet shows it once it has been built on the current version of that sidebar; if an applet you use does not show it, reach its changes from Tenant Admin instead. Each applet’s trail shows only its own applet’s changes.

The Audit Trail link in the Sales Invoice applet's sidebar — Audit Trail sits at the end of the sidebar, above Settings.

The listing opens on the newest change first, 50 rows at a time. More loads the next 50 and ALL loads the rest.

The audit trail listing inside the Sales Invoice applet — Doc No comes first, and Date Updated runs newest to oldest. The count on the right is every change this applet has recorded.

Two things to notice straight away:

Rows with no Doc No are usually the first save of a document. A new invoice is saved before it gets its number, so its CREATED row has an empty Doc No, and the number only appears on the UPDATED rows after it. In the listing above, the CREATED row at 20:51 is the same invoice as the UPDATED row for 1002083 at 21:30.
Status here is the audit record’s own status, not the document’s. It says ACTIVE on almost everything. What happened to the document is in the details, which you will read in Step 3.

Step 2: Find the document’s changes

Type the document number into the search box at the top and press Enter, or open the advanced search with the filter icon at the right of the box.

The advanced search panel — Doc No, Action and the two date ranges are the fields you will use most.

For a recent document this is all you need:

Five UPDATED rows for document 1002083 — Every UPDATED row for 1002083. The CREATED row is not here, because it was written before the invoice had a number.

The Doc No search can miss older changes. It looks through the most recent few hundred changes and stops at the first batch that contains a match. For an older document you may get nothing, or only some of its rows. An empty result does not mean the document was never changed.

For a document that is not recent, use this reliable route instead:

Leave Doc No empty. In the advanced search, set Date Updated From and To to the days around the change, and click SEARCH.
Click ALL so that every row in that range is loaded.
Type the document number into the small filter box under the Doc No column header.

The date range is applied by the server, so nothing in the range is left out, and the column filter only has to search rows that are already on your screen.

Two more things about the search boxes:

Action By must be typed exactly as the name was stored when the change was made, capitals included. sales clerk does not find Sales Clerk. The column shows the person’s current profile name, so if someone has renamed their profile since, the name you see in the column may not be the one the search needs. Search by date instead and read down the column.
The Doc No search does not find a CREATED row written before the document had its number, which is the usual case, for the reason in Step 1. To see who created a document, search with Action set to CREATED and a Date Created range that ends just before its earliest UPDATED row.

Even after the date-range route and a look in Tenant Admin, a missing row proves nothing: only audited operations are recorded, and when the audit write itself fails the change still stands with no row (Good to know).

Next: Step 3, open the change.

Audit trail use cases

To see what a document’s whole life looks like in the trail, follow one sales invoice from start to finish: created, saved, edited, finalised and voided, every row in the order it was written, with a screenshot of each.

Eleven questions that finance and operations teams bring to the audit trail — a disputed invoice total, who finalised, discarded or voided a document, a sale under the wrong branch, a document that seems to have disappeared, a month-end check of what changed after the books closed — and the checks that answer them are on Audit Trail: Use Cases and Tenant Admin.

What success looks like

You can say, in one sentence and without hedging: “The total on invoice 1002083 was changed from RM 12,400 to RM 11,900 by [name] at [date and time], and the discount changed in the same save.” If any of those facts is missing, you have not finished: go back to Step 2 and try the date-range route.

Common mistakes

The first two belong to Step 2 on this page; the other three to Steps 3 to 5.

Trusting an empty Doc No search. It can miss older documents entirely. Use the Date Updated range, ALL and the column filter, then Tenant Admin, before concluding a document was never changed.
Looking for the CREATED row by document number. It was written before the number existed. Search by Action = CREATED and a date instead.
Reading Status as the document’s status. It is the audit record’s own status. What happened to the document is in posting_status, inside the details.
Reading one field in isolation. A new total on its own says what it became, not why. Read every field in the change list for that save, and remember that a line change shows only as the totals it moved.
Stopping at “who”. The audit trail gives you the name. Whether the change was right is a conversation with that person and with whoever approves that kind of change.