Docling is a serious open-source document parser from IBM Research. If you are already running it and getting decent output, the honest answer is: you may not need an alternative. You may need better failure detection around it.
This page is written for people who have hit a wall with it. It separates the three different problems that get bundled into “find me a Docling alternative”, because each one has a different fix.
What Docling genuinely does well
- Native PDFs with a real text layer, in a handful of common languages.
- Reading-order reconstruction, which is why it became popular for RAG pipelines.
- Table structure detection on reasonably well-formed tables.
- Markdown and JSON output you can pipeline yourself, with no vendor lock-in and no per-page fee.
If your documents are clean and your volume is low, the library is the cheapest path that works. Nothing below should talk you out of that.
Where it breaks, and why tuning does not fix it
1. Tables that continue onto the next page
Docling processes tables page by page. A table whose body continues on the following page does not get stitched back together, so the continuation can arrive with a misplaced header, duplicated columns, or invented rows. The project’s own issue tracker documents this as a known structural limitation, not a configuration problem — users report that cell matching, accurate mode and OCR toggles do not resolve it.
Financial statements are exactly the document type where this happens most: a transaction list that runs from page 3 into page 4, with the column header printed only at the top of page 3.
2. Borderless tables
When columns are defined only by whitespace, table detection can fail outright or fall back to a picture region — in which case the content is lost rather than misaligned. Bank statements and 10-K tables are frequently borderless.
3. No signal for “I could not read this”
The output is a document object. It does not tell you which cells were ambiguous, which rows failed to align, or whether the numbers still add up. In a RAG pipeline that is tolerable. In a lending or accounting workflow it is the whole problem: a wrong number that looks like data is worse than an obvious failure.
Three real alternatives (only one is a different product)
Option A: keep Docling, add verification
Feed the output into checks you write yourself: re-sum the amounts against the document’s stated total, compare consecutive balances, flag rows where a numeric column parsed as text. This is the cheapest and most controllable route — and it is what most production teams eventually do. The cost is engineering time, and the checks are only as good as the person who wrote them.
Option B: a hosted parser API
Managed parsing services remove the GPU and the queue. They generally give better throughput and, sometimes, better table handling on specific document types. What they usually do not give you is a financial check: whether opening + deposits − withdrawals equals closing, or whether this month’s closing balance matches next month’s opening. You still have to build that.
Option C: a tool that answers the question behind the extraction
SheetParser is in this category, and it is fair to say what it is and is not. It is a hosted pipeline in the same family as Docling, with the extraction work done for you, plus three things layered on top:
- Reconciliation. On statements, the running balance is recomputed after every row. A broken chain is flagged on the row where it breaks.
- Provenance. Every extracted value maps back to a region of the source page, so a challenged number is one click from its evidence.
- Third-party verification. A hash-bound certificate lets someone else confirm which document the output came from, without an account.
What it does not do is magically stitch every cross-page table. That limitation is real and shared with the underlying engine. The difference is that when a table does not survive, you can see it — the totals stop tying out, and the disputed cells are listed — instead of shipping a plausible-looking wrong number.
How to decide in ten minutes
- Take one real document from your worst-performing pile — a scanned statement, a borderless 10-K table, a multi-page invoice batch.
- Run it through whatever you are considering.
- Ask one question: does the output tell me what it could not read? If the answer is no, you are comparing extraction quality and ignoring the failure mode that actually costs money.
- Then check whether the numbers reconcile to the document’s own totals.
If your documents are clean single-page tables and your pipeline already validates them, keep Docling. If you are spending your week writing checks around it, or you cannot answer a client asking “where did this number come from”, that is the gap SheetParser fills. One file is free each day — test it on your own worst document.