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.
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 entryWhat it holds
TimestampWhen the change happened, to the second.
Actor typeuser, system or rule.
ActorThe person's name, when the actor was a person.
Event typeWhat happened — extracted, fields_updated, approved, exported and so on.
DocumentThe invoice the entry belongs to, where the event concerns one.
BeforeThe value the field held beforehand, where there was one.
AfterThe 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 typeMeans
userA person, named. Field edits, approvals, rejections, restores.
systemThe pipeline itself. Parsing, extraction, holding on quota, export attempts.
ruleOne 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.

SourceMeans
ocrRead off the document itself.
bodyRead from the text of the email rather than an attachment.
ruleWritten by one of your rules — a default GL account, for example.
userTyped 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 for the rest of that picture.

Where to go next