--- updatedAt: 2026-05-04T15:53:20.000Z --- Fetch the complete documentation index at: https://developers.pismo.io/pismo-docs/llms.txt. Use this file to discover all available pages before exploring further. Append .md to any documentation page URL to get its markdown version. # Back-value-dated transactions Back-value-dated transactions are essential for maintaining accurate account balances. They play a crucial role in adjusting account values to correct errors, provide timely compensation to customers, and meet regulatory requirements. By ensuring that the back-value-dated balance accurately reflects the correct payment date, even if the transaction was processed later, these transactions help maintain the integrity of financial records and ensure compliance with regulations. # Objectives of back-value-dated transactions Banks use back-value-dated transactions for the following reasons. * **Correcting errors**: Banks use back-value-dated transactions to rectify processing mistakes by adjusting the funds to the correct date. For example, if a bank erroneously credits USD 100 to a customer's account on the 1st of the month, but the payment was actually made on the 15th of the previous month, the bank can back-value-date the funds to the 15th to ensure that the account balance is correct. * **Customer compensation**: Banks sometimes back-value-date transactions to compensate customers for processing delays. For example, if a bank takes two weeks to process a payment, it might back-value-date the funds to the original payment date. This compensates the customer for the lost interest they would have earned if the funds had been available sooner. * **Regulatory compliance**: Regulatory requirements might mandate that banks back-value-date transactions. For example, in the United States, banks are required to back-value-date funds if a processing error occurs to ensure that customer balances are accurate. # How to post a back-value-dated transaction Use the [Post payment](https://developers.pismo.io/pismo-docs/reference/corporate-v2-post-payments) or the [Post multi-leg payment](https://developers.pismo.io/pismo-docs/reference/corporate-v2-post-multileg-payments) endpoint to post a back-value-dated transaction by setting the `payment_datetime` field to the past date. After posting, balance history events are generated for all days affected by the balance adjustment. No clearing process is needed. **Notes** * If the administrative division of the account has the `skip_cycle_closing` parameter set to `true`, no balance history is sent on non-business days or holidays. * If the `deny_value_date` parameter is true and the `payment_datetime` falls on a non-business day or holiday, the transaction is denied. * For details about `skip_cycle_closing` and `deny_value_date`, refer to the [Parameters](https://developers.pismo.io/pismo-docs/docs/posting-transactions-on-holidays#parameters) section of *Posting transactions on holidays*. * Before performing back-value-dated transactions, ensure you check the number of days specified in the `retroactive_payment_time_restriction` field of [Create acceptance configuration by Org](https://developers.pismo.io/pismo-docs/reference/post-acceptance-by-tenant). The transactions are processed based on the date you provided. # Impact on account balances When back-value-dated transactions occur, account balances are adjusted accordingly. This has the following results. * The account balance is higher if funds received are back-value-dated. * The account balance is lower if funds paid are back-value-dated. This adjustment happens because the interest earned or owed on the account is **recalculated**, as the **value-dated balance is adjusted for a longer period of time**. This process is closely linked to the management of balance history and the bank's end-of-day procedures. The effects on various types of balances are detailed in the following table. | Balance type | Description | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Ledger balance | The ledger balance is the balance at the close of the business day, carried forward to the next business day. It is shown in statements as the **running balance** and is calculated as the book balance for the current date, plus any uncleared funds. When a transaction is back-value-dated, the ledger balance is adjusted online to reflect the back-value-dated credit or debit. | | Available balance | The available balance is the amount of money immediately accessible to the account holder. It’s used to validate new transactions. When a transaction is back-value-dated, the available balance is adjusted online to reflect the back-value-dated credit or debit. | | Book balance | The book balance is the total amount of money in the account, **excluding earmarked or hold funds and uncleared funds**. When a transaction is back-value-dated, the book balance is adjusted online to reflect the back-value-dated credit or debit. | | Value dated balance | Back-value-dated transactions affect the back-value-dated balance of the account for the past date when the transaction was posted. Subsequent balances must be recalculated according to the new back-value-dated balance from that day to the present. During this process, balance events are issued to indicate the adjustments or corrections. | ## Examples Here are some examples of how you use back-value-dated transactions in different scenarios. | Scenario | Description | | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Error correction | A bank mistakenly debits USD 100 from a customer's account on August 15th. On August 16th, the bank corrects the error by back-value-dating the transaction to July 31st, adjusting the customer's balance accordingly. | | Refund processing | A customer receives a USD 450 refund on May 30th. The bank processes the refund on June 7th with a back-value date of May 30th, compensating the customer for the processing delay. | | Compensation | On September 15th, a bank compensates a customer USD 150 for an error made on August 1st by posting a payment backdated to August 1st. | | Late settlement | A bank receives a trade-related payment of USD 550,000 one day late on August 15th, instead of August 14th. The funds are credited and an interest claim is generated for the delay. | # Rules for performing a back-value-dated transaction Here are the key rules to remember when you perform back-value-dated transactions. | Rule | Description | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Configurable days | The number of days allowed for back-value-dated transactions can be configured in the payments settings. | | Balance history events | Balance history events are generated for all days affected by the balance recalculations when you set `trigger_reason` to `BACK_VALUE_DATED_OPERATION` or `BACK_VALUE_DATED_OPERATION_CURRENT_DATE` | | Calendar and holidays - cycle closing | If `skip_cycle_closing` is `true`, no balance history is sent on non-business days or holidays. | | Calendar and holidays - deny value date | If `deny_value_date` is set to `true` and the `payment_datetime` is a non-business day or holiday, the transaction is denied. | | Custom rejection rules | If `reject_back_value_dating` is `true` and the provided `payment_datetime` back‑values the payment, the Pismo platform rejects the transaction. |