Compare Zerodoc’s dedicated invoice extraction API with general-purpose large language models.
Often, yes — a model with a good prompt reads invoices well. The catches: when it cannot read a field it returns a plausible number rather than an error, nothing verifies the arithmetic, and your clients’ invoices become third-party API traffic that typically sits in provider logs for 30–55 days⁴. Zerodoc returns null with a warning, reconciles net + VAT against the total on every extraction, and processes documents in memory — never stored, never sent to a third party.
Why a specialized extraction API behaves differently from a general-purpose model on financial documents.
Zerodoc returns typed JSON with a guaranteed shape and a confidence score on every field, so there is no parsing layer between the API and your accounting system.
Our own model, trained on invoices rather than the open internet, working alongside OCR and extraction rules built for a single document family. Depth on UK and EU invoices instead of breadth across everything.
The same document returns the same fields on every request, and an unreadable value comes back as null with a warning rather than as a plausible guess.
How Zerodoc's specialized extraction compares with general-purpose large language models.
| Feature | LLMs | Zerodoc |
|---|---|---|
| Core Technology | ||
| Document SpecializationPurpose-built for document understanding and extraction | ||
| Structured Data OutputReturns a consistent, typed JSON shape without a parsing layer | ||
| Domain-Specific UnderstandingBuilt-in knowledge of invoice fields, VAT and totals | ||
| User Experience | ||
| No-code setupExtract documents in the dashboard without writing code | ||
| API-first designBuilt for developers with a clean, single-endpoint API | ||
| Deterministic ResultsThe same document returns the same output every time | ||
| Performance | ||
| Accuracy on DocumentsSpecialized accuracy on invoice fields and identifiers | ||
| Built-in ValidationNet plus VAT reconciled against the total on every extraction | ||
| Handling Complex LayoutsProcesses tables, line items and multi-page documents | ||
| Pricing | ||
| Transparent pricingRates published openly, with no sales call required | ||
| Predictable costs£19 for 2,000 pages — about £0.01 each, whatever the layout | ||
| Security | ||
| Data PrivacyDocuments never stored, retained in logs, or trained on | ||
A partial mark means it depends on the provider or the tier. Retention, residency and training policies vary between model providers and change over time⁴; verify the current terms of whichever provider you are comparing before relying on this for a DPIA.
One pipeline tells you it failed. The other returns a number that looks exactly like the right answer.
| Invoice number | INV-2026-0042 |
| Invoice date | 01/06/2026 |
| Due date | 30/06/2026 |
| Description | Qty | Rate | Amount |
|---|---|---|---|
| Consulting services | 10 | £100.00 | £1,000.00 |
| Subtotal | £1,000.00 |
| VAT (20%) | £200.00 |
| Total due | unreadable on this scan |
A real-world scan: the one field that matters is the one the toner missed.
"total_amount": null,
"extraction_warnings": [
"total_amount unreadable; net + VAT = 1200.00"
]Your pipeline routes it to a human. Cost: one review.
"total_amount": 1260.00Well-formed, plausible, wrong — and nothing flags it. Found at reconciliation, or after payment.
This is not hypothetical: research on multimodal models shows they fabricate rather than abstain when text is blurred or occluded¹, and misdirected authorised payments cost UK customers £576 million in 2025, with only around six in ten pounds reimbursed³. For a value that feeds a payment, refusing to guess is the feature.
If document text and your instructions share one prompt, the document gets a vote. Extraction into a fixed schema does not work that way.
| Invoice number | INV-2026-0042 |
| Invoice date | 01/06/2026 |
| Due date | 30/06/2026 |
| Description | Qty | Rate | Amount |
|---|---|---|---|
| Consulting services | 10 | £100.00 | £1,000.00 |
| Subtotal | £1,000.00 |
| VAT (20%) | £200.00 |
| Total due | £1,200.00 |
Tinted here so you can see it. In the wild it is white text, a footer note or a metadata field — it does not have to be visible to a human at all.
"bank_account": "GB29 NWBK 6016 1331 9268 19",
"total_amount": 1200.00The sentence is read as text on a page, not as an instruction. There is no tool to call and no address to send anything to.
"bank_account": "GB00 EVIL 0000 0000"Document text and your instructions share one prompt, so the model cannot reliably tell them apart — and if it has tools, the second sentence is the dangerous one.
Indirect prompt injection is the number one entry in the OWASP Top 10 for LLM applications, and CVE-2025-32711 was a zero-click, document-borne exfiltration in a major production assistant². Zerodoc has no tool to call and no outbound path to call it with, so the worst an injected line can do is get extracted as text and fail validation.
Adding document extraction to your application takes a single request. The API is designed so that the response is ready to use, rather than ready to parse.
// Extract structured data from an invoice
const form = new FormData();
form.append("file", invoiceFile);
const res = await fetch("https://api.zerodoc.io/v1/extract", {
method: "POST",
headers: { "X-API-Key": "zk_your_api_key" },
body: form,
});
// Consistent, typed JSON on every request
const { fields, retention } = await res.json();
console.log("Supplier:", fields.supplier.value);
console.log("Total:", fields.total.value);
console.log("Confidence:", fields.total.confidence);// Using a general-purpose model for document processing
const pages = await renderPdfToImages(invoiceFile);
const res = await llmClient.complete({
prompt: `Extract the supplier, total amount and due date
from this invoice. Return JSON.`,
images: pages,
max_tokens: 500,
});
// Still needs parsing, validation and a fallback path
const parsed = parseAndValidate(res.text);
// The same document can return a different value
return parsed;
// TODO: check privacy policyFor document types you cannot predict, a general model may be a better tool for you. For invoices that feed payments, this is the trade Zerodoc makes instead.
Zerodoc returns the same fields from the same document on every request. There is no sampling and no serving-stack change that quietly shifts an output you already tested against.
Fixed pricing per page rather than per token, so a month of mixed layouts costs what you budgeted for it instead of what the densest scans happened to tokenize to.
Consistent field names and a guaranteed response shape mean no prompt to maintain and no defensive parser sitting between the API and your systems.
Documents are processed in memory on EU infrastructure and gone the moment we respond. Nothing is retained, nothing is trained on, and no model provider joins your sub-processor list.
retention: { stored: false } so you can assert it programmatically.Start free with 200 pages every month. No credit card, and nothing you upload is ever stored.
Zero retention on every plan · EU processing · Affordable pricing