Why LLMs Cannot Scale for Receipt OCR

LLMs work for low-volume, exploratory receipt scanning. At production scale, the economics collapse, the infrastructure buckles, and hallucinated fields become a compliance risk. Here is why the architecture matters.

Receipt OCR sounds like a natural fit for a large language model. You pass in an image, ask for the merchant name, the date, and each line item, and the model writes back something that looks like structured data. For a proof of concept or an internal tool processing a few dozen receipts a week, that works well enough. The problem appears at scale, and it is not a tuning problem. It is an architectural one.

The cost problem compounds with every receipt

Every call to a generalist LLM is priced on tokens: image tokens for the encoded receipt, prompt tokens for the extraction instruction, and completion tokens for the output. A single receipt image can consume several hundred to several thousand tokens depending on the model and the encoding method, before the model has written a single character of output.

At low volume that overhead is invisible. At 100,000 receipts per month, a figure well within the range of a mid-size loyalty programme or expense management platform, the token bill becomes the dominant infrastructure cost. Published pricing for frontier vision LLMs sits in the range of a few dollars per million tokens on the input side and more on the output side. A receipt with a dozen line items can easily consume 2,000 to 4,000 tokens per call. At 3,000 tokens average and 100,000 receipts, that is 300 million input tokens per month, before factoring output.

A purpose-built receipt OCR model is not reasoning over tokens. It runs a lightweight specialised inference pass on a fixed-size image representation, producing typed fields from a trained extraction head. The compute per call is a fraction of what a large transformer requires, and because the model is not general-purpose, no token budget is wasted on open-ended generation. The economics diverge sharply above roughly 10,000 receipts per month and the gap only widens from there.

The infrastructure was not built for concurrent structured extraction

A large language model is a stateful transformer inference engine. Each call loads model weights, manages attention across a long context window, and generates output autoregressively, one token at a time. That architecture is well-suited to sequential reasoning tasks. It is not well-suited to thousands of concurrent, short-duration, structured-extraction jobs.

At high concurrency, LLM APIs exhibit predictable pathologies: rate limits per minute and per day, throttling under sustained load, and latency spikes that are not bounded or predictable the way a queued OCR workload is. These limits exist because the underlying infrastructure is shared, stateful, and expensive to scale horizontally. A burst of 500 concurrent receipt uploads, a normal condition for a loyalty campaign redemption event or month-end expense close, will hit those ceilings and begin queuing or dropping calls.

Tabscanner is architected around this workload specifically. The API uses an asynchronous submit-and-poll pattern: you POST an image, receive a token immediately, and poll the result endpoint. Underneath, a dedicated autoscaling queue manages concurrency across lightweight specialised models optimised for receipt extraction. The system scales compute to the receipt OCR task, not to the cost structure of a general-purpose inference cluster. That is a structural difference. Prompt engineering cannot change what the underlying infrastructure was built to handle.

Hallucination is not an accuracy problem, it is a compliance problem

A generalist LLM is trained to produce plausible text. When the model encounters a thermal receipt with faded ink, a truncated line item, or a locale-specific date format it has not seen clearly, it fills the gap with what seems reasonable. That behaviour is useful in a conversational context. In a structured-extraction context, it is a quiet failure mode: the model returns a value that looks correct but was generated rather than read.

For expense management, the fabricated total that passes straight into an ERP is the problem, not the one that flags for review. For a loyalty programme, a hallucinated product name that matches a reward threshold is a direct financial loss. For fintech use cases operating under audit requirements, a line item that does not appear on the original receipt is a compliance event. There is no way to distinguish a hallucinated field from a correctly extracted one in the output of a generalist LLM without ground-truth verification of every record.

Tabscanner returns a confidence score with every extracted field. A field the model read clearly carries a high score. A field that is ambiguous, partially occluded or formatted unusually carries a lower one. That score is the operational lever: high-confidence fields flow through automatically; low-confidence records route to a brief human review. The system is deterministic in its output format and honest about uncertainty rather than resolving it with a plausible guess.

Domain training on global receipt formats is not something LLMs replicate

Receipts are a specific and demanding document class. Thermal print fades, smears and loses contrast in unpredictable ways. Line items are truncated when they exceed the printer's character width. Tax labels, currency symbols and date formats vary by country, region and even individual merchant configuration. A receipt from a Japanese convenience store, a UK supermarket self-checkout and a US fast-casual restaurant share almost no layout conventions.

Tabscanner's models are trained on a large corpus of real-world receipt images spanning these global formats, including the specific artifacts that thermal printing introduces. That training is the source of the model's extraction accuracy on difficult inputs: not general visual reasoning, but pattern recognition built from thousands of examples of exactly the document class it is asked to read.

A generalist LLM has broad visual understanding but no equivalent domain-specific training on this corpus. It will perform reasonably on a clear, well-lit receipt from a common merchant. It will degrade on the harder cases, the faded ink, the unusual layout, the locale-specific formatting, precisely the cases where a production pipeline cannot afford errors and where a confidence score rather than a plausible hallucination is the only safe response.

The right tool for each stage of the project

None of this is an argument against LLMs. For early-stage exploration, prototyping a receipt-parsing concept, or processing a small internal dataset, an LLM is a reasonable starting point. You get a working extraction pipeline with minimal setup, and at low volume the cost and reliability limitations are manageable.

The inflection point is production. When volume crosses into the tens of thousands of receipts per month, when a loyalty campaign launches and redemption events spike concurrency, when an audit requires every extracted field to have a traceable confidence and a reliable null rather than a generated guess, the architectural fit of a generalist LLM runs out. Prompt engineering can improve output format and reduce obvious errors. It cannot change the token economics, the infrastructure ceiling or the model's tendency to generate rather than abstain.

Tabscanner is a receipt OCR API that turns photos and scans of receipts into structured, line-item data, for expense management, loyalty and market research. The API is live, purpose-built for this workload, and designed to handle high-volume concurrent extraction at a cost structure and reliability level that production pipelines require.

A hallucinated line item in an expense report is not an accuracy metric. It is a compliance event. Confidence scores are the only safe substitute for certainty.