# Value Date vs Booking Date vs Entry Date on a Bank Statement Source: https://gravam.com/blog/value-date-vs-booking-date-vs-entry-date Author: Tan Gravam Published: 2026-10-04 Reviewed: 2026-10-04 Summary: Value date, booking date and entry date on a bank statement: what each means, where it sits in camt.053, MT940 and BAI2, and which date your cash position uses. **The booking date is when the bank posts an entry to the account on its books; the value date is when the money becomes available to you on a credit, or stops being available on a debit. "Entry date" is the MT940 name for the booking date — the optional second subfield of the `:61:` line.** The textbook version ends there: three terms, two concepts. The reality is that the three statement formats carry these dates in three different shapes — camt.053 as two optional XML elements, MT940 as two dates of unequal length fused into one string, BAI2 as a file-level date plus an optional value date buried in a composite field — and that every system downstream has to choose one of them for each purpose. Verified against ISO's Message Definition Report, BAI's specification and bank implementation guides. ## The three terms side by side | Term | What it means | camt.053 / 052 / 054 | MT940 | BAI2 | | --- | --- | --- | --- | --- | | Booking date | When the entry is posted to the account on the bank's books | `` on the entry, `[0..1]` | `:61:` subfield 2, "entry date" | No per-transaction field; the group's as-of-date | | Value date | When the funds become available to the account owner (credit) or cease to be available (debit) | `` on the entry, `[0..1]` | `:61:` subfield 1, mandatory | Funds type `V` followed by a value date, on the 16 record | | Entry date | MT940's term for the booking date | Not a camt term | `:61:` subfield 2, `[4!n]` MMDD, optional | Not a BAI2 term | | Availability | When a booked amount becomes accessible, where float applies (cheques, typically US) | `` on the entry, `[0..*]` | Not on the `:61:` line | Funds types `0`, `1`, `2`, `S`, `D` | The definitions in the second column are ISO 20022's, from the Message Definition Report; MT940 and BAI2 use the same ideas with less formal wording. If you are still choosing between the formats, the [MT940 vs camt.053 vs BAI2 comparison](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) is the place to start. ## camt.053: BookgDt and ValDt on the entry In ISO 20022 both dates are elements of the entry (``), and both are optional. The report defines them like this: - **BookingDate ``, `[0..1]`** — "Date and time when an entry is posted to an account on the account servicer's books." The usage note adds that it is the _expected_ booking date unless the entry's status is booked, in which case it is the actual one. - **ValueDate ``, `[0..1]`** — "Date and time at which assets become available to the account owner in case of a credit entry, or cease to be available to the account owner in case of a debit entry." If the entry is pending, a value date present is an expected or requested one. Each is a choice between a plain date (`
`) and a date-time (``). An illustrative entry, cut down to the relevant elements (not a complete or valid instance): ```xml 12500.00 CRDT BOOK
2026-10-01
2026-10-02
 ``` Three things to know before you map them: - **Optional in the schema.** Nordea's camt.053.001.02 guide keeps both at `[0..1]` with a plain ISO date. Whether your bank always sends both is a question for its implementation guide; the rest of the entry is in the [camt.053 field-by-field walkthrough](https://gravam.com/blog/camt-053-structure-and-fields). - **The same component in all three messages.** The 2020–2021 report lists `` and `` at the same multiplicity on the entry of camt.052, camt.053 and camt.054. What changes is the status: the statement contains booked entries only, while the [intraday camt.052](https://gravam.com/blog/camt-052-intraday-account-report-vs-mt942) and the [camt.054 notification](https://gravam.com/blog/camt-054-notification-explained) may report pending items, where both dates are expectations. - **Availability replaces value date under float.** ISO's rule: "For entries subject to availability/float and for which availability information is provided, the value date must not be used." The `` block then says when the booked amount "can be accessed and starts generating interest", as a number of days or an actual date. ISO describes this as US usage tied to instruments such as cheques. ## MT940: value date first, entry date second MT940 packs both dates into the head of the `:61:` statement line. Per Nordea's service description, subfield 1 is **Value Date**, `6!n`, YYMMDD; subfield 2 is **Entry Date**, `[4!n]`, glossed as "Booking date (MMDD)". The square brackets mean optional. The same order, illustratively: ```text :61:2610021001C12500,00NTRFINV-4471//BANKREF123 │ │ │ │ │ └ C = credit │ └ 1001 = entry date, 1 October (MMDD — no year) └ 261002 = value date, 2 October 2026 (YYMMDD) ``` The traps follow directly from that layout: - **The value date comes first.** Anyone who assumes "the first date is when it happened" reads the line backwards. - **The entry date has no year.** Four digits, month and day. The year has to be inferred from the statement's own dates, and a line whose value date and entry date fall on opposite sides of 31 December is where a naive "same year as the value date" rule breaks. - **The entry date may be absent.** HSBC's usage guideline shows the base message at `[0..1]` for the entry date and restricts it to `[1..1]` for HSBC's own statements. So some banks always send it and the format doesn't oblige them to. If it is missing, the format gives you no separate booking date; what your parser assumes in its place is your decision, and it should be a written one. - **Either date can be the earlier.** Nordea's own sweep example reads `:61:0509070908D…`: value date 7 September, entry date 8 September. That is a back-valued entry. The mirror case, booked today and valued later, is a forward value. SWIFT's own field specification sits behind the user handbook, so its formal definition of the entry date is not quoted here; the subfield positions above are the ones both bank guides print. The other seven subfields are in the [MT940 tag-by-tag guide](https://gravam.com/blog/mt940-format-tags-explained). ## BAI2: an as-of-date, and a value date through the funds type BAI2 has no booking date on the transaction. The 16 transaction detail record carries a type code, an amount, a funds type, two references and text — no date of its own. The date lives one level up: the 02 group header carries the **as-of-date** (YYMMDD, "originator date"), and every account and transaction in the group is reported as of it. A value date appears only through the funds type. When the funds type is `V`, the next two fields are value date (YYMMDD) and value time, and BAI defines the value date as "the date the originator makes funds available to the customer". Illustratively: ```text 02,RECEIVER,ORIGINATOR,1,261001,,USD,2/ └ as-of-date: 1 October 2026 16,195,1250000,V,261002,,BANKREF123,INV-4471,/ │ └ value date: 2 October 2026 (value time defaulted) └ funds type V = value dated ``` Two traps: - **At some banks, no `V` means "same day", not "unknown".** HSBC's guide says it leaves the funds type at its default when value date, posting date and reporting date are the same, and uses `V` when they differ. That is one bank's convention; the specification's default is `Z`, unknown. - **Back-valuation is handled differently.** BAI's specification says value dates before the as-of-date "are not prohibited but are discouraged", that such records "should be processed as if the value date was equal to the As-of-Date", and that prior value dates must not be used to adjust availability. A back-valued entry that MT940 would show with its true value date is flattened here by rule. The other funds types (`0`, `1`, `2`, `S`, `D`) express availability in days — the same float idea as ISO's ``. Record layouts are in the [BAI2 file format guide](https://gravam.com/blog/bai2-file-format-explained). ## Which date to use for what The formats define the dates. They don't tell you which one to use. That part is practice, and I mark it as such: - **Cash position and forecast: value date (practice).** A position answers "what is available on this day", which is what the value date records. A forward-valued credit belongs in tomorrow's column of a [daily cash position](https://gravam.com/blog/how-to-build-a-daily-cash-position), even though it sits on today's statement. - **Reconciliation and the ledger posting: booking date (practice).** The statement's balances move on the day the bank booked the entry, so that is the day the entry has to be matched and explained. Which date becomes the posting date in your ERP is configuration, not a property of the format. - **Interest and overdraft: value-dated balances (practice, governed by contract).** The specifications point the same way — ISO ties availability to when money "starts generating interest", and Nordea describes the `:64:` closing available balance as "the balance subject to interest charges (if debit balance)". But the actual calculation basis is in your account agreement, not in any statement format, and I haven't verified it against one here. One sourced SAP point. For bank statements integrated into One Exposure, SAP's S/4HANA 1610 documentation states that "the transaction date and amount are determined based on the bank statement item and bank statement value date": in its example a statement dated 24.02.2016 with an item valued 23.02.2016 produces one flow dated the 23rd (incoming bank cash) and two dated the 24th that move it to confirmed bank cash — the value date dates the bank-cash flow, the statement date the confirmation. That page describes statements integrated directly into One Exposure. How the [electronic bank statement posting rules](https://gravam.com/blog/sap-ebs-posting-rules-and-interpretation-algorithms) derive the document's posting date, and which fields of the statement tables hold each date, are not verified in this post. ## What goes wrong in practice The patterns I see repeat, whatever the bank or system: - **One "date" column.** The import maps a single transaction date and nobody recorded which one it was. Every later disagreement between the position and the ledger starts there. - **A position that doesn't tie to the statement.** A position built on value dates will not equal the booked closing balance on any day with back- or forward-valued entries. That is correct, and it needs explaining once, in writing, before someone "fixes" it. - **Back-valued entries landing in closed days.** A late correction with a value date last week changes a past day's value-dated balance. The interest follows it; so do [sweeps in a cash concentration structure](https://gravam.com/blog/cash-concentration-sweeping-and-zba). A report that only ever looks at today never shows it. - **The year-end MT940 line.** Parsers that borrow the year for the entry date pass eleven months of testing and fail in the first week of January. - **A migration that changes the meaning silently.** Moving from MT940 to camt.053, or adding a BAI2 bank, changes which dates are present and how back-valuation is represented. If the mapping document says "date → date", the difference surfaces later as a reconciliation break. The fix is the same in each case: carry both dates through the interface under their own names, decide per use which one applies, and write the decision down where the next person will find it. ## Primary sources BookingDate, ValueDate and Availability definitions and multiplicities verified against ISO's Message Definition Report for Bank-to-Customer Cash Management (camt.052/053/054.001.09, Maintenance 2020-2021, in the draft published for evaluation in December 2020) and Nordea's camt.053.001.02 MIG; the MT940 :61: subfields against Nordea's MT940 service description and HSBC's MT940 usage guideline (SR 2013), because SWIFT's own specification sits behind the user handbook; the BAI2 funds type and as-of-date against BAI's Version 2 specification and HSBC's BAI2 guide; the SAP statement against SAP's One Exposure documentation for S/4HANA 1610. Which date drives interest is contractual and is marked as practice, not specification. - ISO 20022 — Message Definition Report Part 2, Bank-to-Customer Cash Management, Maintenance 2020–2021, draft for evaluation (camt.052/053/054.001.09: Entry BookingDate, ValueDate, Availability) — accessed 2026-10-04 — https://www.iso20022.org/sites/default/files/2020-12/ISO20022_MDRPart2_BankToCustomerCashManagement_2020_2021_v1_ForSEGReview.pdf - Nordea — Corporate eGateway MIG camt.053.001.02 BankToCustomerStatementV02 (v1.9, 2023) — accessed 2026-10-04 — https://www.nordea.com/en/doc/nordea-mig-camt-053-001-02-bank-to-customer-statement.pdf - Nordea — Account Statement Service MT940 file description — accessed 2026-10-04 — https://www.nordea.com/en/doc/2010-05-31accountstatementservicemt940en.pdf - HSBC — Usage Guideline HSBC_MT940_CustomerStatementMessage_Core (SR2013) — accessed 2026-10-04 — https://www.hsbcnet.com/-/media/hsbcnet/client-transition/mt940-ir-specs.pdf - BAI — Cash Management Balance Reporting Specifications, Version 2 (Technical Reference Manual, 10/2005) — accessed 2026-10-04 — https://cdn.bai.org/migrated-from-www/docs/default-source/libraries/site-general-downloads/cash_management_2005.pdf - HSBC — BAI2 Statement Message Implementation Guide, Version 1.5 — accessed 2026-10-04 — https://www.hsbcnet.com/-/media/hsbcnet/client-transition/bai2-ir-specs.pdf - SAP Help — Integration of Bank Statements (One Exposure from Operations, SAP S/4HANA 1610) — accessed 2026-10-04 — https://help.sap.com/doc/a0a0b752bf730226e10000000a4450e5/1610%20002/en-US/0bddfa562f4fff7de10000000a441470.html ## Questions this article answers **Q: What is the difference between value date and booking date?** The booking date is when the bank posts the entry to the account on its own books; the value date is when the money becomes available to the account owner on a credit, or stops being available on a debit. Those are ISO 20022's definitions of BookingDate and ValueDate on a statement entry. The two are often the same day, but an entry can be booked today with a value date in the past (back-valued) or in the future (forward-valued), and when they differ the booked balance and the value-dated balance of the account differ too. **Q: What is the entry date on a bank statement?** Entry date is the MT940 name for the booking date. In the :61: statement line it is subfield 2, four digits in MMDD form, placed directly after the six-digit value date; Nordea's MT940 description glosses it as 'Booking date (MMDD)'. It is optional in the base format and carries no year, so a parser has to infer the year from the statement's own dates. camt.053 calls the same thing BookingDate, and BAI2 has no per-transaction equivalent at all. **Q: Which date should a cash position use, value date or booking date?** Value date, by established treasury practice, because a position answers what cash is available on a given day, and availability is what the value date records. Booking date answers a different question: which day's statement an entry belongs to, and therefore what you reconcile against the ledger. The formats define the dates; they do not prescribe which one your position uses, so this is a design decision to make explicitly rather than inherit from a field mapping. **Q: Which date does SAP use for the cash position?** For bank statement items integrated into One Exposure, SAP's documentation for S/4HANA 1610 says the transaction date and amount are determined from the bank statement item and its value date, and its example creates a bank-cash flow on the item's value date and, on the statement date, the flows that convert it to confirmed bank cash. That page covers statements integrated directly into One Exposure; how posted statement items reach the position through accounting documents, and the field-level mapping in the bank statement tables, are not verified in this post.