One receipt, four layers, none of them destructive.
Capture, extraction run, document, transaction. Each is its own database record, so nothing has to be re-photographed and nothing gets silently overwritten — including six months from now, when the model reading your receipts is better than the one that read them today.
An $82.50 invoice from a hardware supplier
The same example moves through every step on this page, ending as a posted, BAS-labelled ledger entry.
- 1Capture
You photograph the receipt
The camera checks focus and framing before it lets you upload — a blurry photo of a crumpled receipt gets rejected on the spot, not three steps later. What gets stored is the original image, untouched, forever. That's the copy that counts as evidence if the ATO ever asks; a separate, lightly processed copy is what the model actually reads.
In this exampleA photo of an Ironbark Trade Supplies invoice, taken at 7:41am on-site.
- 2Extraction run
A model reads it — and the read is versioned
Claude reads every field off the image — supplier, ABN, line items, GST — and attaches a confidence score to each one. It's told explicitly: if it isn't sure, say so, don't guess. Nine arithmetic and ATO-rule checks run immediately after. Anything uncertain, or anything that fails a check, gets a second, stronger read automatically. This whole attempt is saved as a numbered "run" — it's never edited in place, only ever superseded.
In this exampleRun #1 reads the ABN as 84 731 502 664 (confidence 0.99), the GST as $7.50, and passes all nine validators on the first attempt.
- 3Document
The best run becomes the record
The winning run's fields become the document you actually see — supplier, amounts, and a plain yes/no: is this a valid tax invoice? That verdict is what decides whether its GST can legally be claimed, and it's set by the validators, not by whether the total looked right at a glance. If a later model re-reads the same image and does better, a new run is added and the document quietly points at it — nothing about the old read is destroyed.
In this example"Ironbark Trade Supplies, $82.50, is_tax_invoice: true" — ready to become a transaction.
- 4Transaction
A balanced ledger entry is proposed
The document becomes a draft double-entry transaction — an expense split, a GST split, a payment-method split — with the right BAS label already attached. You review and post it, or it auto-posts if everything is high-confidence and clean. Once posted, it's locked: a later re-extraction can't silently rewrite a number that's already on your BAS. It raises a review task instead, and a human decides.
In this exampleMotor Vehicle expense +$75.00, GST Receivable +$7.50, Credit Card −$82.50, tax code GST (G11 · 1B).
Why build it this way
Why keep the original photo forever?
The ATO accepts an electronic copy only where it's a true and clear reproduction of the original. A recompressed or edited image isn't that. The original never changes; only a derived copy is used for reading.
Why is a "run" a separate thing from the document?
Extraction quality moves with the model, not with your data. Keeping runs versioned means a stronger model next year can re-read your entire history, and you can see exactly what changed and why — never a silent correction.
What happens when a validator fails?
It escalates to a stronger model first. If it still fails, the document is marked needs review with the specific check named — never posted as a guess.
Can a re-extraction change a number already on my BAS?
No. A posted transaction is locked. A better read of the same receipt raises a review task for a human to apply — it never rewrites a lodged figure on its own.