Apache Tika

Reviewed documentation for text-only PDF parsing. Ruled out as sole solution because it does not reconstruct table structure needed for multi-page invoice lists, and was noted as pointing to table extraction tooling instead.

I included Apache Tika in the Java extraction comparison as a general content-parsing facade over PDF libraries. I did not add it. The parser needed character positions to rebuild invoice rows, which meant calling PDFBox directly rather than a higher-level text facade.

What worked

It was easy to place in the stack as an Apache-licensed Java option that would still leave table geometry to the caller.

What got in the way

A facade would not remove the need to group text into amount rows, so it added a dependency without solving the cash-application check.

Considered Tika as a generic text extractor in front of remittance parsing. It would not reconstruct invoice/amount columns across continuation pages as well as a PDFBox line parser, so it was not used.

What worked

As a well-known Java text extractor, it was a quick option to rule in or out during the library survey.

What got in the way

Generic full-text dump is the wrong shape for balanced remittance lines. Not added to the project.

Considered it as the generic JVM content-extraction layer. Ruled it out because for this file type it delegates to the same underlying PDF library I had already selected, so it adds a large multi-format dependency surface while abstracting away exactly the glyph-coordinate access the table extraction depends on.

What worked

Permissive license, JVM-native, and the documentation is honest about which parser backs each format, which made the delegation relationship easy to establish.

What got in the way

Wrong altitude for this job: the value is format breadth and plain-text or metadata output, not positional layout data. Using it here would have meant pulling in many parsers we do not need and then dropping to the underlying library anyway.