FWIW, just looking at the JSON, it seems that valueDateTime or bookingDateTime provides time data. If they could be used instead, that would certainly be more useful.
In the specific example you shared, there is the issue of valueDate having a different date from valueDateTime, I flagged to the open banking team and will follow up with you separately on this.
Thanks again for taking the time to share the feedback, and keep it coming :D
Maxim
•
Aug 16, 2025
More importantly, I would argue, is the fact that we as private individuals mostly care about when the transaction actually occured. Not when it got booked in the bank’s systems.
Based on transaction data, at least here for DNB in Norway, it seems that the Value Date Time field, is the only one that actually contains the date (and time, but that’s less relevant I feel) of when the transaction actually happened.
This is especially noticeable when the transaction happens during the weekend, when the banks are “closed”.
Here is a perfect example of that from one of my actual transactions:
Actual transaction date: 26.07.2025 (Saturday)
valueDateTime: 26/07/25, 04:53 pm (Saturday) ✅
valueDate: 28/07/25 (Monday) ❌
bookingDate: 28/07/25 (Monday) ❌
So in the above case, valueDateTime, at least the date part of it, is what I would have wanted to be synced to Lunch Money. Because Lunch Money only has a concept of “Date” in all of its tables and views. And that would lead most, I think, to believe that’s the date of the transaction. Especially when you’re in the Transactions view.
Feature Request
Same way as we have Payee and Notes tabs, that allow us great control over what gets sent over to the destination(s), it would be great to have a Date tab that leverages the exact same mechanism that Payee and Notes do, just for a “Date” field.
Where you can either use a drop-down style selection, with the fallbacks to either bookingDate, valueDate, or valueDateTime, in whatever order one pleases.
Or one could then leverage the “Advanced Mode", with Eta templates, to craft custom logic and formatting.
And then, as with any advanced feature, it’s up to the user to ensure that the date(time) format they output, is compatible with their destination.
So, literally, just copy-paste the code for Payee/ Notes tabs in the account configuration, rename it to “Date”, and then just map to the fields that are used for transaction date information in the destination syncs. 😊
Log in to comment and vote
Comments2
Aug 16, 2025
PinnedThank you very much for the detailed feedback, @Maxim .
To summarise our Discord discussion, I have now updated the date field logic to be:
So we:
Prioritize DateTime objects
Prioritize valueDate over bookingDate
In the specific example you shared, there is the issue of
valueDatehaving a different date fromvalueDateTime, I flagged to the open banking team and will follow up with you separately on this.Thanks again for taking the time to share the feedback, and keep it coming :D
Maxim
Aug 16, 2025
More importantly, I would argue, is the fact that we as private individuals mostly care about when the transaction actually occured. Not when it got booked in the bank’s systems.
Based on transaction data, at least here for DNB in Norway, it seems that the
Value Date Timefield, is the only one that actually contains the date (and time, but that’s less relevant I feel) of when the transaction actually happened.This is especially noticeable when the transaction happens during the weekend, when the banks are “closed”.
Here is a perfect example of that from one of my actual transactions:
Actual transaction date: 26.07.2025 (Saturday)
valueDateTime: 26/07/25, 04:53 pm (Saturday) ✅valueDate: 28/07/25 (Monday) ❌bookingDate: 28/07/25 (Monday) ❌So in the above case,
valueDateTime, at least the date part of it, is what I would have wanted to be synced to Lunch Money. Because Lunch Money only has a concept of “Date” in all of its tables and views. And that would lead most, I think, to believe that’s the date of the transaction. Especially when you’re in the Transactions view.Feature Request
Same way as we have
PayeeandNotestabs, that allow us great control over what gets sent over to the destination(s), it would be great to have aDatetab that leverages the exact same mechanism thatPayeeandNotesdo, just for a “Date” field.Where you can either use a drop-down style selection, with the fallbacks to either
bookingDate,valueDate, orvalueDateTime, in whatever order one pleases.Or one could then leverage the “Advanced Mode", with Eta templates, to craft custom logic and formatting.
And then, as with any advanced feature, it’s up to the user to ensure that the date(time) format they output, is compatible with their destination.
So, literally, just copy-paste the code for
Payee/Notestabs in the account configuration, rename it to “Date”, and then just map to the fields that are used for transaction date information in the destination syncs. 😊Something like this: