> ## 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. # B07 Ledger and financial accounting > Maintain balanced, traceable books or integrate a clearly designated external system of record. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility The ledger is the authoritative accounting record of financial effects. Double entry records balanced debits and credits for each posting. Available balance additionally considers reservations; a displayed balance must state which book and holds it uses. | Attribute | Module definition | | - | - | | Entry condition | An approved financial instruction needs posting, reservation, correction or period close. | | Owned records | Journal, posting lines, balance reservation and accounting period. | | Functional output | A balanced, uniquely referenced financial effect or a pending/rejected posting. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Shared financial services; Banking Operations finance views for authorised posting/period work. Customer channels receive permitted statements, not ledger-edit access. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B24 Reconciliation and exception management](/banking/modules/b24) | B07 records the financial effect; B24 proves it matches external instructions and settlement evidence. | | [B31 Business date EOD and scheduled operations](/banking/modules/b31) | B31 schedules a close/accrual cycle; B07 owns the posting and accounting-period controls. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Finance maker; finance checker; accountant; auditor. 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: JRN-001 / illustrative INR 1,000.00 cash deposit. | Stage | Example | | - | - | | Starting situation | The chosen owned-ledger option receives confirmed cash-deposit evidence. | | Operator/customer actions | Post equal INR 1,000.00 amounts: debit cash asset and credit customer deposit liability, linked to one operation and business date. | | Expected normal outcome | The journal balances; customer deposit liability increases once. In external-core mode, its authoritative journal is referenced instead of double-posted. | | Failure or alternate outcome | A replay returns the existing effect; an unbalanced journal is rejected. | 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: Receive accepted financial event to expose ledger and available balances ```mermaid theme={null} flowchart TD START["B07-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Receive accepted financial event"] N0 --> N1 N1["validate account/period/currency"] N1 --> CHECK{"Balanced, unique and valid-period event"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N2 N2["generate balanced journal"] N2 --> N3 N3["commit once"] N3 --> N4 N4["expose ledger and available balances"] N4 --> 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: Discover incorrect posting to retain both entries ```mermaid theme={null} flowchart TD START["B07-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Discover incorrect posting"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["identify original journal"] N1 --> N2 N2["approve linked reversal/correction"] N2 --> N3 N3["reconcile downstream balances"] N3 --> N4 N4["retain both entries"] N4 --> 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 | | - | - | - | | B07-F1: Double-entry journals and product subledgers | Post linked balanced entries under the adopted chart and subledger mapping. | Each accepted journal balances in its defined currency/valuation context. | | B07-F2: Available/ledger balance and reservation semantics | Track ledger balance and reservations atomically under adopted availability rules. | Concurrent instructions cannot spend the same available funds twice. | | B07-F3: Fees, interest, tax and suspense postings | Post approved fees, interest, tax and unresolved amounts to their designated accounts. | Each component links to its calculation/terms and original instruction. | | B07-F4: Controlled reversal, adjustment and back-valued posting | Correct financial facts with linked reversals/adjustments and period authority. | Original entries remain intact and the correction’s economic effect is traceable. | | B07-F5: Trial balance, period close and immutable financial history | Validate trial-balance totals and close periods with authorised sign-off. | Closed-period history is retained and back-valued changes follow adopted controls. | ## Required configuration Chart of accounts; subledger ownership; currencies; valuation; posting templates; period controls; rounding. 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 Receive accepted financial event → validate account/period/currency → generate balanced journal → commit once → expose ledger and available balances. 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 Discover incorrect posting → identify original journal → approve linked reversal/correction → reconcile downstream balances → retain both entries. 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 Owned ledger or external posting/read contract; atomicity; exact money; reconciliation and finality. 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 operational ledger exists. Imported transaction history is not a posting engine. Reviewed legacy feature boundaries: `transaction-history (read history 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: Unbalanced journal; duplicate event; concurrent debit; closed period; rounding residue. * 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.** Authoritative book, chart of accounts, posting rules and period-reopening 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.