For developers

Receipt Extraction — structured JSON from receipts and invoices, AU GST-aware

For developers building bookkeeping, expense, or agentic-commerce tools. Stop hand-rolling vision-LLM prompts and ABN/GST validation logic. One API call turns a receipt or invoice image/PDF into clean, versioned JSON — vendor, line items, tax, totals — with Australian GST and ABN checksum validation built in from day one.

Request
{
  "tool": "extract_receipt",
  "input": { "document_base64": "<base64 image or PDF>", "mime_type": "image/jpeg" }
}
Response
{
  "vendor": { "name": "Acme Pty Ltd", "abn": "51 824 753 556", "abn_valid": true },
  "date": "2026-07-14",
  "line_items": [{ "description": "Widget", "qty": 2, "unit_price": 12.50, "gst": 2.50, "tax_code": "taxable" }],
  "totals": { "subtotal": 25.00, "gst": 2.50, "total": 27.50 },
  "schema_version": "1.0"
}

01Why this exists

Generic OCR extraction APIs get you raw fields. None of them know that an Australian ABN carries an 11-digit modulus-89 checksum, or that GST apportionment differs for entertainment-coded expenses. You'd build and maintain that yourself, on top of someone else's schema that can change under you. We maintain the versioned schema and the AU-specific validation — so you don't have to re-derive it from the ATO's own documentation every time a client complains about a rejected ABN.

02Pricing

Free
$0
20 documents/month
No card. The trial that proves the AU-GST fields work before anyone pays.
Pay-as-you-go
$0.02/document
No minimum
Effective $0.02/doc
For spiky/low-volume callers — the "just let me try it on real traffic" tier.
How this is priced: the free tier competes on usefulness, not on volume — AU GST/ABN validation is on from document 1, so 20 documents is enough to prove the fields you actually came for. Racing to the bottom on per-page rate isn't the moat.
Against per-page plans: services that meter by page tend to price small monthly bundles, where the effective per-document cost stays high as you scale. Pro at ~$0.0127/doc is the opposite curve — the more you send, the less each document costs.
Built to stay this way: both paid tiers are priced to be sustainable at the volumes they describe, so the rate you sign up on isn't a promotional number that has to be re-cut later.

Want Pro?

Leave your email — we'll onboard you within a day. This page takes no card details and starts no subscription; it records that you want the paid tier so we can set it up with you.

We use the address only to contact you about paid access. Prefer to try first? The free tier below needs no email form at all.

03How it compares

Turn receipts and invoices into structured, validated JSON — vendor, line items, tax, totals, with AU GST/ABN awareness built in. Caller-supplied documents, provider-swap vision LLM under the hood. The alternatives below are described by category, not by brand: what matters when you're choosing is the shape of the thing — how it's called, what it returns, and what it leaves you to build — and that's a property of the category, not of any one vendor.

Alternative Why you might still need Receipt Extraction
Generic OCR extraction APIs Return raw fields and generic totals. None of them apply the Australian layer: no ABN modulus-89 checksum validation, no GST-rate or entertainment/ITC apportionment logic, no per-line tax_code with the rule that produced it. That layer is yours to build and keep current, on top of a schema that can change under you.
Inbox-scanning bookkeeping assistants A genuinely different job. You connect a mailbox (and sometimes a messaging account); they collect receipts into their own workspace on an ongoing basis, and their integrations query that already-populated workspace behind an account login. There is no "here is one document, return structured JSON on this call" entry point — which is exactly what a pipeline receiving an upload, attachment, or scan needs.
Tax-generic receipt/invoice MCP servers Extract merchant, date, line items, tax and totals, and the better ones suggest a GL account for bookkeeping automation. Useful, but tax-generic: no AU GST-rate or ITC-apportionment logic and no ABN checksum validation in the tool set. A journal-entry suggestion is not an AU tax_code plus the rule and confidence behind it.
Per-page and pay-per-call extraction services Metered by page, by event, or by an on-chain payment per call. The billing model varies; the extraction doesn't — the field set stays locale-neutral (generic VAT / tax_deductible-style flags), with no ABN checksum and no GST apportionment. Page-based monthly plans also get expensive per document once volume is real.
Marketplace-hosted extraction actors Vision-model extraction of invoice number, line items, tax and vendor, billed per event through a marketplace that sits between you and the call — its account, its billing, its runtime. Same locale-neutral field set, plus a hosting layer you don't control.
DIY with a raw vision LLM You own the prompt and every regression in it: no versioned response schema, no maintained AU GST/ABN rule set, and no checksum validation unless you write it. Cheap to start, and the thing that breaks quietly when a rule or a document format changes.

This page compares real alternative categories on their real limitations, including the free ones — a comparison that hides the free option isn't worth reading. No vendor is named here; the differences that matter are structural. Try it or browse the source.

04Get a key

Free tier — 20 documents/month, no card required. Keys are self-serve and shown once.

1. Sign up
curl -X POST https://receipt-extraction.acjlabs.com/v1/signup \
  -H "content-type: application/json" \
  -d '{"email":"YOUR_EMAIL"}'

Your API key comes back directly in the response — store it immediately, it can't be recovered if lost (re-run the signup for a new one).

2. Connect it to an MCP client
claude mcp add --transport http receipt-extraction \
  https://receipt-extraction.acjlabs.com/mcp \
  --header "Authorization: Bearer YOUR_API_KEY"