The problem
When something in the books looks wrong - a customer's payment terms changed, an invoice was edited after the fact, a team member's permissions were quietly escalated - the business needs a real answer to who did it and when, not a guess. Many systems either don't log this at all, or log it in a way that can itself be edited or deleted, which defeats the purpose.
How AccountDesq solves it
Every privileged action and change to core records writes a row to an append-only audit log - the codebase has no update or delete path for it, by design. Each entry captures the actor, the action, the target record, and a before/after snapshot in its metadata. Viewing the audit trail requires a dedicated `audit.view` permission, and what a viewer sees is scoped to their assigned branches, with workspace-level entries (role and member changes, which don't belong to any one branch) visible to every audit viewer regardless of scope.
How it works, step by step
An action happens
A role is changed, a member is assigned, or a customer, vendor, invoice, or payment record is modified.
A row is written, not edited later
The audit log is append-only - there's no code path to update or delete an entry once written.
The entry carries context
Actor, action, target, and a before/after snapshot are captured, not just a bare timestamp.
Viewing is permission-gated and scoped
Only members with audit.view can see the log, and what they see is limited to their branches - except workspace-level entries, which every audit viewer can see.
Connected to the rest of AccountDesq
Nothing here works in isolation - it posts through the same ledger as everything else.
In practice
A finance lead notices a customer's payment terms changed from Net 30 to Net 90 and wants to know why. Instead of asking around, they open the audit trail, filter to that customer record, and see exactly who made the change, when, and what the value was before - a specific, checkable fact instead of a guess.
What this means for your business
- A real answer to 'who changed this and when' instead of relying on memory or Slack history.
- An audit record that can't be quietly edited or deleted after the fact, because no code path exists to do so.
- Audit visibility that respects the same branch scoping as the rest of the platform, so reviewing it doesn't require giving someone access to data outside their role.
Frequently asked questions
Can an audit log entry be edited or deleted?
No - the audit log is append-only by design. There is no update or delete path for it in the codebase.
Who can view the audit trail?
Only members with a dedicated audit.view permission, and what they see is scoped to their assigned branches - except workspace-level entries like role changes, which every audit viewer can see.
What kinds of changes are logged?
Privileged actions like role and permission changes and member assignments, plus changes to core records including customers, vendors, invoices, and payments, each with a before/after snapshot.