> ## Documentation Index > Fetch the complete documentation index at: https://banking.nextedge.consulting/llms.txt > Use this file to discover all available pages before exploring further. # B24 Reconciliation and exception management > Prove that instructions, bank books, provider outcomes and settlement funds agree. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Reconciliation compares independent records to prove they agree: instruction, financial book, provider result and actual settlement funds. It does not invent missing evidence or treat a matching-looking balance as proof of completeness. | Attribute | Module definition | | - | - | | Entry condition | A complete source batch arrives or an unmatched instruction needs investigation. | | Owned records | Source batch, match, exception, corrective evidence and sign-off. | | Functional output | A proven match or a named unresolved exception with an authorised resolution. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations finance/reconciliation workspace; no direct customer control over matches or adjustments. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B07 Ledger and financial accounting](/banking/modules/b07) | B07 is the accounting book; B24 checks that book against other sources. | | [B29 Management and regulatory reporting](/banking/modules/b29) | B24 establishes source/match completeness; B29 reports verified totals and explicitly labels remaining gaps. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Reconciliation analyst; exception maker/checker; finance. Access to these duties requires the approved institution permission matrix. The bank or authorised regulated entity owns product policy and financial outcomes. Platform operators receive no automatic customer-data, fund-movement or issuer authority. ## Worked Indian example Use the four stages below to distinguish the initial facts, the action to test, confirmed completion and the alternate result. This example exercises this module’s responsibility; related modules still own the handoffs listed above. **Fictional requirements illustration, not seeded data or approved banking policy.** Reference: RECON-001 / three-source comparison. | Stage | Example | | - | - | | Starting situation | The ledger contains INR 1,000.00, the processor clearing contains INR 1,000.00, but the complete settlement source has no matching item. | | Operator/customer actions | Validate file completeness/control totals, open an exception and investigate timing/reference before approving any adjustment. | | Expected normal outcome | Sign-off remains incomplete until an explained reconciled result exists. | | Failure or alternate outcome | An empty/truncated settlement file is not proof that every transaction failed. | No real customer, regulator approval, provider connection or bank operation is asserted. Illustrative amounts have currency INR and scale 2; actual economics/authority must be supplied by the institution. ## Module flow diagrams Read each flow from top to bottom. Rectangles are actions or recorded outcomes; diamonds are decisions; labelled arrows show the next permitted route. The denial route stops the operation. The pending/unknown route keeps the original reference for investigation instead of claiming success. Each diagram corresponds to the numbered journey below. Planned workflows are shown below. Execution depends on confirmed institution policy and interface contracts. ### Flow 1: Load complete source batches to prove reconciled totals ```mermaid theme={null} flowchart TD START["B24-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Load complete source batches"] N0 --> N1 N1["validate counts/totals"] N1 --> CHECK{"Sources complete and matching rules approved"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N2 N2["match deterministic keys"] N2 --> N3 N3["investigate exceptions"] N3 --> N4 N4["approve correction"] N4 --> N5 N5["prove reconciled totals"] N5 --> RESULT RESULT{"Completion evidence verification"} RESULT -->|Yes| DONE["Record outcome, audit and return"] RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"] HOLD --> REVIEW["Authorised resolution; no blind retry"] ``` ### Flow 2: Missing settlement file to resolve residual exceptions ```mermaid theme={null} flowchart TD START["B24-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Missing settlement file"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["mark incomplete"] N1 --> N2 N2["block false sign-off"] N2 --> N3 N3["obtain source"] N3 --> N4 N4["rerun idempotently"] N4 --> N5 N5["resolve residual exceptions"] N5 --> RESULT RESULT{"Outcome verification"} RESULT -->|Yes| DONE["Record outcome, audit and return"] RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"] HOLD --> REVIEW["Authorised resolution; no blind retry"] ``` ## Required features Planned functionality is listed below. Implementation requires confirmed field definitions, permissions, state transitions and product economics for the selected offering. | Feature | What the user or service does | Completion evidence | | - | - | - | | B24-F1: Instruction-to-ledger-to-provider matching | Compare adopted identifiers, amount/currency, status and timing across instruction/book/provider. | A match references every required source record. | | B24-F2: Bank/network/escrow statement ingestion with completeness | Validate statement coverage and batch control totals before matching. | Missing/truncated sources cannot make a batch appear fully reconciled. | | B24-F3: Duplicate, missing, amount and timing exceptions | Classify duplicate, missing, amount and timing differences with owner and age. | The exception queue retains the original evidence. | | B24-F4: Controlled adjustments and evidence-based closure | Approve necessary linked adjustments through the financial owner. | Closure includes confirmed correction references and a resolved comparison. | | B24-F5: Operational sign-off and ageing dashboards | Sign off reconciled coverage and display open exceptions/ageing. | Totals distinguish matched, unresolved and missing-source populations. | ## Required configuration Sources; matching keys; date/currency; tolerance; completeness; exception owners; write-off limits. Store approved values in versioned, effective-dated product/programme policy. Capture the exact configuration version used by an instruction. Missing mandatory configuration blocks the dependent action; enabling a menu cannot grant legal authority. ## End-to-end journey 1 Load complete source batches → validate counts/totals → match deterministic keys → investigate exceptions → approve correction → prove reconciled totals. The journey ends only when its authoritative result, customer/staff-visible result and related book or case history agree. A saved request, queue entry or HTTP acknowledgement is an intermediate state. ## End-to-end journey 2 Missing settlement file → mark incomplete → block false sign-off → obtain source → rerun idempotently → resolve residual exceptions. Every transition needs an authorised actor, original version and recorded reason where required. Cancellation or client disconnection does not prove server rollback. Financial corrections retain their original reference and use linked reversal/adjustment entries rather than deleting history. ## Interfaces and data dependencies Complete statements; control totals; bank/network finality; journal references; adjustment approval. Agree stable institution, product, party and operation references; source version; as-of time; completeness; status/finality; retry rules and correction handling. Where no financial posting occurs, record the administrative/case outcome instead of inventing a journal. All channel requests use server-verified identity and institution scope. Partner, branch and customer access is narrower than institution membership. Lists, details, search, exports, callbacks and files must enforce the same boundary. ## Current implementation and reuse **New Banking project: proposed, not built.** No financial reconciliation engine exists. Reviewed legacy feature boundaries: `source-clients`, `source-activity (ingestion foundations only)`. See the source inventory on the [gap page](/banking/current-system-gap). Legacy feature presence is a reuse candidate, not acceptance or deployment evidence for this module. ## Acceptance criteria and exception scenarios Explicit cases: Truncated file; duplicate batch; holiday date mismatch; same reference different currency. * Allowed success: confirm saved/output values, authoritative status and the exact approved actor/channel. * Denial: reject foreign institution, unauthorised branch/customer/programme and revoked or expired access without information leakage. * Reliability: prove stale-version rejection and concurrency behaviour; retryable commands apply one economic effect; unknown financial outcomes are reconciled by original reference. * Records and usability: preserve redacted audit, monetary precision and document integrity; verify keyboard/mobile, direct links, expired sessions, Back/Forward and return navigation. Internal web navigation preserves its workspace. Apply the [scenario matrix](/banking/scenario-matrix) and the [shared journey rules](/banking/journeys). Timing, amounts and regulatory applicability are institution-owned inputs, not defaults supplied by this document. ## Required implementation inputs **Status: Pending institution confirmation.** Required reconciliation sources, completeness/control totals and adjustment approval authority. Implementation dependencies and approvals are recorded in the [decision register](/banking/decisions). [Module register](/banking/module-register) · [Offering compatibility](/banking/offering-matrix) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.