Opening a receipt's history

Open any receipt's detail page and click History. The URL is /receipts/<id>/history — every receipt has one, even if it's never been edited (creation itself is the first entry).

Reading the timeline

The history page is a timeline, newest first. Each entry shows:

What changed
A Receipt or Line item badge (line-item entries name the item), plus the operation: INSERT when something was created, UPDATE when it was edited, DELETE when a line item was removed.
Who changed it
manual means the change was made by someone signed in to the account; system means automatic processing did it — AI parsing filling in fields, enrichment refining a vendor name, or a reprocess run. The history distinguishes manual from automatic work; it does not identify individual people sharing one login.
Field-by-field diff
For updates, a table of each changed field with its before and after value — so "the total changed" is never a mystery, you can see it went from 84.95 to 89.95 at 14:02 on a given day.

Busy receipts accumulate a lot of automatic entries during initial processing. Use the Hide automatic changes checkbox at the top of the timeline to see only manual edits.

What gets recorded

  • Receipt fields — vendor, total, tax amount, date, currency, category, notes, WFH treatment, companion linking, source, OCR details, enrichment, processing state and errors, and deletion state. Changes to these fields produce visible before/after values.
  • Line items and tags — additions, edits and removals of individual items are logged with the item's name. Adding or removing a tag produces its own entry; renaming or merging a tag appears as the underlying removal and addition.
  • Automatic processing — the values AI parsing wrote, and any later changes from reprocessing or enrichment, appear as system entries. Your manual corrections are never silently overwritten — if processing changes something you set, the log shows exactly that.

Pipeline events (queued, parsed, enriched, failed) are tracked separately from field history — see When processing fails for reading processing status.

Why the log can be trusted

The audit trail isn't written by application code that could skip a case — it's written by a database trigger. Any change to a receipt row, from any code path, is logged by the database itself at the moment it happens. The trigger stores complete before and after snapshots; the page turns the meaningful fields into readable diffs and keeps internal payloads and storage bookkeeping out of the way. There is no way for an edit to occur without leaving an entry, and no way to edit the log from the app.

  • For tax: if a figure is ever questioned, you can show what the receipt said when it was captured and every adjustment since — with the original file stored untouched alongside.
  • For shared logins: the history shows whether a person or automatic processing made the change, but it cannot distinguish between people using the same account.
  • For debugging your own data: when a total looks wrong, the diff usually shows exactly when and how it got that way — and what to set it back to.