Engineering insight
Bank statement analysis: a reference architecture with human review
A reference architecture for bank statement extraction, reconciliation and human review, with a synthetic example and traceable document evidence.
In this note
Bank statement analysis combines several different jobs: reading a document, interpreting its structure, calculating totals and deciding what the information means. Combining them in a single free-form model response makes errors difficult to locate and correct.
A more inspectable design separates those responsibilities. The reference architecture below is illustrative, not a report of a Xinexis banking engagement. Its purpose is to show how software can prepare traceable information for a qualified reviewer while keeping consequential decisions under the institution’s control.
Define a bounded document workflow
Begin with an explicit document scope: supported statement layouts, languages, account types and input quality. Identify required fields and the downstream system that receives approved results. Specify what happens with incomplete periods, unreadable pages or unsupported documents.
Select processing services only after the institution has defined its requirements for access, retention, processing locations, provider use of submitted data and third-party review. Product names or private endpoints alone do not establish that those requirements are met.
Separate the pipeline into reviewable stages
- Intake: register the document, its source, receipt time and integrity hash in an appropriately controlled store. Detect duplicate submissions while preserving their intake history.
- Extraction: read account metadata, statement period, balances and transaction rows. Preserve the raw extracted text alongside normalized values.
- Validation: check required fields, date ranges, currency consistency, duplicate rows and balance reconciliation using explicit rules.
- Assistance: optionally propose transaction labels or draft an evidence-linked narrative. Treat these as suggestions with a recorded model and configuration version.
- Review and export: present exceptions to an authorized reviewer, retain corrections and approval history, and export only the approved record version.
These stages allow an extraction error to be corrected without treating the entire result as opaque. They also make it possible to use a structured account-data feed where one is appropriately available, rather than forcing every input through OCR.
A synthetic reconciliation example
Consider a fictional statement in a single currency with an opening balance of 12,000, a deposit of 5,000, a rent payment of 1,800, a utility payment of 250 and a service fee of 25. Its expected closing balance is 14,925:
12,000 + 5,000 − 1,800 − 250 − 25 = 14,925.
Suppose OCR reads the utility payment as 2,500. The extracted transactions now imply a closing balance of 12,675, which differs from the statement’s closing balance by 2,250. The pipeline should flag the discrepancy and show the source row to the reviewer. It should not ask a language model to invent an adjustment that makes the totals agree.
If the reviewer confirms 250 from the source, record both values, the correction, the reviewer and the approved version. Reconciliation is a useful control, but matching totals alone do not establish completeness or authenticity: two errors can offset each other, and a document may require separate verification.
Make every important value traceable
Each normalized transaction should retain a link to its document, page and source location. For a derived total, retain the transaction identifiers and calculation version used to produce it. This lets a reviewer move from a summary to the underlying evidence.
Document-extraction tools can support this design. For example, Microsoft’s analysis-response documentation (opens in a new tab) describes content spans and page-based bounding regions. Availability varies by returned element and input format, so the integration needs to handle missing references explicitly.
A generated sentence such as “monthly deposits total 5,000” should point to the included transactions. Calling the same amount “income” introduces an interpretation: a deposit might instead be a transfer or another non-income item. Preserve that distinction and request review when the classification matters.
Design the reviewer’s workspace
Show the document image, extracted rows, reconciliation result and proposed narrative together. Prioritize missing evidence, inconsistent arithmetic and fields important to the downstream task. A vendor confidence score can inform routing, but it should not be treated as a universally calibrated probability of correctness.
Keep approval separate from extraction completion. A changed source document or corrected transaction should invalidate affected summaries and require the appropriate re-review. Preserve earlier versions for authorized investigation under the institution’s retention policy.
Failures also need an operational path. A processing timeout must not cause duplicate downstream records. An unsupported statement should remain visible with its reason for manual handling, rather than disappear from a success-only dashboard.
Evaluate before expanding
Use representative documents with independently reviewed expected values. Measure field-level correction rates, missing and duplicated rows, reconciliation failures, source-reference coverage and reviewer time. Segment results by layout and scan quality so a strong average does not conceal an unsupported input class.
A useful initial deliverable includes the supported-document specification, a validation rule set, a reviewer interface, an evaluation report and an export contract. Expand only when the evidence and the institution’s responsible owners support doing so.
Explore AI & Machine Learning services, or Discuss a Project with the document workflow, required fields and review responsibilities you need to address.