Build vs. buy: should your bookkeeping tool parse receipts with a raw LLM call?

Here’s the honest version of the pitch first: if all you need is vendor, date, and total off a receipt, you should probably build it yourself. A single vision-model call — GPT-4o-mini, Gemini Flash — with a “return JSON” prompt gets you most of the way there in an afternoon, for a fraction of a cent per image. We’d rather tell you that than sell you a service you don’t need.

The reason a service like ours exists isn’t the 80% that’s easy. It’s the 20% that quietly isn’t, and that only shows up in production.

Where a raw LLM call drifts

AU tax treatment isn’t optical — it’s rules. “Find the total” is an OCR problem. Deciding whether the GST on a $180 client dinner is claimable is a rules problem, and the receipt looks identical to an in-flight meal on a business trip that is claimable. A generic model will confidently guess. Ours tags each line item with a tax_code — taxable, gst_free, or entertainment_denied — plus a one-line rationale naming the actual rule it applied, so the guess becomes an auditable decision.

A wrong number and a smudged one look the same. Every ABN carries a modulus-89 checksum, so a misread is usually mathematically detectable — but only if something actually runs the check. A raw extraction prompt will hand back whatever it read. We validate the checksum and transcribe verbatim rather than silently “correcting” a number to something plausible.

Schema stability is a maintenance cost, not a prompt. The afternoon version works until you bump the model version and the JSON shape shifts under you — a field goes missing, an enum gains a value, a nested object flattens. Every downstream consumer of that JSON breaks quietly. Holding a stable, versioned contract across model upgrades is ongoing work that doesn’t show up in the demo and never stops.

An honest decision rule

• Build it yourself if you need generic fields (vendor, total, line items), your volume is low, and you can absorb the occasional schema surprise. The tooling is genuinely good now. Don’t pay for this.
• Use a service if tax-correctness has to be defensible, if a stable typed contract across model upgrades matters to code you don’t want to babysit, or if you’d rather not own an accuracy SLA and an uptime’d endpoint yourself.

That’s the whole tradeoff. It’s not “AI can’t do this” — it obviously can. It’s who maintains the last 20% once the afternoon prototype is carrying real invoices.

Try Receipt Extraction →

GST handling reflects publicly documented Australian tax law and is provided as software output, not tax advice.