Single journal vs. separate journal files?

General
1

I just started dabbling with plain text accounting using hledger and am liking it so far. I have a fundamental question though that I was hoping others could advise me on before I get too far down the path. Basically it boils down to workflow and journal management. I couldn’t find existing documentation or best practices on this, so apologies if I missed it somewhere.

My brain wants to break down the journal into separate files in a tree folder / file structure and use include statements to pull them into a higher level journal. I’ve started creating separate folders for credit cards, bank accounts, etc. and within those having journal files that correspond to monthly statements. I was hoping I could use balance assertions within each file and keep them “modular” such that hledger can check a single journal file to confirm that the summation of the journal transactions for that month match up with the the summary of payments or credits from the statement.

  • For those of you that have been doing PTA for a while, am I going to regret doing things this way as opposed to putting everything in one journal file?

  • The balance assertion statements I’ve been using have sort of been working, however errors in a different journal file month impact all the balance assertions (which makes sense), and as such it isn’t modular. Is there a way to do an assertion which sums the payments or credits just within one journal file?

Thanks in advance!

1 Like
2

I’ll partially answer my own question. I found the link below (smacks forehead). It looks like most people start with a single file and then move to multiple files broken out by year or month. It doesn’t sound like people break it all the way down to match individual account statements.

https://plaintextaccounting.org/FAQ#how-to-organise-files

2 Likes
3

Just have one file and invoke hledger reg appropriately.

1 Like
4

Welcome! You should find some tips on file management in the hledger and/or plaintextaccounting cookbooks. Look also at “workflow” docs.

IMHO yes you will regret it because things soon get complicated enough, so in the things you can control, less is more.

But you won’t really regret it because it’s just text, easy to rearrange and try out in different workflows, especially at this stage, and you might find an arrangement you like. YMMV!

1 Like
5

For those of you that have been doing PTA for a while, am I going to
regret doing things this way as opposed to putting everything in one
journal file?

With PTA, you can changes things at anytime, its not a big deal. I’ll
first go through how i organize mine, then i’ll show how you can change
back to and fro.

My system revolves around the mk program, which is the plan9ports version
of make. I keep my transactions in seperate files and then i build the
single journal file with mk. Here is a simplified version of how i build
my journal, main.led:

transactions = `{find transactions -type f | grep '\.led$'}

main.led: $transactions
	for file in $transactions; do
		cat "$file"
		echo
	done | hledger -f - print >$target

My transactions are organized in the following way:

transactions/
	account1/
		year1.led
		...
		yearM.led
	...
	accountN/
		year1.led
		...
		yearM.led

For example

transactions/
	personal/
		2021.led
		2022.led
		2023.led
		2024.led
	business/
		2021.led
		2022.led
		2023.led
		2024.led

Now if i wanted to switch back to a single-file…well i just ditch the mkfile and
add everything from then on to the journal, main.led, that i’ve already built.

If i wanted to switch back to seperate files from a single file, i could just run

for year in $(seq 2021 2024); do
	hledger -f main.led print personal -p $year >transactions/personal/$year.led
	hledger -f main.led print business -p $year >transactions/business/$year.led
done

to repartition my transactions back into seperate files. In reality you
might have to take special care of certain transactions (like periodic
transactions), but that can easily be done manually.

The balance assertion statements I’ve been using have sort of been
working, however errors in a different journal file month impact all the
balance assertions (which makes sense), and as such it isn’t modular. Is
there a way to do an assertion which sums the payments or credits just
within one journal file?

I keep all my assertions in a seperate file named
assertions.led. Everytime i do an import i append the following:

2024-03-30 Balance Assertion for account personal:bankaccount
    (personal:bankaccount)    $0.00 = $9999999999999999999999

Is there a way to do an assertion which sums the payments or credits
just within one journal file?

I don’t understand exactly what you mean. Something like(?)

cat SINGLE-JOURNAL-FILE assertions.led | hledger -f - bal
2 Likes
6

Thank you for all the replies. Very helpful to know that it’s fairly straightforward to change file structure in the future and that I won’t necessarily be “locked in” to a particular choice I start with now. I never thought about the possibility of using hledger to split out files by date in the future if desired.

7

I don’t understand exactly what you mean. Something like(?)

cat SINGLE-JOURNAL-FILE assertions.led | hledger -f - bal

Yes, that would in fact be a better way to accomplish what I was trying to do. The assertion could be done by appending to that one journal file as you demonstrated, however it wouldn’t be present if the same journal file is included in another journal. I’m seeing the possibilities better.

The other examples you provided gave much food for thought also. Thank you!

8

When I first started off with PTA, I tried having separate files for credit cards, bank accounts, etc. But I realized it didn't make sense, since there are entries that involve both bank accounts and credit cards (when I repay my credit card liabilities). Where would I put those? And if I pull them from CSV files, there ends up being 2 entries. So I abandoned that idea.

For the longest time, I kept all my transactions in a single journal, and all directives and declarations (prices, commodity styles, accounts, etc.) in their separate journals. This is the simplest way, and I'd recommend this for most. But it also, imho, doesn't provide for adequate checks.

Thus for the past many years, I've settled for keeping separate journals for each financial year. At the end of each financial year (April 1 - March 31, in my country), I close my Income and Expenses accounts by adding a "Retained Income" and "Retained Expenses" entry, as accountants do. This entry is generated using:

hledger close --retain '^Expenses' --close-acct="Equity:Retained:Expenses:FY23-24" --close-desc="FY2023-24 Closing Balances ; clopen:" --explicit date:2023-04..2024-04

and

hledger close --retain '^Income' --close-acct="Equity:Retained:Income:FY23-24" --close-desc="FY2023-24 Closing Balances ; clopen:" --explicit date:2023-04..2024-04

And then I add an include statement as the first line of the next journal:

include fy2023-24.journal

This set-up allows the hledger bse -p 'yearly from 2010-04 report to add up to zero. The only issue is that for accurate income statements, you need to use hledger is -p 'yearly from 2010-04' not:tag:clopen, and explicitly exclude the "clopen" tag (i.e., the retained income/expenses entries).

Of course, you could do all of this in a single file as well, by simply skipping the include fy2023-24.journal directive.

My current file structure looks like this:

Main file                : /home/sol/accounts/latest.journal
Included files           : /home/sol/accounts/fy2023-24.journal        
                           /home/sol/accounts/fy2022-23.journal        
                           /home/sol/accounts/fy2021-22.journal        
                           /home/sol/accounts/fy2020-21.journal        
                           /home/sol/accounts/fy2019-20.journal        
                           /home/sol/accounts/fy2018-19.journal        
                           /home/sol/accounts/fy2017-18.journal        
                           /home/sol/accounts/meta.journal             
                           /home/sol/accounts/accounts.journal         
                           /home/sol/accounts/rates.journal            
                           /home/sol/accounts/rates_currency.journal   
                           /home/sol/accounts/rates_crypto.journal     
                           /home/sol/accounts/rates_nps.journal        
                           /home/sol/accounts/rates_mf.journal         
                           /home/sol/accounts/rates_gold.journal       
                           /home/sol/accounts/rates_stocks.journal     
                           /home/sol/accounts/rates_equivalents.journal
                           /home/sol/accounts/commodities.journal
2 Likes
9

Although I keep all my journals in a single file, I have recently came to realize that having separate files for tangible assets and depreciation cab make sense. It's easier to maintain them and to include/exclude them.

10

Chiming in as a guy who does pull them from CSV files, you make one transaction go from account A to the transit account, and the second transaction goes from the transit account to account B. In the end, money has moved from A->B and an empty transit account gives you a nice reconciliation aid.

You can have multiple transit accounts when/if it makes sense.

1 Like