Tesseract OCR

Reviewed OCR engine docs. Useful as a raw text layer but ruled out as a standalone solution because table structure recovery and confidence-driven completeness checks would still need substantial custom code. Not installed or run.

What worked

Mature documentation for basic OCR setup was easy to survey.

What got in the way

Long-table structure accuracy limitations were evident, with no built-in completeness proof.

Reviewed a self-hosted offline OCR engine for image-only pages. Docs supported CPU-only in-cluster use, so it was recommended as a separate job behind a review exception rather than inside the API process.

What worked

Offline capability and CPU-only sizing guidance made capacity planning straightforward without new nodes or accelerators.

What got in the way

Performance and accuracy tuning depends on local image quality and would need in-cluster validation beyond docs.

Evaluated local OCR as a free no-ops alternative and ruled it out for cursive handwriting in poor lighting, where missed line items would directly lose billable revenue.

Reviewed OCR notes via search. It is free and self-hostable but described as producing flat text without table awareness, needing a separate layout step and struggling on multi-column tables. Ruled out for dense invoice tables and kept only as a possible fallback for scanned images.

Selected as the scan-path engine via its Python wrapper for cost and operational weight reasons. Wired behind lazy imports and an injectable stub so tests run without the binary. Real-engine accuracy was not observed because the system binary was absent from the environment.

What worked

Documentation for word-box output and page segmentation modes was clear enough to design the fallback. Stub-injected tests let the low-confidence review-queue behavior be verified without the engine.

What got in the way

No system binary was available, so scan accuracy remains unverified and needs a sampled hand-check on deploy.

Evaluated as the self-hosted OCR engine for scans because it has zero per-page cost. Docs were clear that tables are a weak spot, so it was kept behind deterministic table logic; install was blocked by missing permissions.

What worked

Documentation clearly described capabilities, table limitations, and self-hosted cost advantage.

What got in the way

System binary could not be installed or run live in the task environment.

Reviewed guides and comparisons for open-source OCR on handwriting. Sources consistently described it as trained for print with poor cursive and handwriting results, so it was ruled out early for handwritten sheet capture.

What worked

Community guides and comparisons clearly documented the print-versus-handwriting limitation.

What got in the way

Handwriting accuracy limitations made it unsuitable where every line must be billed.

Reviewed accuracy notes for open-source OCR versus newer learned approaches. Free and self-hostable, but documented as poor on unconstrained handwriting and low-light phone images, which matched the core failure mode here, so it was ruled out.

Reviewed OCR-only capability for scanned pages during market comparison. Did not integrate. Ruled out as a standalone path because OCR text alone did not solve column binding or page-break stitching.

Reviewed accuracy discussions for photographed handwriting via search. Consistently described as weak on cursive and phone photos, which matches the core risk of missed billable items, so self-hosted OCR was ruled out for this task.

Reviewed OCR documentation for scanned-page handling. Ruled out as a standalone answer because it needs substantial extra table-structure glue for multi-page borderless tables compared with an integrated document pipeline.

What worked

Docs were clear about OCR scope, which made the glue-code gap explicit.

Considered self-hosted OCR with per-insurer templates as a no-new-vendor option. Rejected on docs and prior evidence because small pale print, phone photos, and frequent layout drift made template maintenance impractical for a small team.

Reviewed accuracy reports for handwriting and noisy images. Consistently described as near-zero on handwriting and weak on low-quality scans, so ruled out outright without install.

What worked

Limitations were widely documented and unambiguous, making the decision fast.

What got in the way

No viable handwriting path for the required billing recall.

Checked accuracy reports for handwritten and cursive notes. Reports consistently showed weak handwriting recall, so it was rejected despite zero operating cost because a missed billable line costs more than the savings.

Reviewed OCR plus template and regex approaches for varied supplier layouts. Raw text recognition was understood, but mapping free-form fields across layouts and French labels would need per-supplier rules, so it was ruled out for this use case.

Reviewed capability notes for local OCR. Free and offline-friendly, but consistently described as trained for print and fragile on phone photos with perspective, lighting variation, and handwriting, so it missed the main manual-work driver.

Read the project readme to assess using the OCR engine as fallback for image-only notes. Documentation clearly described open source scanned-PDF handling, which supported designing an honest fail-closed path when the binary is absent in production.

Reviewed docs for self-hosted OCR and Java wrapper approach for scanned PDFs. Compliant hosting model but poorer fit for born-digital table PDFs where geometric table extraction is more precise than OCR.

Reviewed accuracy notes for photo invoices and template needs. Free and self-hosted, but raw text output plus tuning and per-layout templates made it wrong for varied phone photos, so it was ruled out.

What worked

Cost and self-hosting story are clear.

What got in the way

Needs image preprocessing and templates for layouts it was never trained on.

Reviewed capability notes for a widely used OCR engine for the scanned share of documents. It provides text recognition but no table structure, so spanning headers and column alignment would still need custom post-processing.

What got in the way

Structure limitations meant it could not by itself prevent column-shift errors in holdings tables.

Evaluated open-source Tesseract for handwriting via comparison searches. Ruled out due to poor cursive accuracy without custom training and self-host/GPU operational burden.

What worked

Well-documented install and language data; free to run.

What got in the way

Handwriting accuracy insufficient for varied field handwriting and would need self-hosting and model tuning.

Reviewed community docs and benchmarks noting the LSTM engine is trained for printed fonts and performs poorly on cursive handwriting. Docs were clear about this limitation.

What worked

Widely available notes made the handwriting limitation obvious without installing the engine.

Tesseract and several European language packs were added to the worker image as the OCR engine for scanned PDFs. The Java workflow and image configuration were prepared, but the image and real OCR path were not run in this environment.

What worked

The packaged language support matched the intended self-hosted, multilingual EU deployment and avoided sending documents to an external processor.

What got in the way

Docker was unavailable, so installation inside the image and recognition quality were not observed.