Reconciliation: incomplete transactions vs. transfer accounts?

General
1

Hi

I fell off the PTA wagon a few years back and I’m getting back into it. Started with ledger, right now I’m trying beancount (some “performance anxiety” but I like the documentation and emphasis on avoiding footguns).

One thing I always felt I should be doing, but largely wasn’t, was consistently reconciling statements with manually-recorded expectations of what should have ended up where, so I can catch any errors (really, large errors is what I have in mind!).

Looking through the beancount docs I saw this:

https://beancount.github.io/docs/getting_started_with_beancount.html

when I know I import just one side of these, I select the other account manually and I mark the posting I know will be imported later with a flag, which tells me I haven’t de-duped this transaction yet:

2014-06-10 * "AMEX EPAYMENT    ACH PMT"
  Liabilities:US:Amex:Platinum       923.24 USD
  ! Assets:CA:BofA:Checking

Later on, when I import the checking account’s transactions and go fishing for the other side of this payment, I will find this and get a good feeling that the world is operating as it should.

Apparently these ! transactions legs create what are called “incomplete” transactions in beancount.

In the past, what I’ve done (sometimes!) is rather to have one’s manually recorded transactions move money into some “pending” account, and leave it to the auto-imported transactions to move the money out again. If money is left in the transfer account, you know something’s wrong. Like this example (here the author goes to the lengths of one account per transaction so the PTA system will even pinpoint the transaction id where things went wrong):

https://mumble.net/~campbell/2017/02/26/ledger/HOWTO-reconcile-cheques

Does anybody have comments re pros/cons of these two approaches? I’m actually not sure yet how one goes about getting beancount even to list the incomplete transactions. I guess the idea is you don’t, but rather your auto-import creates transactions with only one leg, and then you manually match those up and move them to their corresponding manually-entered ! incomplete transactions - or at least manually remove the !s? Sounds labour-intensive?

1 Like
2

Right on @human-bean-count , welcome back.

I don’t know if it has more meaning in beancount, but in h/ledger the ! flag is significant mainly to the user. And the tool provides a way to list postings or transactions with or without that flag. Conventionally we use ! to mark pending/unusual things, and * to mark cleared/reviewed things (and absence of either to mean uncleared/unreviewed things).

Flags like ! are not part of traditional double entry bookkeeping or the accounting equation, while transfer accounts are. But using a transfer account is more verbose in the journal and in reports. Sometimes it’s worthwhile, eg for things that will be pending for a significant while, or across year file boundaries; other times it’s too much effort and a flag may be just what you need.

h/ledger allow posting dates in addition to or instead of a posting status flag, which can be even better for representing clearing delays. I’m not sure beancount allows that though.

1 Like
3

I really liked using a pending account and uses scripting to automatically generating the counter-transactions against the pending account. I felt like this game me more more confidence that my reconciliation was correct than manually editing the pending flags. I also liked that my ledger always summed to zero which isn’t the case when you’re doing sums with/without the pending postings. The treatment of clearing dates with the automatically generated transactions was much more integrated than toggling my reports between using different date1 vs date2 modes.

1 Like
4

date2 (AKA secondary/effective/auxiliary dates) is another can of worms which beancount certainly would not allow, let’s not speak of it and perhaps it will go away :no_entry_sign: :laughing:

5

There is a settlement date proposal, but who knows when the mighty version 3 will come out.

https://beancount.github.io/docs/settlement_dates_in_beancount.html

If I really want settlement dates, I’ll just add a tag in the hope that one day I’ll edit all transaction…

2014-06-10 * "AMEX EPAYMENT    ACH PMT"
  Liabilities:US:Amex:Platinum       923.24 USD
  Assets:CA:BofA:Checking
    settlement-date: 2014-06-20

In the meantime, I’ll create my own pta app with settlement dates :slight_smile:

1 Like
6

Oops sorry to accidentally ignore this (forgot all about it for a week), and thanks everybody!

I think I’ll try and stick to the “transfer account” approach and see how it goes. I think my potential for missing large discrepancies is big, and finding those is something I want to get out of this.