Audit trail
Who did what, when and from where. What is recorded, how to review it and how long it is kept.
The audit trail answers one very concrete question: "who touched this?". A payment that turned up modified, a client someone deleted, a loan whose arrears changed with no explanation. Every action that modifies data is recorded with a name and a timestamp.
It is the tool you reach for when something does not add up and you work with collectors.
Who can see it
Only the account owner. This is not a permission you can delegate to an agent: it is a business-owner capability. A collector who opens that section sees a "no access" message.
That makes sense: the point of the log is to keep an eye on what the team does, and it would be useless if the team could read it (or worse, alter it).
What gets recorded
Every action that MODIFIES data and completes successfully is recorded: creating a client, registering a payment, editing a loan, deleting a document, inviting an agent, changing permissions.
What is not recorded:
- Reads. Opening the client list or looking at a report leaves no trace. Only changes do.
- Failed actions. If a collector tried something and the system denied it, there is no audit row (the failed attempt changed nothing).
For each action, the following is stored:
Field | What it is |
|---|---|
Date and time | The exact moment of the change |
Actor | Who did it, by name (or their email if they have not completed their profile yet) |
Actor type | A user of your business, or a platform administrator |
Resource | What was acted on: clients, loans, payments, documents… |
Resource id | Which one exactly |
Action | What was done: create, update, delete… |
Request | The method and path (POST /loans/:id) |
IP and browser | Where it was done from |
Detail | A summary of the data sent with the operation |
What never appears in the log
- Passwords, tokens, keys and card numbers. If a field looks like a secret, it is stored as [redacted]. The log exists to audit, not to leak credentials.
- The request's query parameters: the path is stored clean, without anything after the ?.
- If the submitted detail was huge, it is trimmed: you will see a truncation marker instead of a giant row.
Reviewing it
Open Audit. You will see a table with the most recent entries on top, and filters above it:
- Resource: type payments, loans, clients… to narrow down to one area.
- Action: to look for a specific kind of operation.
- Actor: to see everything one person did.
- From / To: the date range.
Click a row to open the full detail: there you will find the resource id, the actor type, the browser and the summary of the data sent, none of which fit in the columns.
A typical case: a client claims they were overcharged on the 12th. You filter by resource payments and by the 12th-to-12th range, and you see who registered the payment, at what time, from what IP and with what amounts. In thirty seconds you know whether it was a typo or an argument about who remembers what.
It cannot be altered
The log is write-only: rows are appended, never edited or deleted. Neither you, nor an agent, nor support can change a row once it is written. That immutability is precisely what gives it internal evidentiary value.
How long it is kept
Here plans do differ:
Plan | History kept |
|---|---|
Basic | 30 days |
Gold | 60 days |
Premium | 90 days |
An automatic cleanup runs daily and deletes anything outside that window.
What is purged cannot be recovered. If you are on Basic and need to review what happened two months ago, it will not be there. If your operation needs long review windows (audits, disputes that surface late), that is a genuine reason to be on Gold or Premium. See Your plan limits.
One detail in your favour: if you cancel your subscription, the cleanup stops running for your account. Your audit history is not drained further while you are away.