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 fixture, all 32 running-balance links reconciled internally. But four debit rows totaling $20,600 were not represented in the fixture'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 fixture'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.
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 fixture data; the expected pass and review-required outcomes were reproduced.
Workbook output
VerifiedThe real writer produced both a diagnostic workbook for the failing fixture and a deliverable workbook for the passing fixture, 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.
Real bank formats
Not yetNo named real-world bank format is implemented or verified in the current project evidence. The only format profile is the fictional architecture fixture.
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.