BV-OCR: inside the document-reading engine

Reading documents at operational scale is two problems wearing one coat. The first is throughput: a real operation does not process a PDF, it processes thousands —invoices, forms, scanned mail— and every second per page multiplies across the whole archive. The second is trust: it does not matter how fast you read if nobody can prove where each value came from. A reading engine that solves only the first produces errors faster; one that solves only the second never reaches production.

BV-OCR is BiVelio's document-reading engine: the stack that feeds the Documents module and sits underneath the pipeline we described in From documents to governed data. That article covers what Documents does; this one covers how it reads. The short answer: three coordinated pieces, with a gate between the last two that is what turns "model output" into "evidenced data".

The architecture, in three pieces

BV-OCR deliberately separates three jobs that other systems collapse into one:

1. Deterministic GPU parsing —BiVelio's own document parser, written in C++ on CUDA and TensorRT— turns each page into verbatim text with coordinates, layout structure, tables and formulas. Fast, local and reproducible: the same page yields the same text.
2. Understanding with a compact vision-language model, served with NVIDIA-optimized inference, which proposes field-level interpretations on top of that text: which of the amounts is the total, which of the dates is the due date.
3. The value-in-OCR gate, the engine's central rule: every value the model proposes must be traceable to a span of the text the OCR recognized. Whatever cannot be anchored is rejected and goes to human review.

Why the split? Because each piece is good at exactly what the other cannot do. The deterministic parser delivers speed and verbatim text with coordinates —the physical anchor of all later evidence— but has no idea what any line means. The model understands, but it generates: nothing in a generative model guarantees that a value came from the document rather than from its imagination. The gate joins the two halves: the model may propose anything, but only what exists in the recognized text may enter the operation.

The fashionable alternative —a pure-VLM parser that looks at the page and writes the structured output directly— collapses those three functions into one generative pass. It is simpler, and on the hardest layouts it is even more accurate (numbers below). But it pays two prices BiVelio finds unacceptable: it is orders of magnitude slower per page, and it leaves no verbatim anchor: the text it emits is generated, not recognized, so there is no snippet of the original against which to verify a value short of re-reading the whole document.

Deterministic GPU parsing

The first piece is BV-OCR's document parser, built in-house at BiVelio and written in C++ on CUDA and TensorRT. It is not "OCR with extras": it is a full parsing pipeline on a single multi-stream GPU engine, running locally —no VLM anywhere in the loop— and served over HTTP and gRPC. Like all of BiVelio's research, it runs on NVIDIA inference and hardware.

The stages, in order:

• Text detection and recognition: where the text is on the page and what it says, line by line, with a coordinate box and a confidence per line.
• Layout analysis: which regions are paragraph, heading, table, figure, formula.
• Tables → HTML: cell structure is preserved rather than flattened into running text.
• Formulas → LaTeX.
• Reading-order Markdown: everything above, assembled in the order a human would read the page.

That last step matters more than it looks. Reading-order Markdown is what the second piece consumes: a faithful, ordered textual document, with tables as tables and formulas as formulas — and where every line remains traceable to its region of the original. Without it, the model would receive an unordered soup of fragments, and "the amount that follows the Total label" would stop meaning anything.

The benchmark numbers

The figures that follow come from BV-OCR's own reproducible benchmark harness, measured over public datasets on a single NVIDIA GPU (RTX 5090):

• Throughput: up to 559 images/s on receipts, 520 on forms and 200+ on dense documents, on the fastest tier (the default).
• Accuracy on forms and receipts: 92% word-F1 on FUNSD and 93% on CORD on the higher-accuracy tier.
• Full structured parsing (layout + tables + formulas): ~20 pages/s with a 0.90 Overall score on a 125-document OmniDocBench subset (English + Chinese). On that subset, BV-OCR lands about 5 points behind the best reference pure-VLM parser; purely VLM-based document parsers run at around ~1 page/s.

That last comparison is the honest contrast we promised: on the hardest layouts, the best pure-VLM parser is ~5 points better. In exchange, the deterministic parser is ~20× faster and, above all, produces recognized text, not generated text — the raw material without which the value-in-OCR gate could not exist.

Tiers and hardware

BV-OCR ships three tiers that trade speed for accuracy without changing language coverage: from the fastest —the default, behind the throughput figures— to the higher-accuracy tier behind the FUNSD and CORD figures. All three cover Latin script, Chinese and Japanese; Arabic, Cyrillic, Korean, Thai and Greek are covered by additional recognition packs.

On hardware, BV-OCR is designed and optimized for NVIDIA GPUs: it runs on Linux with an NVIDIA GPU (Turing or newer), with ~4 GB of VRAM for text-only and ~8 GB for the full pipeline.

Understanding with a compact vision-language model

Verbatim text is not enough. A perfectly recognized invoice still does not tell you which of its seven amounts is the total, or which of its three dates is the due date. That is the job of the second piece: a compact vision-language model with native image and document understanding, served with NVIDIA-optimized inference.

Its role in BV-OCR is deliberately narrow: it proposes field-level interpretations over what the deterministic parser already recognized. "The invoice total is €1,240.00 — the one next to the Total label." "The due date is 2026-09-30, the one on the Payment due line." It proposes; it does not transcribe. The document's OCR is already done, and done by a deterministic component.

Two things the model does not do in BV-OCR:

• It does not replace the OCR. The text it works over —and against which every proposal will be verified— is the deterministic parser's, not a transcription of its own.
• It does not decide. Its proposals do not enter the operation on their own: each must pass the value-in-OCR gate, and doubtful ones end up in front of a person.

One capability is exploited directly: adjustable reasoning depth. Easy fields —a clear label with a value beside it— need no chain of thought; hard ones —two candidate totals, an ambiguous table— justify spending extra compute on reasoning before proposing. A compact model with adjustable effort lets you pay for reasoning only where it is needed.

The value-in-OCR gate

The third piece is the reason the other two exist. The rule fits in one sentence: every value the model proposes must be traceable to a span of the text the deterministic parser recognized.

In practice, every proposal that clears the gate leaves with an evidence locator: the region of the original and the snippet of recognized text the value came from. That is exactly what the Documents module attaches to every extracted field — the pointable fact a reviewer checks in seconds.

And when no anchor exists? When the model proposes a value that does not appear in the recognized text —because it hallucinated it, because it "corrected" it, because it derived it from a calculation— the gate rejects it. The field is neither silently dropped nor accepted with an asterisk: it is routed to the human review console, with the document in front of the reviewer, for a person to decide. A model cannot invent a value and have the system accept it; the most an invented value ever earns is an appointment with a reviewer.

Note what the gate is not: it is not a confidence threshold. A threshold filters by how sure the model says it is; the gate filters by what the document says. A hallucinated value with 0.99 confidence passes a threshold and fails the gate. That is the thesis of From documents to governed data —evidence beats bare confidence— landed in the concrete mechanism that enforces it.

What we measure — and what we don't

An honest technical article has to separate three kinds of claims:

• The figures come from our own harness, over public datasets. This article's throughput and accuracy numbers (559 img/s, FUNSD 92% / CORD 93%, 0.90 on the OmniDocBench subset) are measured with BV-OCR's reproducible benchmark harness over public datasets, on a single NVIDIA GPU (RTX 5090). A public dataset is not a promise about your documents: an academic receipts dataset is not your archive of scanned contracts.
• BiVelio publishes no accuracy percentages on customer documents. Accuracy on your documents depends on your corpus, and is validated in your own review flow. The guarantee we do offer is structural rather than statistical: no value enters without evidence, and anything doubtful ends up in front of a person.
• BV-OCR is designed and optimized for NVIDIA GPUs. The engine is written in C++ on CUDA and TensorRT, and all of our research runs on NVIDIA inference and hardware.

Where BV-OCR fits

BV-OCR is not a product you buy on its own: it is the engine underneath the Documents module. The full map:

• The deterministic parser reads every ingested document: verbatim text with coordinates, layout, tables, formulas, reading-order Markdown.
• The vision-language model proposes the fields the operation needs, with reasoning depth tuned to how hard each one is.
• The value-in-OCR gate anchors every proposal to the recognized text and emits the evidence locator that travels with the data.
• Rejected and doubtful fields queue in the human review console — the design principle we develop in Human-in-the-loop: 5 components, not an approval button— and corrections flow back into the case.
• Validated data feeds governed cases and workflows: permissions, an audit trail, human gates on critical steps.

The data's full journey —from ingestion to the case— is in From documents to governed data; this article is the engine room of its first half.

FAQ

Is BV-OCR a separate product from the Documents module?

No. BV-OCR is the name of the reading engine that feeds the Documents module: the layer that turns a document into anchored text and evidenced field proposals. Documents adds preservation and versioning of the original, the review console and governed automation on top.

Why not just use a vision-language model for everything?

Because a pure-VLM parser generates the text instead of recognizing it: it leaves no verbatim snippet of the original against which to verify a value, and it is far slower per page (purely VLM-based document parsers run at around ~1 page/s, versus ~20 on the cited OmniDocBench subset). It is more accurate on the hardest layouts —BV-OCR lands about 5 points behind the best reference pure-VLM parser on that subset— and we say so plainly: BV-OCR gives up those points in exchange for throughput and, above all, anchorable evidence.

What happens if the model hallucinates a value?

It does not get in. The value-in-OCR gate requires every proposed value to be traceable to a span of the text the deterministic parser recognized; a value that does not appear in that text is rejected and the field is routed to the human review console. The hallucination does not become data: it becomes a review task.

Are the speed and accuracy figures BiVelio's?

Yes. They are measured with BV-OCR's own reproducible benchmark harness over public datasets (FUNSD, CORD and an OmniDocBench subset), on a single NVIDIA GPU. What BiVelio does not publish are accuracy percentages on customer documents: accuracy on your corpus is validated in your own review flow, and the guarantee the system offers is structural (mandatory evidence + human review), not a number.

What hardware does the engine run on?

BV-OCR is designed and optimized for NVIDIA GPUs: it runs on Linux with an NVIDIA GPU (Turing or newer), with ~4 GB of VRAM for text-only and ~8 GB for the full pipeline.