A bank statement is a detailed summary of an account’s transactions and balances for specific business dates. These statements are directly tied to "cycles," which define the start and end dates for recording activity. On the Pismo platform, cycles are automated so that as soon as one closes, the next one automatically begins, ensuring a continuous record.

Cycle closing

Cycle closing is the Pismo platform's process for marking the operational end of the day for accounts. Unlike traditional "End of Day" routines that require system downtime, cycle closing enables 24/7 platform operation and continuous transaction processing. At the designated closing moment, the Pismo platform captures a balance snapshot for each account, creating an official record for that business date. This consistent and auditable history is essential for accurate reporting, reconciliation, and interest calculations.

You can configure cycle closing time using the cycle_closing_time field in the Create account balance history configuration endpoint. To update cycle_closing_time, use Update account balance history configuration.

When a cycle closes for an account, three key events occur.

• A balance history event is generated and emitted.
• A new record is created in the balance history table, provided there has been activity or movement in the account.
• The account's balance for that day becomes accessible through the Get account balance history endpoint, if there is any account movement.

Configure cycle closing

You can configure cycle closing at the division or organization level, and each level can follow its own rules. These are the main settings.

• Cycle closing time: Specify the exact time the cycle ends, using the division’s time zone.
• Cycle event delay: Add an optional buffer period before the Pismo platform emits the cycle closing event.

The timezone used for cycle closing depends on where it is configured. For division-level configurations, the Pismo platform first looks for a timezone set for that division. If none exists, it inherits the timezone from the parent division, moving up the hierarchy until one is found. If no timezone is found, it defaults to UTC.

In contrast, cycle closings configured at the organization level always use the organization’s timezone, regardless of the settings in any individual divisions.

Update cycle closing

When you update the cycle closing time, the timing of your request determines when the change takes effect. There are two scenarios.

• Update made before the next cycle validity: If you submit the update before the next cycle validity is scheduled to start, the new configuration takes effect at the very next cycle closing. This change is immediate for the upcoming cycle.
• Update made after the current cycle validity: If you submit an update while the current cycle is already in progress, the new closing time only takes effect after two full cycles have completed. The Pismo platform finishes the current cycle and the following cycle using the existing configuration. After both cycles complete, it applies the updated configuration. This ensures consistent processing across active cycles.

For traceability, the Pismo platform generates an Account balance history configuration changed event every time you update a cycle-closing configuration.

For details about cycle validity, refer to the cycle_config_validity field of Get account balance history configuration.

Skip cycle closing

Skip cycle closing is a feature controlled by a boolean parameter in the administrative division or Create holiday endpoints. When set to true, the Pismo platform bypasses the cycle‑closing process for that division on non‑business days. As a result, the Get account balance history endpoint returns only business days, omitting weekends and holidays. With skip_cycle_closing enabled, any transaction that occurs on a non‑business day is automatically recorded on the next business day, ensuring that both event generation and balance history follow the division’s business calendar.

This configuration is especially useful for back‑value‑dated transactions—transactions posted with a past value date—because balance recalculations and balance‑history events are generated only on business days. This avoids unnecessary entries and maintains consistency with the defined business calendar.

For a list of parameters and how you can use them to configure back- and future-business-dated transactions, including skip_cycle_closing, refer to Posting transactions on holidays.

Trigger reason

The trigger_reason field in the Account balance history generated event indicates the specific condition or action that caused an account balance history event to be generated, providing clear context for why the event was emitted.

You can find a list of trigger reasons and their details in the Account balance history generated event. Here are some trigger reason examples.