Booking date and value date: keep both in a bank statement export

Keep booking date and value date in separate columns whenever the statement provides both. Do not replace one with the other to fill gaps. Value date relates to interest calculation; the document’s own labels determine how to map its other transaction dates.

Which date belongs in each output field?

Build the mapping before joining pages or changing types. These are proposed field names, not a universal bank export specification.

Printed information	Suggested working field	Preserve or clarify
Date when the bank records the entry, if defined	Booking date	Confirm the bank’s definition
Value date	Value date	Keep its interest-related meaning
Purchase date inside a card description	Description; optional purchase-date field	Do not overwrite booking date
Statement issue date in the heading	Statement metadata	Do not repeat as every transaction date
Undocumented “Date” heading	Raw date plus unresolved mapping	Consult the bank’s document guide

A transaction can therefore have several dates without being several transactions. The useful output keeps each meaning traceable. If a native bank CSV already supplies documented booking and value dates, it can save the reconstruction work; compare it with the same account and period before choosing it.

Practical method

Copy each date heading exactly into your source notes, then assign clear output names. Preserve the original date strings alongside parsed dates.
Choose the date used by the intended report or import template explicitly. Keep the other date as supporting information rather than discarding it.
Flag missing or conflicting dates. Sort only after retaining the original row index, so you can reconstruct the printed sequence.

Fictional example

A fictional row has booking date 2026-10-31, value date 2026-11-02 and debit 18.00. A report grouped by booking month places it in October; a report grouped by value month places it in November. The amount has not changed. Giving both output columns the name ‘date’ conceals this difference and makes month-to-month comparisons misleading.

Map the heading, not the column position

Create a small mapping note with three items for each output field: the exact printed heading, your chosen field name and the reason for the match. Do not assume that the leftmost date is always the booking date. “Transaction date” may require clarification from that bank’s statement guide; it is not a licence to rename it automatically. If a separate purchase date appears in the description, keep it as descriptive evidence rather than silently moving it into the booking field.

The Banca d’Italia glossary distinguishes an operation date and a value date. That supports keeping date meanings separate, but it does not resolve every bank’s headings. If your bank offers a native export with defined headings, compare those definitions with the PDF before doing manual remapping. Prefer the defined export when it already satisfies the task.

Check the month boundary without changing the transaction

For the fictional 18.00 debit, prepare two labelled views of the same row: booking-month October and value-month November. The number of transactions and overall debit total must remain one and 18.00 in both views. Only the month allocation changes. Do not combine the views as if they were two different transactions.

If the target requires a booking date but that source field is absent, retain a missing-value flag and resolve the requirement with the receiving workflow. Do not duplicate the value date simply to make the file pass an import check. Keep a date-only value as a date; adding an invented time does not supply missing evidence. Finally, verify the exported date and column heading in the import preview, not only their appearance in your working spreadsheet.

A three-row month-end check

All following dates and amounts are invented, in EUR for one account. Row A is a debit of 18.00, booked on 31 October and valued on 2 November. Row B is a credit of 50.00, booked and valued on 31 October. Row C is a debit of 7.00, booked and valued on 2 November. On booking dates, October’s net movement is +32.00 and November’s is −7.00. On value dates, October is +50.00 and November is −25.00. Both views total +25.00 over the two months and contain three transactions.

This is a practical check for a mixed date column. If only row A accidentally uses value date while other rows use booking date, the general total can remain correct while the monthly report changes. Label each view with its date basis and keep the same source-row IDs, so the reader can tell a regrouping from an additional payment. The example describes spreadsheet grouping; it does not decide financial reporting recognition or a tax period.

Prepare a one-date import without destroying the other date

Read the receiving application’s definition of its date field before mapping it. Record whether it expects a booking date, a value date or another documented date. Then create a dedicated delivery sheet containing that selected date, while keeping both source dates in the review workbook. A single output column is a destination constraint, not permission to treat the dates as equivalent.

Test a row with different dates and a row with a missing date in the import preview. If the required source date is missing, obtain clarification or disclose that the import is incomplete; a copied alternative date must not masquerade as an observed value. Also check that sorting has not detached a date from its description and amount. Date interpretation is a separate issue from date meaning: use the bank CSV date-format checks if day and month are ambiguous.

Checks and limits

Test a row where the dates differ, not just rows where they match. Document the chosen reporting date in the sheet heading. If the receiving application accepts only one date, consult its import specification before deciding. This mapping guide does not determine accounting periods or calculate interest.

Keep the original file unchanged and record any unresolved item before using the table.

State which date column and sign convention the balance check uses. Debit and credit columns to one signed amount: a bank CSV method · Check a bank statement balance without hiding extraction errors.

BankStatementScan is in preparation. The site offers an access request and a fictional example; it does not currently convert your bank files. See the planned service.

Sources consulted on 16 October 2026

Banca d’Italia — Estratto conto.