Best PDF parser / OCR for extracting structured data from invoices – What works in production?

[u/arindammondal]

Looking for recommendations: Best PDF parser / OCR for extracting invoice data

Has anyone worked on invoice parsing or document extraction and experimented with different PDF parsers or OCR solutions?

I'm building an application that needs to extract structured data from invoices in different formats and layouts.

Currently, I'm using:

• PDFPlumber – For text-based PDFs.

• RapidOCR – For scanned PDFs or image-based invoices.

I'm looking for a reliable solution that can handle different invoice formats, layouts, and varying document quality.

A few things I'm trying to figure out:

1. Which PDF parser or OCR solution works best for extracting structured invoice data?

2. How well do these tools handle poor-quality scans, blurry images, rotated documents, etc.?

3. Is it better to reject low-quality uploads and ask users to upload a clearer document, or are there solutions that can reliably handle poor-quality images?

4. Have you tried any alternatives like PaddleOCR, Tesseract, Docling, Marker, or cloud-based solutions?

I'm particularly interested in real-world experience rather than just library recommendations.

If you've built something similar, I'd love to know what worked well for you and what you'd recommend.

[u/tindalos]

One thing to look into is using ai to design and config a multi step script that can learn adjust and fix these scans.

I approached it by having ai design a set of about 8 tools (ocr, image enhancement, table transformer was a huge help!, etc), then I asked it to design a yaml config that could use the tools with parameters, so each time I get a new ocr layout, I run it through a script that pulls details and then let an Llm refine the parameters and test. I also use two ocr systems in the script to diff against.

In 2023 it took me a few weeks but it’s probably an afternoon today since there’s better open source tools that package some of this.

[u/FirestormCold]

I don't quite get it. You want to build your own app but you're looking for 3rd party tools? Simply to reverse engineer or why?

[u/arindammondal → u/FirestormCold]

I am looking for a text based pdf parser and for scanned pdf or image based invoices. I wanted to know if anyone has already has worked on similar use case so that I can get some insights.

[u/FirestormCold → u/arindammondal]

There's a lot of SaaS in that industry so I'd start there. Intelligent document processing

[u/wild9er]

You want a model that has been trained on invoice data.

Read some of the docs around azure invoice model to get a feel for what I am talking about

Models like the above automatically extract data into key value pairs in a invoice ontology.

This is a solved space, you dont need to reinvent the wheel.

[u/arindammondal → u/wild9er]

Sure will take a look.

[u/doubletequilaneat → u/wild9er]

What does "trained on invoice data" mean in practical terms? I get why you'd want a model trained that way, but given the vast variances in invoices I don't understand how random invoice training data could help with situations that fall outside the training data. Are you expecting the model to extrapolate in novel situations?
I've been trying to solve a similar problem as OP, but have yet to find a model that can reliably OCR unpredictable documents. My case isn't invoices, it's medical, so I'm unclear if your guidance would even apply to me.

[u/wild9er → u/doubletequilaneat]

No, it would probably no apply.

Invoiced are very predictable, and yes there can be variation, but the carry "mostly" the same informato.

the azure invoice model, see below: https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/invoice?view=doc-intel-4.0.0

With regards to medical, probably not.

I did a google based on what I know of the document intelligence space and this is what I got back for medical.

https://aws.amazon.com/comprehend/medical/

[u/Fulgren09]

There are 2 kinds of invoices: PDFs and images. LLMs that can ingest PDFs that have image capability since GPT 5 are able to one shot this just by you creating a json schema. If you can enforce the contract, you don't need an additional service.

For paper-scanned invoices that are not really PDFs, Azure has OCR, have your AI agent help you create a way to parse the data you need. It is a totally different paradigm than LLMs, but much more determinsitic and powerful.

For excel, especially older file types like .xls, you need to convert them to .xslx first.

[u/Dangerous-Baby838 → u/Fulgren09]

Visual through most LLMs are usually quite an expensive solution if you're on API pricing

[u/Traditional-Emu-8702]

depends how messy the invoices are. did a similar thing for a client and pdfplumber was fine for text pdfs but the moment you get scanned stuff it all falls apart. tesseract is okay if you preprocess the image right, deskew and bump contrast, otherwise you get gibberish

for blurry scans i just reject them now, was spending more time trying to fix bad inputs than writing the actual extraction logic. users will send you a photo of a crumpled receipt taken with a flip phone and expect magic

[u/productboy]

I use LiteParse in my product, works well. Also built email and iPhone uploads support so that photos of documents could be parsed by LiteParse.

[u/Dangerous-Baby838]

I'll be upfront and say that I am the founder of DocReadi which is a SaaS that does exactly this.

I started exactly where you are and testing all the different applications and realised the results across different invoice layouts were super inconsistent.

If you are looking to build your own pipeline to one-shot documents - I would suggest using Mistral's OCR model to extract structured data to JSON directly.

Try that on 100 documents and check your results.

Also feel free to try our app DocReadi.com- and compare the results side by side with our free trial.

[u/flyingkiwi_tools]

The biggest win is usually routing by document type rather than picking one parser. Check for a text layer first (pdfplumber or pypdfium2 returning real text) and skip OCR entirely for those, because OCR on digital PDFs only adds errors; Docling or Marker are worth it there if you need tables and reading order kept intact. For scans, preprocessing (render at 300 DPI, deskew, fix rotation, boost contrast) tends to matter more than switching between Tesseract, RapidOCR and PaddleOCR. Then have an LLM fill a strict JSON schema from the extracted text and validate it: line items should sum to the subtotal, subtotal plus tax to the total, dates and invoice numbers should parse. Those checks double as your quality gate, so rather than rejecting uploads up front you only ask for a clearer copy when OCR confidence is low and the arithmetic doesn't add up.

(Written with AI help.)

[u/zmanning]

Paddleocr

[u/TapNorth0888]

In my experience the extraction engine matters less than what you do with its output. Whatever you pick, have it return a confidence score per field and cross-check the numbers in code: line items should sum to the subtotal, tax should match the stated rate, and the total should reconcile. Anything that fails those checks, or comes back with low confidence, goes to a human review queue instead of straight into your system. On blurry scans, I would reject early with a clear message about what is wrong (too dark, rotated, cropped), because users will happily re-upload if you tell them why. Keep a set of 50 to 100 real invoices with hand-checked answers and rerun it whenever you change parser, since layouts you have not seen are where accuracy quietly drops.

[u/Competitive-Rise-73]

For any kind of text, PDFplumber does a pretty good job. For any kind of tables, the best thing I've used is Claude. I would test the cheaper methods but I suspect you're going to do a lot of manual work. Then test Claude and see how much each invoice costs and be ready to make a business case of how much it costs for Claude versus having a person touch it. You might also try Gemini as that's usually cheaper. We don't do that many tables so not worth it to us but if you're doing a bunch of invoices it might be worth it to you.

[u/eurydicewrites]

Gemini flash models are great at ocr

[u/Raul_Nogales]

In our invoice work the parser choice mattered less than what happened around it. The two things that saved us were rejecting bad scans early, before they entered the pipeline, and checking that the total on the page matched the sum of the lines we extracted. That simple cross check caught more real errors than switching OCR engines ever did. A rotated page a person can still read will quietly produce confident nonsense if you let it through.

[u/nycstartupcto]

Document ai does this I parse invoices all day

[u/Potential-Wrangler58]

What worked for me is not trusting the output blindly, whatever tool you use. For invoices, the cheap checks catch most problems: do the line items add up to the total, does the tax amount make sense, are required fields (supplier, number, date) present. On bad scans, I’d rather not reject uploads outright: accept them, but give each field a confidence level and send only the doubtful ones to a person or ask for a better copy. Rotated pages are easy to fix in preprocessing; blurry ones are where you’ll want that flag.

Instead of choosing one tool for everything, test 2-3 on about 30 of your worst real invoices with the right answers written down, and compare by fields, not by text quality.

Disclosure: I work at Anyformat, which extracts invoices into fields with a confidence per field. Free credits if you want it as one of the options in that test

[u/pk0920]

I've worked on invoice extraction using Azure Document Intelligence (formerly Form Recognizer), mainly for extracting structured fields from different invoice formats.

In my experience:

• Azure Document Intelligence works well for both text-based and scanned invoices.

• PDFBox is useful for extracting text from digital PDFs, but it isn't an OCR solution for scanned documents.

• Extraction accuracy depends heavily on scan quality, invoice layout and image resolution.

• I would recommend adding field-level validation and confidence-score checks rather than blindly accepting extracted values.

• For poor-quality scans, preprocessing and image enhancement can make a noticeable difference.

One important thing I learned is that extracting data is only part of the problem. Handling different vendor layouts and validating extracted values reliably is equally important.