Audit Log

Sooner or later a question comes up that the books themselves can’t answer: who deleted that invoice? When was the period lock moved, and by whom? What exactly did the import change last night? The Audit Log is where those answers live — one stream, across the whole dataset, of every change anyone or anything has made.

Open it under General Ledger → Audit Log (requires the audit permission). There is nothing to switch on: logging is always active, for every user, from day one.

Two things to know up front:

• It sits next to a different screen. General Ledger → Audit is the settings screen for the period lock and the deletion rule — that one is covered in Closing the Books. This page is about the log.
• It complements the per-record History. Journal entries, sales invoices, AR/AP transactions and customer and vendor records each show their own timeline on their edit screen. The Audit Log shows all of them in one place — and it is the only place that still shows what happened to a record after the record itself has been deleted.

Reading the log#

Entries are listed newest first, fifty per page, with the total count above the list and a Refresh button to re-read it.

Each entry is one line: what was done, to which record, by whom, and when. The verb is specific where it can be — Posted as new, Payment added, Created from bank matching, Bulk updated (AI Assistant) — so you can usually tell not just that something changed but how it was changed.

Entries on invoices, transactions, journal entries and customer or vendor records link straight through to the record. Configuration and system entries are plain text, and so are deleted records — there is nothing left to open — but the entry keeps the name or number captured at the moment of deletion, so the line still tells you what was removed.

Entries that carry change details expand on click into a field-by-field comparison: the old value struck through, an arrow, the new value, grouped by section (header fields, lines, payments, attached documents). That before → after view is the log’s real value — not just that the due date changed, but from what to what.

Narrowing it down#

Four filters sit above the list, each applied as soon as you set it:

Performed by distinguishes four kinds of actor, and it’s the filter to reach for when you’re tracing automation rather than people:

• User — a person working in the app.
• API key — a request made with one of your API keys, recorded against the user the key belongs to and marked via API key.
• Background job — scheduled and automatic processing: bank imports, batch emails, documents arriving by upload or email.
• System — internal actions neoo performs itself.

So “what did the bank import do overnight?” is Performed by: Background job, and “which changes came in through the integration?” is Performed by: API key — no guessing from timestamps.

What the log guarantees#

The log is read-only. Nobody — not an administrator, not the person who made the change — can edit or clear it. That is the point: it’s the one record in your books that can’t be tidied up after the fact.

That matters most for deletion. Deleting a transaction in neoo is a hard delete — as Batch Update spells out, there is no recycle bin — and the Audit Log entry, with the name and amount captured at deletion time, is the only trace that remains.

The audit permission shows every change across the whole dataset, including amounts on every document — and the same permission controls the period lock. Grant it as narrowly as Closing the Books already advises.