This course teaches matching and classification judgment — but in real vendor statement work, most "discrepancies" never make it that far. They're caused upstream, by the document itself defeating whatever read it before a human (or a system) ever compares one number to another.
A statement that was printed, scanned, or photographed on a phone has no underlying text layer at all — every number on the page is a shape made of pixels, not a character a computer can read directly. Naive PDF text extraction either finds nothing or, worse, finds a garbled text layer left behind by a prior OCR pass on someone else's system, and treats the garbage as if it were real data.
Statements scanned sideways, upside down, or a few degrees off-square are common — especially multi-page statements batch-scanned on shared office equipment. A rotated page can make a reference column, an amount column, and a date column line up in the wrong order once naive extraction reads the page left-to-right, top-to-bottom — silently swapping which number belongs to which invoice.
Every vendor's ERP exports a different layout: open-item vs balance-forward, different column orders, different date formats, multi-currency statements, statements with a logo and letterhead pushing the real table down the page. A parser tuned for one vendor's layout routinely mis-reads another vendor's layout — not because the reconciliation logic is wrong, but because the wrong numbers were handed to it in the first place.
The most dangerous failure mode isn't extraction that fails loudly (an empty page, an obvious error) — it's extraction that fails quietly. A garbled text layer can still produce plausible-looking characters, and a wrongly-ordered read can still produce a number that looks like a legitimate invoice reference. If that wrong reference becomes the "join key" used to match a statement line to your AP extract, you get a confident, wrong match — a false tie-out that looks clean and isn't.
The governing principle for any extraction-quality problem: when extracted text and the rendered page disagree, the page wins. Extracted text, OCR output, and parsed tables all describe the document — they are not the document. Before concluding a statement is unreadable, unreconcilable, or that a number is genuinely missing, look at the actual rendered page. A degraded parse is a bug in the reading, not proof the information isn't there.
StatementZen is built around this exact principle: models may propose a read of the page, but arithmetic proves the reconciliation — never the reverse. Rather than a generic OCR wrapper, extraction is purpose-built for scanned, rotated, and multi-format vendor statements, because that's the actual shape of the documents accountants receive. The guarantee we back this with is real and checkable, not a marketing percentage: we don't charge for statements we can't extract — you only pay for reconciliations we successfully complete. If extraction genuinely fails, that's our cost, not yours.
StatementZen Academy Team — Built from StatementZen's own vendor statement reconciliation engineering and casework — pending Michael's named byline commitment (spec.md section 7). · Last updated