AI invoice OCR on your own server: MiniCPM-OCR 1.0

MiniCPM-OCR 1.0 is a small, free model from OpenBMB that reads scanned and photographed documents and turns them into text, tables or JSON fields. It runs on your own hardware, and it ships with a second model that scores how likely each piece of the output is correct. That second part is what makes it useful for invoice and form processing in a business.

This post covers what the model does, how we would use it to get invoices and forms into your systems, and when a simpler tool is the better choice.

We read the MiniCPM-OCR 1.0 model page, the MiniCPM-OCR Jev model page and the project's GitHub repository on October 28, 2026. The facts below come from those pages.

• Size and license. MiniCPM-OCR 1.0 has 1.3 billion parameters. The weights, code and docs are under the Apache 2.0 license, which allows commercial use.
• What it reads. Text, tables, formulas, charts and stamps or seals. It handles scans, photos, curved and skewed pages and documents photographed off a screen. Chinese and English are its primary languages.
• What it outputs. Plain text and Markdown for whole pages, HTML for tables, and JSON for fields you name. For field extraction you list the fields you want, and it fills in "###" for anything not on the page.
• How it runs. It works with vLLM, SGLang, llama.cpp and Ollama, and there are smaller quantized versions. OpenBMB also offers an online demo and an API, but those send your documents to their servers.
• Speed. OpenBMB reports 1.2 pages per second on an NVIDIA RTX 5090 in their own test. Your speed will depend on your hardware and documents.
• Benchmarks. OpenBMB reports a top score of 93.68 on Real5-OmniDocBench, a test set of real-world document photos and scans. These are the vendor's numbers, so test on your own documents before you rely on them.

The companion model, MiniCPM-OCR Jev, has 2 billion parameters. You give it a cropped region of the page and the text the OCR model read from it. It returns a score from 0 to 1. A higher score means the text is more likely correct.

OpenBMB suggests picking a threshold using samples from your own documents. Regions above the threshold go through automatically. The rest go to a person. It works on output from other OCR models too, so you can run two readers and keep the higher-scoring result.

One detail from the docs is easy to miss. When the service fails to render or check a region, it returns a fixed value with a verdict field. Only a verdict of "scored" means the model actually ran. If your code treats every number as a real score, a failure could look like a low-confidence read, or the other way around.

This is the piece most invoice OCR setups lack. Without a score, you either review every invoice or trust every invoice. With a score per field, a person only looks at the ones the model is unsure about.

Any business that types data off paper or PDFs into another system:

• Accounting firms and bookkeepers entering vendor bills and receipts.
• Freight and logistics teams reading delivery notes, bills of lading and customs papers.
• Clinics reading intake forms and insurance cards, where sending images to an outside service needs extra review. Our post on vetting AI tools for HIPAA covers that side.
• Property managers reading leases and maintenance invoices.

Running it on your own server means the documents do not leave your network. For many clients, that is the reason to consider it over a cloud OCR service.

Here is how we would set up invoice intake around MiniCPM-OCR for a team that gets a few hundred bills a month.

1. 1One intake point. Bills arrive by email, upload or a shared folder. A small service collects them into one queue and gives each file an ID.
2. 2Parse and extract. MiniCPM-OCR reads each page and pulls the fields you need: vendor name, invoice number, date, due date, line items, tax and total.
3. 3Score each field. Jev scores the regions those fields came from. Anything below your threshold is marked for review.
4. 4Run plain checks. Code checks that line items add up to the total, the vendor exists in your accounting system, the invoice number is not a duplicate and the due date is after the invoice date. These catch errors a confidence score cannot.
5. 5Send clean ones through. Bills that pass every check and score above the threshold go into QuickBooks or Xero as drafts through the API, with the original file attached.
6. 6Route the rest. Low-score or failed-check bills go to a review screen that shows the page image next to the extracted fields, with the unsure fields highlighted.
7. 7Learn from corrections. Every correction is logged. After a month, the team can see which vendors and fields cause the most review and adjust the threshold.

This is the same goal as the screen-driving approach we compared in our post on GPT-6.1 Terra for invoice entry. Reading the document and posting through an API is usually cheaper and easier to check than having an agent click through accounting software.

• Low volume. If you process a few dozen bills a month, the bill capture built into QuickBooks or Xero, or a paid OCR service, will cost less than setting up and maintaining a server.
• No one to run it. Self-hosting means updates, monitoring and a graphics card. The project's FAQ says the two software environments plus the model need at least 20 GB of disk. Our self-hosted AI deployment checklist lists what else to plan for.
• Other languages. The model's primary languages are Chinese and English. If most of your documents are in other languages, test carefully first.
• Your vendors can send data directly. If your main suppliers can send invoices through e-invoicing or an API, reading PDFs is the wrong problem to solve.
• No tolerance for any error. OCR plus a score reduces review. It does not remove it. Totals that feed payments still need checks and an approval step.

Pull 50 real documents from last month, including the messy ones. Run them through the online demo only if they hold no sensitive data, or through a local test setup if they do. Compare the extracted fields with what your team entered by hand, and note which fields the score flagged.

That test tells you whether the model reads your documents well enough and how much review you would still need. If you want us to run that test and map the rest of the workflow, book a free automation audit. We build this kind of intake as part of our workflow automation and systems integration work. For accounting teams, our post on accounting firm workflow automation shows where invoice intake fits in the bigger picture.