Must we close accounts? …and why?

General
1

Last year was my first year paying close attention to accounting using PTA. Towards the end of the year, I started reading articles about closing accounts. This is an accounting relic which methinks may not apply to personal accounting, or small-scale accounting using PTA.

These PTA tools can process really large files really fast, and are only getting better by the day. Last year's balance can be gotten using some targeted queries in reports.

Should we really be closing accounts? …or can we do without it. What do you think? — p.s: if there's some accounting law which absolutely mandates closing accounts at the end of the year (fiscal, or calendar), please share

3 Likes
2

Which kind of closing do you mean -

  1. Retaining earnings, ie transfering revenues and expenses into equity (part of "closing the books" at the end of each accounting period) ?

    This is a traditional accounting practice. Like you I haven't (yet) found any need for it in personal accounting.

  2. Zeroing out asset/liability(/equity) balances at the end of an old file when starting a new file, as suggested by hledger close docs ?

    This is arguable. I have found it worthwhile so I can flexibly choose which old files I want to include in reports. It also adds some documentation/error checking for year-end balances. But it creates some noise in reports, and it makes adjusting old entries more effortful. It's not a traditional practice as far as I know, I think it's more of a technical workaround to allow data sharding. (Because even fast PTA tools slow down with large data.)

  3. Declaring the end of an account's lifetime, after which it may not be posted to, as with Beancount's close directive ?

    I think that's a useful error checking feature, I'd use it if available.

1 Like
3

Personal accounting: do as you please.

Otherwise: mandated by law: to calculate taxes you have to pay, to make audits meaningful (you cannot modify an old ledger once it is closed, that is the point).

For me closing/opening yearly means taking a photograph of Assets & Liabilities and archive it/compare it with other such photographs. If you are well versed in double-entry accounting, you know those photographs are linked together by an income/expenses statement.

Feels interesting enough to reflect about it once a year and what better occasion to do it that opening/closing the books.

4

Great explanation of the possibilities to close accounts!

In my case I close/zero out assets and liabilities every year and I begin with a new journal file. However, it is not easy, I am not very happy with this workflow because I feel this complicates my journal management.

Why I began closing assets and liabilities every year:

  • I have around 1100-1200 transactions per year. I thought hledger and emacs to manage the journal file smoothly, I should have to split per year. I have 6 years in hledger. Perhaps it is not necessary...
  • I use subaccounts for lot management (for example, assets:stocks:amz:2022-01-13-01). Lots are created and deleted and so hledger's accounts. Every year, when I create a new journal file, I do not declare accounts I do not use anymore. If I had only one journal file, I would have declared a lot of accounts I do no use currently. Perhaps de beancount's solution would be great...
  • To avoid modifying the accounting of previous years. But VCS such as git solve this and hledger's assertions at the end of the year could be used to avoid mistakes.

Handicaps:

  • More complex interanual reports. You need to include multiple files. Sometimes you need to exclude the yearly closing and opening transactions to get valid reports (for example with hledger-roi).
  • More complex to begin with a new journal file at the begining of the year. Many times I need to look at the previous journal to copy similar transactions, they are not in the new file. This also affects the autocomplete capabilities of emacs.
  • More complex to batch editing/modifying the journal. Sometimes, I need to rename one account or move one subaccount. This is easily done with REGEX in one file but with multiple files is more complex/tedious.

So, at the end I am closing books because of performance and account cleaning. Perhaps it is senseless... What do you think?

1 Like
5

Thanks for your thoughts @zako.

  • I have around 1100-1200 transactions per year. I thought hledger and emacs to manage the journal file smoothly, I should have to split per year. I have 6 years in hledger. Perhaps it is not necessary...

For 6 years, probably not. When it reaches 20 years.. or when you want to analyse 100 years of historical data..

I could split less often than yearly, but I feel it's better to do it somewhat regularly and get good at it.

  • I use subaccounts for lot management (for example, assets:stocks:amz:2022-01-13-01). Lots are created and deleted and so hledger's accounts. Every year, when I create a new journal file, I do not declare accounts I do not use anymore. If I had only one journal file, I would have declared a lot of accounts I do no use currently. Perhaps de beancount's solution would be great...

I do the same, redeclaring each year's accounts from scratch. This means increasing duplication of account declarations as time goes on. It's easy enough though.

And, it allows me to include old data from times when the Chart Of Accounts was substantially different, without forcing me to maintain a consistent COA over all time. This flexibility has drawbacks, but I think it's the only scalable way - anticipating future COA needs generally is not practical, and rearranging old data into newer COAs could be risky (I do it a bit with aliases).

  • To avoid modifying the accounting of previous years. But VCS such as git solve this and hledger's assertions at the end of the year could be used to avoid mistakes.

Yees.. except if you want to fix/rearrange/clean up old entries, then you will be changing those balance assertions as well. For me, such cleanups and assertion updates happen fairly often..

Handicaps:

  • More complex interanual reports. You need to include multiple files. Sometimes you need to exclude the yearly closing and opening transactions to get valid reports (for example with hledger-roi).

Yes. I use clopen:NEWYEAR tags to match and exclude them - all but the first. A little awkward.

  • More complex to begin with a new journal file at the begining of the year.

Splitting files requires setting up starting balances in the new file, yes. And closing AL(E) balances in the old file is another step (optional). Both of these should be fairly easy with hledger close though - I wonder if you're using that ? My main problem with it is not using it often enough to remember all details (so I script it in a Justfile, but still there's a bit of relearning each year..)

Many times I need to look at the previous journal to copy similar transactions, they are not in the new file. This also affects the autocomplete capabilities of emacs.

Yes. I sometimes include the previous year, which makes the extra autocompletions available for hledger (i)add, and (maybe?) also for ledger-mode (Or, just having the old file open in Emacs does that.. I am using ledger-mode's and dabbrev-expand). It's not as convenient as being able to search back through all history in the same buffer. (Conversely, it's easier to jump to the start of the current year without getting lost in ancient data..)

  • More complex to batch editing/modifying the journal. Sometimes, I need to rename one account or move one subaccount. This is easily done with REGEX in one file but with multiple files is more complex/tedious.

Lately I have been getting brave and using sed -i '/OLD/NEW/' 2*/*.journal (and reviewing the effect with magit or vs code or git diff) whenever possible. This has been a huge time saver, I should have started doing it sooner.

So, at the end I am closing books because of performance and account cleaning. Perhaps it is senseless... What do you think?

I have a bit of the same feeling at times. It certainly feels tedious when you find errors in some long-past year and then you have to regenerate all subsequent closing/opening entries.

I would like to try a combined balance assignment/balance assertion (balance assumption ? balance assernment ?) that works as a balance assignment when it's the first transaction seen in an account or a balance assertion otherwise. This would make the closing balances transactions unnecessary, at least.

Related: hledger#2151

6

I was thinking on "subaccount-inclusive balance assertions" (=*). So we could assert the complete revenues and expenses of the year and then be able to rename or split revenues or expenses subaccounts without failing the assertion.

1 Like
7

Another idea:

Instead of creating a new file for the new year (or period you decided) and begin with an empy file, why not one single file and periodically remove/close older years? For example, this year 2025 I remove transactions prior to 2020 from my main journal transactions.journal.

This way:

  • Always import and create new transactions in the main transactions.journal.
  • The transactions.journal is sufficient old to perform all the reports I am normally interested in.
  • The creation of new entries is easy, because I can copy old transactions that are available in the journal (I do not need to search in another file to copy and paste it).
  • If I need to rename or modify accounts, I only need to modify them in this journal. I assumme transactions-prior-2020.journal is for archiving purposes.
  • When I remove transaction of the oldest years (I move them to another file such as transactions-prior-2020.journal), it would be time to check unused accounts to remove them from the main transactions.journal.
1 Like
8

So much accounting terminology is based on the days when records were kept in paper books.

"Closing the books" was a procedure by which entries were made in the journal at the end of an accounting period to assure an appropriate balance in every account for the period reporting. The physical journal and ledger books were then literally closed and archived, never to be written in again.

A new journal was created by writing opening transactions describing the state of the business when the previous books were closed. The new ledger was then started by posting these opening transactions.

Some accounts are, by convention, closed at the end of an accounting period as the books are closed. Closing an account means entering a transaction making the account balance zero. The account remains closed unless/until it is reopened by a new transaction.

For example, the balances of income, expense, and all their subaccounts are transferred to retained earnings as the books are closed. The new set of books has new income and expense accounts with opening balances of zero. It might be clearer to call last year's income account "equity:income2024" and this year's income account "equity:income2025", but the convention is to close and reopen the income account with each new set of books.

2 Likes
9

My 5 cents: parallel journaling of one big file, and "closing" (I think at this like "archiving") a separate year's journal file, like a copy.
Of course, drawback: if I ever change older transactions of the main big file, what happens with the same transaction in the archived version?

_______________________________________
|    |                |               |
|    |_ 2022          |               |
|                     |_2023          |
|                                     |_ 2024
|_ main journal