If you keep all your ledger transactions in one big file, it can quickly become messy and unwieldy. Fortunately, ledger has a feature that allows for easily separating different accounts into different files, without losing the ability to report on them all at once.
(This post is part of a series describing how I use the Ledger accounting system. For an introduction to ledger and this series, or to see all the entries, have a look at the first post).
A full ledger system will contain not just a record of transactions for one account, but ones for many accounts, in many types of commodities (i.e. not just money but stocks, mutual funds, foreign currencies, etc.), and extra metadata such as historical prices for commodities, and lists of pre-defined valid account names (to catch data entry errors). All this would be overwhelmingly messy if crammed into one single journal file.
Instead, we can split out everything however we'd like; for example by
account type, or financial institution, plus also separating out the metadata
from the real data. Then, we can use ledger's include directive
to reference it all in one place. In practice, this means you might have a
main.journal file that looks like this:
include definitions
include SomeBank-Chequing.journal
include SomeBank-Savings.journal
include CreditCard.journal
include StockBrokerage.journal
include MutualFunds.journal
include Prices.journal
And, if you've created a
.ledgerrc file, you can reference this main journal in there
using the --file flag, so you don't even have to specify it on
every invocation.
The only tricky question that can come up is where to list transactions that go from one account to another. They could go in either account's file, but not in both (or they'd actually be duplicated). The simplest answer is to establish a convention like that transactions are always listed in the source account's journal (or the destination's; it doesn't matter).
Another (more sophisticated) option, which I first learned from Oliver Cardoza is to have the source account list the transaction as going out to an intermediary “Transfers” account, and then have the destination account also list the transaction in its journal, but receiving the funds from the intermediary account instead of the original source. This has the benefit of listing the transaction in both places where it's relevant, and it also lets you catch errors, delays, or hidden fees, by checking whether your “Transfers” account always balances out to zero. The downside is that it can obscure the source/destination of the the transaction (and thus, implicitly, the reason for the transfer); but this can be avoided by carefully specifying the payee description.
