[GNC] Kind of a Philosophical Question about Transaction Dates

[Hartmut W Sager]

I've now read this whole thread up-to-the-minute (fine granularity :) ), and I picked your response for my reply because you gave the best explanation.

But I'm replying because the whole thread didn't mention one particular point:  In double-entry accounting, the books "have to balance" at every instant in time, and thus all the legs of a transaction have to be dated/timed in the same instant.  Otherwise there would be points in time where the books aren't balanced.

I gave this issue much thought when I wrote my own accounting software (first in DOS Basic in 1982 and second in FoxPro in 1992), and I have two fields, TransDate and PostedDate.  The TransDate is the same for all the legs of a transaction, and the PostedDate is you-know-what.  The PostedDate can be used for summaries/reports where we really need the posted date, but of course, such summaries/reports must not be used where they conflict with "always balanced".

Hartmut W Sager


On Mon 02 Mar 2026 at 19:56:45 -06:00, Jim DeLaHunt <list+gnucash at jdlh.com <mailto:list%2Bgnucash at jdlh.com>> wrote:
> Tom:
> 
> Interesting question. And deeper that it may sound!
> 
> On 2026-03-02 17:00, Tom Route36 wrote:
> > …Any transaction in GnuCash always involves at least two accounts.  
> > For example, when you make a payment to a credit card account you're 
> > debiting funds from your checking account, and crediting those funds 
> > to your  credit card account.  My question here is about how folks 
> > choose to enter the transaction dates in GnuCash.
> > …If you use Feb. 27th, the transaction date differs from your next 
> > month's bank statement.  But if you use March 2nd, the date differs 
> > from your next credit card statement.… I was just curious how other 
> > folks deal with these kinds of date differences.
> 
> Most transactions I enter into GnuCash are not instantaneous. They take 
> non-zero time, often more than a day, from when they start to when all 
> the settlement of all the parties is finished. There can be four days 
> from when an interbank transfer leaves my investment account to when it 
> arrives in my chequing account. There can be weeks between when I write 
> a paper cheque, to when the recipient deposits the cheque, to when my 
> bank takes the funds from my account. Different parties can report 
> different times when they participated in the transaction, for instance, 
> the moment when I wrote the cheque, the moment when the recipient 
> received the cheque, the moment when the recipient deposited the cheque, 
> the moment when the receiving bank requested funds from my bank, the 
> moment when my bank took the funds from my account.
> 
> Yet GnuCash's data model has room for only one time value per 
> transaction, and that time value is in increments of calendar days, no 
> finer.
> 
> Clearly what the GnuCash data model can store will be a simplification 
> of what actually happens in the transaction. I need to choose one moment 
> from the many moments when steps happened in the transaction. I need to 
> record that moment with day granularity.
> 
> I choose to record the date which is closest to my first action in the 
> transaction. For a credit card purchase, when I made the purchase. For a 
> cheque, when I write it. For funds I receive, when I deposit it. When my 
> bank credits me interest, when they say they credited it. I usually 
> choose to disregard how long the transaction takes to complete.
> 
> The purpose of my bookkeeping is to help me understand my financial 
> situation to the level that I need to understand it. The actual duration 
> of a transaction is often immaterial to my financial situation, so I 
> don't need to worry much about which date I choose to represent the many 
> moments of a transaction.
> 
> You can imagine a data model which includes a time value, to microsecond 
> accuracy, of every event that happens as part of a transaction. There 
> may be some bookkeepers which need that kind of data to be able to 
> understand their financial situation. GnuCash is not designed for them.
> 
> Best regards,
>     —Jim DeLaHunt\
> 
> 
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>