Audit Log¶
Overview¶
The audit log helps you investigate changes to Credence records: who is attributed to a change, when it happened, what action occurred, and which recorded values changed. Use it to review activity on records such as payables, leases, payments, transactions, and administrative settings.
Events appear newest first. A single business action can change several records and produce several events—for example, adding a payable and its charge items. The log records changes to supported records; it is not a list of every page visit or action in Credence.
Independent history and protection against manipulation¶
Credence stores audit events in a separate audit store from the production database that holds business records. An event preserves the recorded change at that time; it is not reconstructed from the record's current values. Editing a payable again, for example, does not rewrite its earlier audit events.
This separation helps prevent someone from concealing activity simply by changing the business record back or altering its current data. Credence does not provide the ability to edit or delete audit records. Changing or restoring production business data also does not itself rewrite the separately stored audit events.
Separate storage is a protection against manipulation, not a guarantee of absolute immutability. Privileged access to the audit store must still be controlled, and recorded history remains subject to retention and audit coverage. The log cannot establish changes that were never captured.
Reading an event¶
| Information | Meaning |
|---|---|
| Timestamp | When the change was recorded, rather than the record's accounting or effective date. |
| User | The user or system identity attributed to the change. |
| Source | How the change reached Credence, shown beneath the user as “via MCP,” “via API,” “via Web,” “via System,” or “via Unknown.” Source and user attribution are separate. |
| Event Type | Whether a record was created, updated, or deleted. |
| Model | The kind of record affected, such as Payable or Lease. |
| Object | The affected record, with a link when it is available. |
| Changes | A summary of the recorded values associated with the event. |
Create shows recorded values on a new record. Update shows changes from the previous value to the new value, such as a due date changing from one date to another. Delete shows recorded values from the removed record. Deletion is different from changing a record's status to cancelled or archived; a status change is an update.
The Changes summary can be shortened when several fields changed. Where a history link is available, open the event's record history to inspect the recorded changes in more detail. Some related-record events link through their parent record. An object link opens the current record; its current values may differ from the values recorded at the event's timestamp.
Finding changes¶
The initial date window is the last 90 days. Set an earlier start date to look further back in the available history. From and To dates include events on the selected dates.
Combine filters to narrow the results:
| Filter | Use it to find |
|---|---|
| User | Changes attributed to one or more users represented in the available events. |
| Source | Changes from Web, API, MCP, System, or Unknown. |
| Event Type | Creates, updates, or deletions. |
| Model | Changes to a particular kind of record. |
| Date range | Changes recorded during a particular period. |
| Search | Text in the object description or displayed change summary; matching ignores capitalization. |
Understanding Source¶
| Source | Meaning |
|---|---|
| Web | A change made through the web application. |
| API | An API request whose client is not registered as an MCP connector or system service. |
| MCP | A request authenticated with credentials registered to an MCP connector. |
| System | A change made by a background task or registered system service, including ingestion and mail merge. |
| Unknown | The source was not recorded or could not be identified. Events recorded before source attribution was introduced show Unknown. |
Source describes what performed the recorded change. Uploading an invoice through the web is Web; a payable subsequently created by ingestion is System. A task can be System even when a person originally triggered the work.
Source does not replace user attribution or establish human review or approval. An API request can come from a person or automation, and an agent can use a web interface. Supported changes through a registered MCP connector show MCP. Reading records through MCP does not create change-audit events.
Record history and downloads¶
Where available, select an event row to open that record's audit history. Use the Object link to open the business record itself. History links depend on the record still being available and on your access; some events have no link.
Record histories also show the source with the user. If only creation and last-modification details are available instead of recorded audit events, their source is Unknown. A source cannot be determined from the user alone.
Download the audit table as CSV for spreadsheet review or PDF for sharing. Downloads include the user and “via” source together and contain the summaries on the current page, with the current filters applied. They do not automatically include other pages or all fields from record history. Adjust the page size or download separate pages if needed.
Access and coverage¶
Viewing the audit log requires audit-log access. Results are also limited by customer attribution and your access to the affected records. Audit-log access does not grant access to otherwise restricted records. Deleted or no-longer-accessible records may be absent from the management list even when a change event was recorded.
Only supported records and recorded fields are audited. Viewing a record does not itself create a change event. Some fields are omitted, and events may take a short time to appear after a change. The log is for investigation; it does not undo changes or restore deleted records.
Available history depends on retention and when auditing began. Widening the date range cannot recover expired events or changes that were never recorded. If results are empty, check your dates and filters, allow time for a recent change to appear, and confirm your access before concluding that no change occurred.
Common scenarios¶
- Investigate a changed invoice due date: filter to Payable updates and the relevant dates, search for the payable, then review its recorded old and new values.
- Review ingestion activity: filter to System and the relevant record type. Several events may represent one ingestion because it creates or updates related records.
- Review changes attributed to a colleague: filter by User and date range, then use Source to distinguish browser activity from system or integration activity where recorded.