Understanding the audit history
Every change to a receipt — every field, every line item, whether made by you or by automatic processing — is recorded with before and after values. Here's how to read the timeline, and why the log can be trusted.
On this page
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:
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, date, currency, category, notes, tax amount, and the rest. Any field edit produces a diff entry.
- Line items — additions, edits and removals of individual items are logged the same way, labelled with the item's name.
- 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. 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 accounts: in a household account, the history answers "who changed this?" without anyone having to remember.
- 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.