Statement Extractor
Extraction is not trustworthy just because its own math agrees with itself.
Statement Extractor is an engineering system for turning native-text bank statements into structured transaction data, then reconciling that data against controls captured independently from the statement before extraction begins.
Internal consistency is not the same as independent verification.
A parser can extract a set of rows, total those same rows, and prove that its own numbers reconcile. That still does not prove it captured the statement correctly. Statement Extractor was designed around a separate trust boundary so the extracted ledger is checked against values the extraction process never supplied.
The system is designed to answer
Two independent tracks converge at validation.
The distinction matters: the extraction path cannot feed values back into the control-entry path.
Human control entry
An operator reads the statement and keys four printed controls: opening balance, closing balance, deposit total, and debit total. The control-entry function is designed to take those values from keyboard input before extraction runs.
System extraction
The parser reads transaction rows from a native-text PDF using deterministic geometry and format rules, creating structured rows with amounts, categories, provenance, and running-balance information.
See why the independent controls matter.
This demo starts from a synthetic extracted ledger. Toggle the independently keyed summary between a matching version and a version missing one $15.99 debit. The validator logic changes the run from PASS to REVIEW REQUIRED even though the row-by-row balance chain still agrees with itself.
Example Community Bank
| Date | Description | Credit | Debit | Balance |
|---|---|---|---|---|
| 01/02 | Direct Deposit – Payroll | $1,200.00 | — | $1,700.00 |
| 01/05 | Grocery Mart Purchase | — | $85.40 | $1,614.60 |
| 01/07 | Electric Utility Co | — | $64.10 | $1,550.50 |
| 01/10 | Coffee Shop | — | $5.25 | $1,545.25 |
| 01/14 | Transfer From Savings | $300.00 | — | $1,845.25 |
| 01/18 | Auto Loan Payment | — | $210.00 | $1,635.25 |
| 01/22 | Online Retailer | — | $142.99 | $1,492.26 |
| 01/29 | Streaming Service | — | $15.99 | $1,476.27 |
Four checks tell the core architecture story.
The development validator implements nine checks today. The public demo surfaces four that make the independence and reconciliation model easiest to understand.
Deposits total
Compares extracted deposits and credits with the independently keyed deposit control.
Debits total
Compares extracted checks and withdrawals with the independently keyed debit control.
Full balance walk
Tests opening balance + increases − decreases against the independently keyed closing balance.
Running-balance chain
Tests whether the printed running balance is internally consistent from row to row. It is useful, but it is not independent source verification.
A perfect internal chain can still fail independent reconciliation.
That is the point of the trust boundary.
In the project's original synthetic sample statement (Awesome Bank, a fictional institution used for demonstration and testing), all 32 running-balance links reconciled internally. But four debit rows totaling $20,600 were not represented in the sample's printed summary control. The validator therefore failed V2 and V3 and moved the run to REVIEW_REQUIRED.
The latest ground-truth review reproduced that validator result from the sample's hand-verified oracle data. This is an architecture proof on synthetic data—not a claim about a real client's bank statement or broad bank-format support.
A recorded walkthrough of the full workflow.
This recorded walkthrough replays an actual run of the Statement Extractor development code against a synthetic sample statement from Awesome Bank, a fictional institution created for demonstration and testing.
It shows the workflow from document fingerprinting and blind control entry through row extraction, nine validation checks, review-state handling, and workbook output.
The walkthrough demonstrates one synthetic layout only. It does not establish production readiness or support for any real-world financial institution. Statement Extractor remains in development, with 9 of 15 designed validation checks currently implemented.
Hosted externally on Claude. No client financial data is used. A passing validation result is not human approval.
Implemented architecture, narrow evidence base.
The maturity label is intentionally conservative. The project proves important components and controls, but it is not a generalized statement-processing product.
Control-entry trust boundary
VerifiedThe orchestration test suite passed 54/54 in the latest review, including tests that prevent extraction or file reads from supplying the four operator-entered controls.
Validation engine
VerifiedNine implemented checks were exercised against the hand-verified sample data; the expected pass and review-required outcomes were reproduced.
Workbook output
VerifiedThe real writer produced both a diagnostic workbook for the failing sample and a deliverable workbook for the corrected passing test copy, with operator review still PENDING.
Extraction parser
Implemented / recheck pendingThe deterministic PDF parser exists. The latest review could not rerun the full extraction test suite because the fixture files attached to that project were stale ZIP substitutes rather than the genuine PDFs expected by the parser. The recorded walkthrough shows an actual run of the development code against the synthetic sample. The separate full extraction-suite rerun noted here remains pending from the latest documented review.
Real bank formats
Not yetThe walkthrough runs on one synthetic sample layout. No real-world financial institution format is currently verified or claimed as supported.
Operator interface
Not yetThe current operator workflow is command-line based. There is no production web or desktop interface in the evidence reviewed.
Designed validation checks
9 of 15 implementedSix designed checks—V4, V9, V10, V13, V14, and V15—are explicitly deferred rather than represented as working.
Public maturity
In DevelopmentThe appropriate public frame is an engineering case study and active development system, not production software, beta software, or a multi-bank product.
What this page does not claim
The development story is stronger when the limits are explicit.
Where does your data workflow need independent verification instead of another automated guess?
O2S builds custom internal systems around real operating requirements, including extraction, reconciliation, exception handling, review gates, and usable outputs.