Statement Recognition: the Hard Part Is Mapping

Budget and rework in a statement-recognition project go to account mapping and exception handling, not to character reading. A vendor demo shows a high recognition rate on one clean, standardised scan, and that figure is real — it simply measures the shallowest layer. Delivery has to absorb the rest: the same line item carrying four different names across portfolio companies, hand-adjusted row orders, parent-only and consolidated statements arriving in the same folder, and units switching between thousands and tens of thousands. Recognition rate decides whether the project can start. The mapping table decides whether it can finish.

Three accuracy layers; sign the acceptance on the deepest one

Layer one is character accuracy: are individual figures and labels read correctly. This is what demos measure. Layer two is field accuracy: does each prescribed line of the balance sheet, income statement and cash flow statement land in the right system field, including shifted rows and omitted lines. Layer three is metric accuracy: do metrics derived from those fields — cash runway, interest-bearing debt, gross margin, receivable turns — match a human result, and can each value be traced to its page and region.

The three layers do not nest; they transform. Perfect characters can still shift into wrong fields when table rules are missing. Perfect fields can still produce wrong metrics when an account maps to a plausible-but-different line. So write the acceptance clause at layer three: sample and recompute at metric level, ensure the sample includes non-standard formats (image PDFs, edited spreadsheets, multi-currency statements), and define the denominator as “entity-periods”, not “fields”.

Four mapping problems

Problem	What it looks like in delivery	Handling	Acceptance test
Naming variance	One account under four labels across standards and industries	Maintain the map by account family: many source aliases to one target field, each with a cited basis	Random historical statements re-checked by hand
Scope variance	Parent-only and consolidated statements uploaded together	Make reporting entity, consolidation scope and definition version mandatory, with no defaults	Metrics stay distinguishable when both statement types exist for one company
Layout drift	Rows reordered, custom rows added, column order changed	Locate by account semantics rather than coordinates; keep a layout snapshot	A redesigned sample ingests without retraining
Unit and currency	Thousands and units mixed; foreign currency mixed with reporting currency	Store unit and currency as separate fields, add magnitude checks, route anomalies to humans	Cross-period jumps trace to the unit field, not to a recognition error

The client, not the vendor, owns the mapping table. The reason is simple: account meaning follows the portfolio company’s sector and accounting policy, and only the team that collects post-investment reporting knows that one company splits R&D expense across two rows. The vendor supplies the mapping editor and the exception workbench; it cannot supply the judgement.

Validation catches errors earlier than recognition

Run three checks in order. Arithmetic integrity: assets equal liabilities plus equity, income statement ties to the equity movement, closing cash ties to monetary funds. Period continuity: opening balance equals prior closing balance for the same entity and account, with tolerance and exception queue. Definition drift: the rate of change in mapping hits — a sudden rise means a company changed its template.

None of these need a model, all are cheap to implement, and they stop the most expensive class of error: numbers that look plausible. Recognition mistakes get caught by a human reading the page; scope drift does not, because it stays internally consistent every period until a peer comparison or a valuation adjustment exposes it. Catalpa lists statement recognition as its first published AI scenario, and the engineering weight sits in this layer: converging many formats onto one definition table (see AI agents and intelligent risk).

Checklist before go-live

• Produce the account definition table first: target field, source aliases, basis, owner; sign it and treat it as the mapping baseline (method in data governance and metrics).
• Collect genuine historical statements from three or more portfolio companies covering image PDFs, hand-edited spreadsheets and multi-currency filings; make that set the acceptance sample.
• Define sampling and ownership for each accuracy layer, and put only the metric level into the contract.
• Set human-confirmation thresholds: rows below confidence or failing validation go to a queue, never straight into a report.
• Retain each period’s source file, recognition result and manual corrections; record correction reasons as enumerated values rather than free text.
• Fix the exception turnaround target for reporting season, with an escalation path when the queue grows.
• Review mapping-hit drift quarterly as a standing input to definition maintenance.

When we advise against introducing recognition

Three cases. The portfolio is small and the statement set per period is limited, so two person-days of manual entry covers it: build and maintenance cost will not return. The account definition table does not exist yet: launching then lets a model execute an unconfirmed mapping steadily, and later requires a full recompute — the same mistake as comparing features before definitions, in an AI wrapper (see post-investment metrics). Portfolio companies send paper only, with uncontrollable scan quality: the real bottleneck is the collection agreement; fix reporting duties and file formats in the post-investment policy first.

The payoff of statement recognition is not converting paper into digits. It is converting many definitions into comparability. Accuracy is the entry ticket; the mapping table and the validation layer decide whether the capability is still alive in year two.