Audit Logs

Kassly keeps a record of the things people do in your store: who edited a price, who voided a sale, who logged in, who exported data. You read it at Audit Trail in the sidebar.

It exists for two reasons. The everyday one is that it settles arguments — "the price was ₱85 yesterday" has an answer. The formal one is that a BIR examiner looking at a computerised accounting system expects a trail like this, and expects to be able to tell whether it has been altered.

The Audit Trail is not a paid add-on.

Who can read it

Owners and managers only. Cashiers and staff cannot open the page and cannot reach the data behind it — this is enforced on the server, not just hidden in the menu. Managers see their own store's trail, in full.

Each store's trail is entirely separate. If you run more than one business, one business's audit trail never contains the other's.

What is recorded

Two kinds of thing land in the trail.

Changes to records. Every create, update and delete on the records that matter:

Sales and returns	Transactions, returns
Catalogue	Products, services, categories
People	Users, staff payroll profiles
Money	Expenses, expense categories, loans, payroll runs, cheques
Stock	Stock transfers, goods receipts
Buying	Suppliers, purchase orders, sales orders
Setup	Branches, terminals, warehouses, stations, customers, promotions

Account and security events. Logged in, logged out, failed login, password reset, email verified, two-factor turned on or off, store registered, an audit export pulled, and any question asked of Insights AI.

What each entry holds

Field	What it tells you
Timestamp	When it happened
Action	Created, Updated, Deleted, Voided, Logged In, Exported, and so on
User	Who did it — name, email and role
Record type and ID	Which product, sale, or user was touched
Old values	The fields as they were, before the change
New values	What they became
IP address and device	Where the request came from
Terminal	Which till, when the change happened at one
Chain values	Two fingerprints that prove the entry has not been altered

An update records only the fields that actually changed, with their before and after values — not a copy of the whole record. That keeps the trail readable.

Voiding a sale is surfaced as its own Voided action rather than being buried among ordinary edits, because it is the one everybody comes looking for.

Reading the trail

The Audit Trail page filters by:

Filter	Notes
Action	Grouped as Data changes, Authentication and Sensitive
User ID	The numeric ID of the person
From / To	A date range
Terminal	One till
Search	Matches a record ID, or an exact IP address

Entries are newest first, 25 at a time by default and up to 100.

The search box is narrow on purpose: it matches record IDs and IP addresses, not free text. To find "who changed the price of this product", filter by Action: Updated and search that product's ID.

Exporting for an auditor or an examiner

Export CSV downloads the trail for the date range and terminal you have filtered to. The file is named audit-logs- plus the date and time you pulled it.

The CSV is the version to hand to an accountant or a BIR examiner. It carries more than the screen does — including the chain fingerprints, so a technical reviewer can verify the trail independently, offline.

Exporting is itself recorded. Your own export appears in the very trail you just exported, as an Exported entry, with the row count and the filters you used. That is intentional. Report exports elsewhere in Kassly are not audited — only this one.

Why the trail can be trusted

Three properties, all enforced by Kassly rather than by policy:

• Entries cannot be edited. There is no way, through any screen or any API, to change an audit entry after it is written.
• Entries cannot be deleted. Not by you, not by a manager, not by support.
• Entries are chained. Each entry carries a fingerprint that includes the fingerprint of the entry before it, per till. Removing or altering an entry in the middle breaks every fingerprint after it, which is detectable.

A note on completeness: an entry needs a signed-in user to attribute it to. Changes made by Kassly's own scheduled jobs — a nightly sweep that closes stale shifts, for instance — have no user and are not written to your trail.

Two entries you may find surprising

• Failed logins are recorded. Someone guessing at your password leaves a trail of Login failed entries with the IP address they came from. Worth a look if something feels wrong.
• Support access is recorded but hidden from this page. When Kassly support accesses your store to investigate a problem, that is written to the chain, but the Audit Trail page does not show it inline — an entry reading "support accessed your account" alongside routine cashier activity alarms people out of proportion to what it means. It is in the CSV export. If you want to see exactly when support has been in, export the trail.

How long it is kept

Audit entries are kept for as long as your store exists. Kassly does not prune or archive them, and there is no retention setting to shorten them.

For context, the BIR requires books and transaction records to be retained for ten years. Kassly protects your financial records — sales, receipts, payments, stock movements and Z-readings — from permanent deletion on that basis, and the audit trail sits alongside them.

If your store is closed and deleted, the trail goes with it. Export first.

What the audit trail is not

• It is not a report. It records changes, not results. For what you sold, see Sales reports.
• It does not record most reads. Opening a page, running a report, or looking at a customer is not logged. The two exceptions are pulling an audit export and asking Insights AI a question — both of those are recorded.
• It cannot undo anything. It tells you what a value used to be. Putting it back is a change you make yourself, and that change is logged too.