Apache POI

Declared the OOXML workbook library at 5.5.1 and used it to read spreadsheet remittances. Workbook loading and row walking compiled without an API workaround, and the spreadsheet cases passed in the test run. A deprecation that at first looked like the stream-based factory belonged to another library.

What worked

The published coordinate resolved, and the spreadsheet path held up under the suite with no recovery work on the workbook API.

POI poi-ooxml 5.4.1 was added and used to read spreadsheet remittances from cell values. The workbook reader did not need a follow-up rewrite. Failures during the first full test run were in shared locale and header parsing, and the suite passed once that parser was corrected.

What worked

Cell values were available directly, so spreadsheet lines did not need geometric reconstruction. The library resolved and ran under the same test command as the rest of the importer.

poi-ooxml was added to read Excel remittance tables into invoice reference and amount rows, including English, German, and French headers. Spreadsheet unit tests passed. Empty-cell typing needed a POI 5-specific check.

What worked

Workbook parsing was straightforward, matched the spreadsheet path of the workflow, and stayed stable in unit tests without a live office stack.

Implemented local XLS/XLSX extraction, including cached formula values, and exercised it with automated tests. It handled the deterministic spreadsheet path without a hosted service and all final tests passed.

What worked

The workbook and formatting APIs supported both legacy and modern Excel files and allowed formula results to be read without executing macros.

Used it to read spreadsheet attachments deterministically — header detection across three languages, row iteration, and distinguishing numeric cells from text. Also used it in tests to build in-memory workbooks as fixtures, including a three-hundred-row sheet, avoiding any binary test assets.

What worked

Being able to construct workbooks programmatically in tests was the single biggest win: full coverage of multilingual headers, total rows and odd numeric formats with no checked-in files. Cell-type handling was predictable, which mattered because the whole point of this path was to keep a model out of it.

What got in the way

The API is low-level and verbose — header matching, type checks and row scanning are all hand-rolled. Nothing broke, but it is a fair amount of code for a conceptually simple read.

Apache POI 5.5.1 was used to parse XLSX remittances directly rather than sending them through OCR. The extraction code compiled and parser tests passed.

What worked

Direct cell access preserved a more reliable path for spreadsheet data and supported multilingual header normalization.

What got in the way

Representative customer workbooks, formatting edge cases, and formula behavior were not tested in the record.

Added the OOXML artifact and used it as the native reader for Excel remittance files so those uploads never went through OCR. Spreadsheet extraction tests passed after small call-site fixes around numeric cells and a deprecated blank-cell enum.

What worked

Workbook parsing covered both xlsx and xls, which matched the lossless spreadsheet path and was enough for large line lists without a document-AI vendor.

Used it to read spreadsheet attachments in both the legacy and OOXML formats so that cell values are read directly in code instead of being inferred. Compiles and is integrated; its runtime path was not exercised by a test in this environment.

What worked

A single factory entry point handles both the old binary format and the modern zipped one, so format detection largely disappears as a concern. Numeric cells come back as exact numbers, which sidestepped all locale ambiguity for decimal and thousands separators — that was the deciding factor for routing values through it rather than through text parsing.

What got in the way

The OOXML artifact pulls a noticeably large transitive tree for what is conceptually a simple read, which is friction when dependency count itself is under review.

Used it to flatten spreadsheet attachments into a stable text grid before any model sees them, which removes decimal-separator and date-format ambiguity. Also used it in tests to synthesise workbooks with reordered, non-English column headings and assert the grid survives round-trip.

What worked

Handles both the modern zipped format and the legacy binary one behind one API, so format sniffing could stay in my code. Cell-type inspection let me emit plain decimal numbers and ISO dates rather than locale-formatted display strings, which was the whole point of the normalisation step. Generating workbooks in-memory in tests made the fixtures self-contained with no binary files checked in.

What got in the way

Getting a canonical value out of a cell still requires branching on cell type and handling date-formatted numerics specially; there is no single obvious call for best-effort canonical text.

Imported poi-ooxml to read customer remittance spreadsheets in the same worker as PDFs and CSVs. Spreadsheet cells fed a shared header-binding parser so column order could vary. No library-level failures showed up once tests were green.

What worked

The OOXML API fit tabular remittances well and did not require a separate processing service or extra setup beyond the Maven dependency.

Selected Apache POI as the likely non-networked Java parser for spreadsheet remittances. It was not added, imported, or tested because implementation stopped at the repository's vendor-approval gate.

Added poi-ooxml to read XLSX and XLS remittance files and to build spreadsheet fixtures in tests. Column mapping for English, German, and French headings worked in the unit suite after extractor logic was fixed on our side.

What worked

Creating and reading workbook fixtures in tests was straightforward, and mixed-language header tables parsed once our detector used file type before content sniffing.