dots.ocr Alternatives for Production Invoice and Table Extraction

If you are looking for a dots.ocr alternative for invoices and tables, the short list is four names long: dots.mocr, PaddleOCR-VL, MinerU and Docling. dots.mocr is the same team's successor and beats dots.ocr on seven of eight benchmark columns. PaddleOCR-VL is the only one of the group that runs on a $0.5260 an hour Tesla T4. MinerU has the highest table score anyone has measured. Docling is the cheapest to operate because it does not need a GPU at all. Which one is right depends almost entirely on what GPU you are willing to pay for and whether you need a hosted endpoint rather than a model.

Everything below is checked against the projects' own repositories and model cards, plus live AWS on-demand rates pulled on September 1, 2026. Where a number is derived rather than published, the arithmetic is shown.

Why would you look for a dots.ocr alternative at all?

Three reasons come up repeatedly, and only one of them is about accuracy.

The first is that the project was renamed. The dots.ocr News entry states that on March 19, 2026 the team "rebranded dots.ocr-1.5 as dots.mocr", and both of its homes moved with it: the GitHub repository from rednote-hilab to studio-dots-ai, and the HuggingFace organization from rednote-hilab to dots-studio. Nothing is broken, the old paths redirect, and no end of life has been announced. But the original checkpoint was last modified on October 31, 2025 and the repository's last code push was March 24, 2026, so a team that installs "dots.ocr" today from an older tutorial is installing something that has been quiet for a while. Full detail on that move, including how it was verified, is on our dots.ocr reference page.

The second is hardware, and it is the one that actually blocks projects. The dots.ocr config pins its vision tower to FlashAttention-2 and sets the checkpoint dtype to bfloat16. Both require an Ampere-generation NVIDIA GPU or newer. A 16 GB Tesla T4 has more than enough memory for a model whose weights are 5.66 GiB, and it still cannot run it, because Turing supports neither. That single line in a config file rules out the cheapest GPU instance on AWS.

The third is that there is no official hosted dots.ocr API. The project publishes weights and vLLM instructions. If you need an endpoint with a key rather than a service to operate, dots.ocr is not a candidate no matter how well it reads a page.

Which dots.ocr alternative is best for invoices and tables?

Sort on the table column, not the composite score. This is the mistake that sends teams to the wrong model. Every public document benchmark reports an overall figure that averages plain text accuracy, table structure and formula recognition into one number, and almost nobody buys a document parser to read prose. On the dots team's own olmOCR-Bench table, dots.ocr ranks sixth of eleven on the composite at 79.1 and second of eleven on tables at 88.3. Those are the same model on the same test.

Two cautions about reading that table. The table scores come from two different benchmarks and are not directly comparable across the boundary: olmOCR-Bench scores and OmniDocBench TEDS scores measure related but different things, so compare within a column rather than across. And the olmOCR-Bench figures for the two dots models are the team's own published numbers rather than an independent result. They are still worth having, not least because they show dots.ocr losing on the composite to four other systems, but treat them as a hypothesis to test rather than a verdict.

Is dots.mocr a drop-in replacement for dots.ocr?

Effectively yes, and it is the first thing to try. Both checkpoints report exactly 3,039,179,264 parameters, both are MIT licensed, both load through the same vLLM command with only the model path changed, and both have the same hardware floor. On the team's own benchmark the successor wins seven of eight columns. The one column where the original is ahead is headers and footers, by a tenth of a point. The gaps that matter for finance documents are tables, 90.7 against 88.3, and old scans with mathematics, 85.5 against 64.2.

The successor also does something the original never did, which is parse charts, diagrams and logos into SVG code rather than describing them. The team is candid that a 3 billion parameter model is not excellent at this yet, and ships a separate dots.mocr-svg checkpoint for teams who need it specifically. If your documents are invoices and statements rather than research papers, that capability is unlikely to change your decision either way.

What is the cheapest dots.ocr alternative to run?

PaddleOCR-VL, and the gap is larger than the model sizes suggest. Because it runs happily on a Tesla T4, you can serve it from a g4dn.xlarge at $0.5260 an hour. dots.ocr and dots.mocr need an Ampere or newer card, and the cheapest AWS instance that clears that bar with 24 GB of VRAM is a g6.xlarge with an NVIDIA L4 at $0.8048 an hour. Run either around the clock and the difference is $383.98 a month against $587.50, so $203.52 a month per inference box for a model that also scores higher on the independent board.

Worth knowing if you do stay on the dots family: most deployment write-ups reach for a g5.2xlarge at $1.2120 an hour, because the A10G was the obvious 24 GB Ampere card when the model launched in 2025. The newer L4 gives you the same 24 GB, clears the same requirement and costs $297.26 a month less. That is $14,268 a year across four boxes for changing one character in an instance type.

Docling is cheaper still, at roughly $0.21 per 1,000 pages, because it is built to run on CPU. It is the right answer when you have no GPU budget at all and your documents are reasonably clean, and the wrong answer when you need the accuracy of a modern vision language model on scanned pages. We break the arithmetic down per model on our self-hosted OCR cost page.

Is there a hosted alternative if you do not want to run a GPU?

Yes, and this is where the comparison stops being about models. MinerU operates a hosted API at mineru.net with a documented free daily quota, though a US team should read our note on it first: the create-task endpoint takes a URL rather than a file upload, and MinerU's own documentation states that foreign URLs such as GitHub and AWS will time out, which is a real problem if your documents live in an S3 bucket. Mistral OCR is a straightforward commercial endpoint with a published per-page rate. AWS Textract, Azure Document Intelligence and Google Document AI are the enterprise defaults, though none of the three publishes an accuracy figure or appears on any public leaderboard, which we verified two independent ways on our OCR accuracy comparison.

Before you pick a hosted endpoint on price alone, check what the rate actually covers. Asking for tables is a different and more expensive meter than asking for text on both hyperscalers: $1.50 per 1,000 pages becomes $15.00 on AWS Textract and $10.00 on Azure Layout. The full set of normalized rates is on OCR pricing per 1,000 pages.

What none of these alternatives give you

Every model above returns a parsed page. None of them returns a checked invoice. That distinction is where most evaluations go wrong, because a benchmark measures how faithfully a grid was transcribed and an accounts payable team measures whether the line items add up to the total on the face of the document.

Concretely, here is what you still have to build after the parser works. A classifier, because a mailbox contains invoices, remittances, statements and the occasional contract. Field mapping, because a parsed table is rows and columns and your system wants a vendor, an invoice number, a date, a tax amount and a set of line items. Validation rules, because the parser will occasionally give you a grid that does not reconcile and the only way to catch that is arithmetic you wrote. A review queue, because somebody has to look at the ones that fail. And an export, because the point of the exercise is to route approved invoices into an accounts payable workflow rather than to admire some JSON.

That is not an argument against self-hosting. If you have a GPU, an engineer who wants to own an inference service, and what you need is a clean parsed page, self-host one of these models and do not let anybody sell you out of that decision. dots.ocr in particular has the cleanest licence in the category, plain MIT with no revenue threshold, which is better than Marker's free-below-$5M-revenue terms and better than MinerU's commercial licence above $20 million in monthly revenue. It is an argument for being honest about where the project actually ends, because the parser is usually the smallest part of it.

How to choose in one pass

Take twenty of your own documents, including the three worst ones, and run them through the two or three candidates that clear your hardware constraint. Score them on the fields you actually need rather than on a composite. Time the run so you have a real pages-per-hour figure, because that is the only input that turns an hourly GPU rate into a cost per page, and no open project publishes it for you. Then compare that number against the managed rate you would otherwise pay. Against a $1.50 per 1,000 pages API, a $0.8048 an hour box has to sustain 537 pages every hour before it is cheaper, which is 391,669 pages a month with the card never idle. Most teams evaluating an open parser are a long way below that, which means the honest reason to self-host is usually data residency or control rather than a smaller bill.