--- title: Audit trail description: What the audit log records, why it is append-only with no edit or delete path, and how to use it at month end or when an auditor asks a question section: Reference order: 25 --- # Audit trail Every change to a document in InletAP is written to an audit log: what changed, who or what changed it, and what the value was before. This page describes what is recorded, what is not, and how to get an answer out of it when somebody asks where a number came from. ![The audit log timeline, showing parsed, extracted, rules applied, approved and exported entries with the actor for each.](/screens/audit-log.png "One document's life, newest first. Each entry names who or what acted — a person, the system, or automation.") It is worth reading if you close the books, answer auditor questions, or have to explain an approval to an owner six months after the fact. ## What one entry records | Part of the entry | What it holds | | ----------------- | -------------------------------------------------------------------------------- | | Timestamp | When the change happened, to the second. | | Actor type | `user`, `system` or `rule`. | | Actor | The person's name, when the actor was a person. | | Event type | What happened — `extracted`, `fields_updated`, `approved`, `exported` and so on. | | Document | The invoice the entry belongs to, where the event concerns one. | | Before | The value the field held beforehand, where there was one. | | After | The value it holds now, plus any detail the event carries. | The before/after pair is the part that matters in an audit. "Somebody edited this invoice" is gossip. "The total read 4,120.00, and Priya changed it to 4,210.00 at 09:14" is a record. ## Actor types There are three, and they are kept apart deliberately. | Actor type | Means | | ---------- | ---------------------------------------------------------------------------- | | `user` | A person, named. Field edits, approvals, rejections, restores. | | `system` | The pipeline itself. Parsing, extraction, holding on quota, export attempts. | | `rule` | One of your coding rules fired and changed something. | The distinction is the reason the log is worth keeping. An auditor's first question about automation is never "does it work", it is "how do I tell what the machine did from what a person did". Filtering the log to people only, or to automation only, answers that in one action. ## Field sources Separately from the actor, each extracted field records where its value came from. | Source | Means | | ------ | ----------------------------------------------------------------- | | `ocr` | Read off the document itself. | | `body` | Read from the text of the email rather than an attachment. | | `rule` | Written by one of your rules — a default GL account, for example. | | `user` | Typed or corrected by a person. | A GL account with source `rule` and a GL account with source `ocr` are very different claims about the same number. The first is your standing instruction; the second is something a model believes it saw printed on a page. Keeping them distinct is what lets you decide how hard to look. ## What is logged Documents accumulate entries from the moment the message arrives: parsing, extraction with its confidence, a rule match and what it set, a hold on plan quota, a filtered document and a later restore, field edits, a duplicate marked against its original, the send for approval, each approval or rejection with its comment, and every export attempt including retries. Membership changes are recorded too — invitations sent, accepted and revoked, role changes and removals — because "who was allowed to approve in March" is a question that outlives the person's employment. ## Append-only, and why that is not a small thing No role has an edit path or a delete path into the log. Not the AP specialist, not the controller, not the admin, not the owner of the company. There is no interface for it because there is no route for it. This sounds like a technicality and it is the whole value of the thing. A log that a sufficiently senior person can tidy is not evidence of anything; it is a record of what the most senior available person wanted to be true. The moment an administrator can remove one line, every remaining line is worth less, including all the honest ones. The practical consequence is that mistakes stay visible. If you code an invoice to the wrong building and fix it an hour later, both facts are in the trail for good. That is the correct outcome. A correction with its original attached is a stronger record than a clean one, and anybody who has sat through a review knows which of the two an auditor finds reassuring. It also means the log cannot be used to hide a disagreement. A rejection keeps its comment. An approval that was later reversed keeps both events. ## Using it at month end The log filters on the things you actually search by: a document, an actor, an event type, a date range. The audit screen adds a free-text search across records, fields and values for when you know the invoice number and nothing else, and a toggle between people and automation. Three habits cover most of month end. - **Reconcile the exports.** Filter to export events for the period and compare the count against what landed in your ledger. Anything that failed and was retried shows both attempts, so a bill posted late is distinguishable from a bill posted twice. - **Review what automation decided.** Filter to automation only. This is where you find a rule that has quietly been coding a vendor to the wrong account since you wrote it, which is a far more common failure than a rule that does nothing at all. - **Check the corrections.** Filter to people only and look at `fields_updated`. A vendor whose totals are corrected by hand every month is telling you either to write a rule or to expect that vendor's layout to keep costing you time. The screen exports the entries currently in view as a CSV, with timestamp, actor, role, action, record, field, before and after as columns. That is usually the artifact to hand to an auditor: the whole log is rarely what anybody wants, and the filtered slice covering the question they asked is. ## Limits worth knowing The log records what happened inside InletAP. It does not record what happened afterwards in your ledger — if somebody edits a posted bill in QuickBooks, that edit is in QuickBooks' own history, not here. Audit records are kept for as long as your workspace is active, because they are part of your accounting record. There is no per-workspace retention setting today, and we would rather say so than describe an absent feature as a policy decision. See [security and data](/docs/security-and-data) for the rest of that picture. ## Where to go next - [Security and data](/docs/security-and-data) — tenant separation, retention and what we do not have. - [Roles and permissions](/docs/roles-and-permissions) — who can do what, which is what the actor column reflects. - [Invoice statuses](/docs/invoice-statuses) — the states the log records transitions between. - [Month-end export](/docs/month-end-export) — the close this trail is usually read alongside.