Audit Log

A permanent, searchable record of who changed what and when — the page you open when something looks off.

Updated April 9, 2026

The Audit Log is the searchable record of who did what in your books. Every significant action — create, edit, delete, void, approve, merge, invite, permission change — is recorded with a timestamp, the user who performed it, and enough context to understand what changed. It's the page you open when something looks wrong and you need to answer "how did this end up this way?"

Good books aren't just balanced — they're accountable. If your treasurer asks why an expense was reclassified from one fund to another, the Audit Log has the answer. If your auditor asks whether any posted transactions have been altered since month-end, the Audit Log has the answer. If you suspect a mistaken deletion or an unauthorized change, the Audit Log is the first place to look. For organizations preparing for an audit or responding to a board inquiry, the ability to produce a clear activity record is table stakes.

  • Admin, owner, or accountant role — the Audit Log contains sensitive history and is not visible to members or viewers
  • Activity to look at (a fresh installation with no history won't have much to show)

Opening the audit log

  1. Go to Settings > Audit Log (or use the direct path /audit-log/).

Reading the log

Each entry shows:

  • Timestamp — when the action happened
  • User — the email address of the user who performed the action, or "system" for automated actions
  • Action — what was done (create, edit, delete, void, approve, merge, login, permission change, etc.)
  • Record — the thing that was acted upon, typically with a link to the record's detail page so you can jump straight there
  • Details — additional context (before/after values for edits, the reason for a deletion, etc.)

Entries are sorted newest first by default.

Filtering the log

  • Date range — several presets are available (This Month, Last Month, Fiscal Year, All Time) plus a custom range picker. Narrow the window before scanning for a specific event.
  • Action type — filter to a single category like "void" or "delete" to find all events of that kind.
  • User — scope the log to a single user's activity.

Summary statistics

The page shows summary counts at the top:

  • Total entries in the selected range
  • Breakdown by action (how many creates, edits, voids, deletes, etc.)
  • Top users by activity — who's been most active

These are useful for quickly spotting unusual patterns (for example, an unexpected spike in voids or deletions).

Exporting to CSV

Click Export CSV to download the current filtered view as a spreadsheet. The export includes every column and respects the filters applied to the page view, so you can hand a targeted slice to an auditor without sharing the whole history.

Support session indicators

If a support session is active — meaning a support agent has been explicitly authorized by the owner to access the organization's data — the log flags actions taken during that session with a badge. This makes it clear after the fact which entries were made by your staff versus by a support agent operating under consent.

  • Sensitive actions (voids, deletions, edits to posted transactions) are what they should be. Every entry should have a plausible reason behind it.
  • Unfamiliar users — if you see activity from an email address you don't recognize, immediately check your team membership and revoke access if needed.
  • Activity during periods when the organization should have been inactive (holidays, nights, weekends) — worth a second look if you see something unexpected.
  • Support session entries are expected and approved. If you see support session activity you didn't authorize, contact support and review the support access log.
  • Treating the Audit Log as a to-do list. It's a history, not a task queue. Use it to investigate, not to track ongoing work.
  • Exporting the entire log without filters. For an active organization, the full history can be enormous and hard to work with. Filter first, then export.
  • Assuming voids and deletions are bad. Neither is inherently a problem — voiding a mistaken transaction is the correct way to fix it, and some deletions are legitimate (cleaning up a Draft that was never going to be posted). The log is there to make these actions visible, not to imply they shouldn't happen.
  • Forgetting that the log is write-once. You can't delete an audit log entry. That's the whole point — the record of what happened is preserved regardless of whether the underlying data was later changed or removed.

Accountant note: A preserved, tamper-resistant activity log is a standard internal control for small nonprofits and a common audit request. Pair the Audit Log with the void-transaction trail in the ledger itself — together they give you a complete picture of any correction made to posted entries, which is what auditors are looking for when they test for unauthorized changes.

Ready to try NP Ledger?

Native fund accounting, Form 990 support, and smarter bookkeeping for nonprofits.