Value date

A bank statement usually carries two dates for the same line: the transaction date, when the movement was booked, and the value date, when it starts counting toward the balance. The two separate for ordinary reasons. Instructions given after the daily cut-off, transfers falling on a weekend or a public holiday, movements between foreign currency accounts, and cross-border payments routed through a correspondent bank all push the value date forward by one or more business days. In Türkiye this is visible on nearly every local bank statement, where the domestic transfer types EFT and havale have published cut-off times. Your own ledger, meanwhile, records the payment on the day the instruction was issued. One movement, two systems, two dates, and no error on either side.

In reconciliation, the value date helps you name the kind of difference you are looking at, and one misreading is worth correcting first: a value date shift does not change which statement a movement appears on. Statement lines are listed by transaction date. The value date tells you from which day the amount counts toward interest and the value-dated balance, and from which day the other side can use it. The gap you see at a period boundary comes from a difference in recording dates instead: an instruction given after the daily cut-off is recorded in your ledger on 29 August, while the bank executes it the next business day and books it with a transaction date of 1 September, so the movement sits in your August ledger and in the bank's September statement. Both records are internally correct, and the gap is not an amount discrepancy. To see that, matching has to treat the date as a reasonable window rather than a single day. iFinances places the bank statement next to your ledger records, proposes matches on amount and date proximity, and writes the reason next to every proposal. The decision to close a line stays with a person; iFinances keeps no books and clears nothing on its own.

The most common misreading is treating the value date as the moment the money reached the other party. It is not a delivery timestamp; it is the date the bank includes the amount in its balance and interest calculation, and the counterparty's own credit date can differ again. The second misreading happens while reading the file: matching against the wrong column invents delays, makes settled invoices look unpaid, and fills the exception list with items that were never real. A value date shift is not a reconciliation difference in itself either. It needs no correcting entry, only the knowledge of which column you are reading. Period-boundary gaps, which come from recording dates rather than value dates, close on their own in the opening lines of the next statement, so the real damage comes from leaving them unnamed.