Booking date vs Value/Purchase/Trade date

[Tomasz Zurkowski]

Hello everyone,

I am still pretty new to beancount (I started my adventure around a month ago) and I am still tuning my importers and my ledger.

When writing importers for my banks, I realized that they often provide multiple dates for one transaction, e.g. "booking date" and "purchase date"), and I was wondering which I should choose as the date for the transaction entry. Also, I was wondering if one of them is better, or whether it is just a preference (e.g. if I would like to open source / share the importers, should it be an option to choose one or the other, or can I just choose one of them).

Let me describe situation with UBS bank statement - they provide 3 dates: "booking date", "trade date", "value date". Here is my current understanding of them:

• booking date - a day when bank puts a transaction into their books. Most of the time (always?) it is greater or equal to the other two dates. I also believe it has the nice property that once there is a transaction with date X, then later imports (new transactions) will never have a date X or before (which makes "balance" entries stable and never brake).
• trade/value date - I believe this is the date when the trade actually occurred. For example if I bought something on Saturday, the day will be Saturday but it can be booked on following Monday. The only difference between trade and value date I found was when there is a "e-bill" (a way in Switzerland to automatically pay bills). In this case "trade date" will have a date when the transaction first shows in the bank account "e.g. 2021-01-29", but then the value date is when the transaction was scheduled for (e.g. first of the month, 2021-02-01). Booking date seems to also match 2021-02-01 for those transactions (but I only have few of those, so I am not sure if they will always match). There is one more difference, when importing transaction, one can choose them to sort them either by "booking date" or "trade date" - there is no way to sort them by "value date" (import contains the "balance" column, that I could use to generate automatic "balance" entry).

Currently, I am using "value date" because it represents the actual date of the trade (which helps me to remember what the transaction was for, if the default bank transaction description is not clear), and it also properly dates the periodic transactions that happen on e.g. first of the month (makes sure there is always 1 transaction for rent in a given month).

I am also consider using "booking date" (and saving "value date" somewhere in the default description), so that I can automatically insert "balance" entries, and those entries should almost never break with the new import.

UBS credit card importer has very similar issue, the data contains two dates: "booking date" and "purchase date" that have similar properties to the above one. Small note I want to add here is a refund scenario. If I purchased something on 2021-03-15, and then I return it, it is possible that return will be processed much later (even 2 months later), so it could be booked on "2021-05-15", but it would still have purchase date "2021-03-15" (which means if I have any "balance" entries in my ledger, they all break and I have to manually adjust them).

Does anyone has similar issues? Any recommendations? Is it a personal decision (some people prefer one or the other), or is there a better choice (or something that should be at least considered a default / best practice)? I would love to hear from others!

Thanks,

Tomasz

[redst...@gmail.com]

This probably varies by country. I'm familiar with US accounting, which typically involves two dates: trade date, and settlement date.

In my experience, consistency matters much more than which one you use. Exception: folks who perform advance investing may have more specific requirements. FWIW: I've always used the trade date (aka posting date for credit cards). I've included the settlement date (occurs later than the trade date) as metadata in investment accounts, but have never used it so far.

[Martin Blais]

This is a known issue, see the settlement dates proposal, is being handled in the c++ rewrite, see v3 design doc. Also lots of history on the mailing list.

Currently you either fudge the dates or skip the occasional balance assertion that doesn't want to cooperate. It's unsatisfying but I've been living with it for ten years now

Eventually the solution will allow you to provide both dates and the transaction will be split to two with a transfer account where the funds will transit through an account where the amounts in limbo sit.

This could be handled by a simple plugin in you feel like it. Use metadata for the second date and split the transactions in the plugin. Should be core functionality though

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/d2d384f1-8658-4268-9b66-ba5e63d13433n%40googlegroups.com.

[Tomasz Zurkowski]

Thank you everyone for responses.

Just to clarify a little, I am not interested here in the "transfer" usecase which can be solved with limbo account very cleanly as mentioned here and there is indeed a lot of discussions on this topic (I think it would be useful to collect all the information / idea on this topic in one place, but let's leave it for a separate thread for now). Here I was mostly interested in very simple transactions from debit / credit cards e.g. a grocery or train tickets (let's also ignore trading accounts). Or am I splitting hair here and it does not matter in the long term which date is actually being used?

[redst...@gmail.com]

Particularly for debit/credit card accounts, t really doesn't matter at all in my decade+ long experience, as long as you are consistent.

The only related issue is how to date your balance assertions. Here is a thread and here is how I do it.