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 <https://groups.google.com/g/beancount/c/uvLRzeCSJnY/m/GXgKMoxQBAAJ> is a thread and here <https://reds-rants.netlify.app/personal-finance/automating-balance-assertions/> is how I do it. On Friday, April 2, 2021 at 5:38:02 AM UTC-7 tomasz.z...@gmail.com wrote: > 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? > > On Friday, April 2, 2021 at 11:08:11 AM UTC+2 bl...@furius.ca wrote: > >> 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 >> >> >> On Fri, Apr 2, 2021, 02:35 Tomasz Zurkowski <tomasz.z...@gmail.com> >> wrote: >> >>> 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 >>> >>> -- >>> 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 >>> >>> <https://groups.google.com/d/msgid/beancount/d2d384f1-8658-4268-9b66-ba5e63d13433n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/f8fa186b-ca40-44d6-801a-ac0122bab728n%40googlegroups.com.
