> ## 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. # B31 Business date EOD and scheduled operations > Run financial and operational cycles exactly once per institution business date with controlled restart. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Business-day operations coordinate dated jobs and controlled close/open cycles. The institution’s business date can differ from the clock/calendar date. Scheduling a job is separate from the product module’s calculation and ledger posting. | Attribute | Module definition | | - | - | | Entry condition | An adopted cutoff is reached, a due job runs or an interrupted close needs resumption. | | Owned records | Business calendar, cycle/run, dependency checkpoint and sign-off. | | Functional output | A verified completed business-date cycle or a blocked run with recoverable checkpoints. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations business-day control workspace; background services execute adopted dated jobs. 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) | B31 coordinates close dependencies; B07 validates the accounting entries/period. | | [B14 Loan servicing and repayment](/banking/modules/b14) | B31 invokes due loan jobs; B14 owns schedule/accrual/repayment calculations. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Operations controller; finance reviewer; job operator. 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: RUN-001 / accrual batch interrupted. | Stage | Example | | - | - | | Starting situation | The adopted EOD job stops after posting 700 of 1,000 eligible account units. | | Operator/customer actions | Recover the checkpoint, verify posting references, process only remaining eligible units and reconcile counts/totals. | | Expected normal outcome | Exactly 1,000 intended units have one accepted effect each; close advances only after required controls pass. | | Failure or alternate outcome | Rerunning all 1,000 without idempotency would duplicate 700 units and must fail acceptance. | 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: Reach cutoff to advance business date ```mermaid theme={null} flowchart TD START["B31-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Reach cutoff"] N0 --> CHECK{"Inputs, checkpoint and business date valid"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["validate prerequisites"] N1 --> N2 N2["run dependency-ordered jobs"] N2 --> N3 N3["reconcile counts/totals"] N3 --> N4 N4["resolve exceptions"] N4 --> N5 N5["approve close"] N5 --> N6 N6["advance business date"] N6 --> 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: Crash halfway to resume close ```mermaid theme={null} flowchart TD START["B31-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Crash halfway"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["recover checkpoint"] N1 --> N2 N2["rerun only idempotent unfinished units"] N2 --> N3 N3["verify no duplicate interest/posting"] N3 --> N4 N4["reconcile"] N4 --> N5 N5["resume close"] 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 | | - | - | - | | B31-F1: Institution business-date and holiday management | Record institution calendar, cutoffs and business-date transition authority. | Channels can identify which business date an instruction uses. | | B31-F2: EOD/BOD dependency graph and checkpoints | Run End of Day/Beginning of Day dependencies with durable checkpoints. | No date advance occurs with unresolved required prerequisites. | | B31-F3: Interest, billing, maturity and standing-instruction jobs | Invoke approved product accrual/billing/maturity/payment jobs for their original date. | Each job links to one adopted calculation/posting result. | | B31-F4: Failed-run diagnosis and safe resume | Diagnose failures and resume confirmed unfinished steps without repeating completed effects. | Recovery evidence shows exactly which checkpoints resumed. | | B31-F5: Close sign-off, backlog and downstream report readiness | Present backlog/completeness and obtain required close approval before downstream use. | Reports receive an explicit ready, blocked or incomplete cycle status. | ## Required configuration Timezone; business calendar; cutoff; dependencies; accrual/billing schedules; lock policy; rerun permissions. 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 Reach cutoff → validate prerequisites → run dependency-ordered jobs → reconcile counts/totals → resolve exceptions → approve close → advance business date. 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 Crash halfway → recover checkpoint → rerun only idempotent unfinished units → verify no duplicate interest/posting → reconcile → resume close. 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 Authoritative clock/calendar; job inputs; ledger posting; control totals; operator approvals. 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 EOD/BOD scheduler or business-date engine exists. Reviewed legacy feature boundaries: No operational source module was found. Legacy feature presence is a reuse candidate, not acceptance or deployment evidence for this module. ## Acceptance criteria and exception scenarios Explicit cases: Holiday rollover; duplicate scheduler; partial batch; failed accrual; leap day; backdated event after close. * 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.** Business-day cycles/cutoffs and failure conditions that block business-date advancement. 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.