MinerU Alternative for Bank Statements: MinerU API, PDF Output and Excel Export

Last updated September 2026.

MinerU is one of the most capable open-source document parsers available, and if you are evaluating it to turn bank statements into spreadsheets, the short answer is that it will read the statement beautifully and then hand you Markdown. There is no XLSX writer and no CSV writer anywhere in the project. Tables come out as HTML embedded in that Markdown, which preserves the grid, but the step from there to a reconciled register with signed amounts and a running balance is code you write and maintain.

What MinerU actually is

MinerU comes out of OpenDataLab and describes itself as transforming complex documents like PDFs and Office files into LLM-ready Markdown and JSON for agentic workflows. That description is accurate and it is worth taking literally. The destination is a language model, not an accountant.

The project is large and genuinely alive. It carries close to 79,000 GitHub stars, it was created in February 2024, and the repository had commits the day this page was written. Release 3.4.5 landed on 14 August 2026 with fixes for Word tables being silently dropped when cells contained special characters, and for surrogate pair handling in PDF text extraction. That is the profile of a maintained project, not an abandoned one.

The MinerU license is not plain Apache 2.0

This is the part most comparisons miss, and it is the reason GitHub displays no recognized license for the repository. MinerU ships under the Apache License 2.0 plus additional terms, and those terms carry real obligations.

Two of them matter. First, there are commercial thresholds: if you and your affiliates on a consolidated basis exceed 100 million monthly active users, or exceed 20 million US dollars in total monthly revenue, you must obtain a separate commercial license before continuing to use it. For almost every accounting practice and finance team that threshold is irrelevant, and it is fair to say so.

The second obligation is the one that actually bites. If you provide online services to third parties based on MinerU, you must clearly and prominently indicate, in the product interface or in public documentation, that MinerU is used. Failing either obligation terminates the license automatically, with no notice required from the licensor. If you are planning to wrap MinerU in a client portal and let customers upload statements, that attribution requirement is a product decision, not a footnote.

MinerU reads Excel files but does not write them

There is a folder in the repository called mineru/model/xlsx, and it causes a predictable misunderstanding. It is an input path, not an output path.

The code there imports load_workbook from openpyxl and feeds the result into MinerU internal middle JSON representation. In the CLI, xlsx appears in a list of office input suffixes alongside docx and pptx. In other words, MinerU can accept a spreadsheet as a source document and convert it into Markdown for a model to read. It cannot go the other way. Nothing in the project writes a workbook.

What MinerU does write is a Markdown file, a content_list.json and a middle.json, plus optional layout and span debug PDFs. Tables inside the Markdown are emitted as raw HTML blocks rather than Markdown pipe tables, which is a sensible choice because HTML survives merged cells and multi-row headers that pipe syntax cannot represent. So the structure of the table is preserved. It is simply preserved as HTML, in a Markdown file, and converting that into an accounting-ready register remains your problem.

What about the hosted MinerU API?

MinerU operates an online service at mineru.net with an API. The documentation states that each account receives a daily quota of 1,000 pages at the highest parsing priority, and that volume beyond that is processed at reduced priority rather than being refused outright. A separate lightweight Agent API is capped at 10 MB per file and 20 pages per document.

MinerU does not publish a per-page price for the API, and this page is not going to invent one. If you need a committed rate and a contract, you would have to ask them. That absence is itself useful information when you are comparing against vendors who do publish rates.

Note also that the hosted API changes the privacy calculation completely. A great deal of the appeal of an open-source parser for financial documents is that nothing leaves your network. Sending client bank statements to a third-party endpoint is a different decision from running the weights on your own box, and it deserves the same scrutiny you would apply to any other processor.

Why a general parser struggles with a bank statement

MinerU is deliberately general. The same pipeline gets pointed at research papers, contracts, slide decks and supplier invoices, and that breadth is the point. It is also why nothing inside it knows what a closing balance is. Specialized document jobs tend to need specialized tooling; the logic that reads line items and tax off a stack of scanned supplier invoices has almost nothing in common with the logic that reconciles a transaction register, even though both start with a PDF.

A bank statement has properties a general parser has no reason to model:

It is one table pretending to be several. The register continues across page breaks without repeating a header. A page-by-page parser produces a sequence of table fragments, and rejoining them in the right order is the first thing you have to build.

Direction is encoded inconsistently. Some banks use separate debit and credit columns, some use one signed amount column, some use a trailing CR or DR marker. Getting the sign right is a per-bank decision.

Descriptions wrap. A long merchant description spills onto a second physical line that belongs to the same transaction. Treated naively it becomes a phantom row with no amount.

The balance is a checksum. This is the useful one. A statement carries a running balance, so you can verify an extraction arithmetically: start from the opening balance, apply every transaction, and you should land exactly on the closing balance. A general document parser has no reason to perform that check, which means when it drops a row you find out during reconciliation instead of at extraction time.

MinerU compared to a finished converter

When MinerU is the right tool anyway

If your actual goal is a retrieval pipeline, MinerU is an excellent choice and a converter is the wrong shape entirely. Feeding a language model the text of a mixed pile of PDFs, Word files and slide decks is precisely what it was built for, it handles that breadth better than most finance-specific tools ever will, and the license is generous below thresholds most companies will never approach.

It is also the right answer when documents genuinely cannot leave your network and you have the engineering capacity to build the register logic yourself. Self-hosting settles the data residency question in a way no hosted service can.

What it is not is a shortcut to a spreadsheet. If you are a bookkeeper with forty client statements to close out this month, the gap between MinerU output and something you can reconcile is several weeks of engineering plus maintenance every time a bank redesigns a template.

The practical route to a spreadsheet

Upload the PDF and take the workbook. BankXLSX is narrowed on purpose to bank and card statements, which is what lets it do the things a general parser will not: normalize dates, sign amounts by direction, stitch rows across page breaks and verify the running balance against the closing figure. Scanned and photographed statements are handled, and password-protected PDFs do not need unlocking first. Exports include XLSX and CSV, plus QBO, OFX, QFX and QIF when the destination is accounting software rather than a spreadsheet.

If you want the same comparison for the other major open-source options, the toolkit with a real Excel writer is covered on the PaddleOCR alternative page, and the IBM parser is covered on the Docling alternative page. For a broader view of the field, see the roundup of open-source OCR options for bank statements.