Philosophy / Procedure for Reconciliation to Statement?

[captain...@gmail.com]

What is the philosophy for reconciling accounts to statements, aka "balancing the checkbook"?

Reading through the documentation, I don't recall mention of "cleared" or "reconciled" flags: there was something about flagging particular legs which are partially unknown at the time of entry (involving currency exchange IIRC), and also a philosophical note that we don't care about freezing the ledger at some past instant in time.  Traditional item-by-item reconciliation seems to be largely a waste of time, but a simple balance assertion is not enough to differentiate between posting date limbo and missing transactions.

[Martin Blais]

Hello Captain Poutine,

On Fri, Dec 26, 2014 at 4:48 PM, <captain...@gmail.com> wrote:

What is the philosophy for reconciling accounts to statements, aka "balancing the checkbook"?

What would you like it to be?

Reading through the documentation, I don't recall mention of "cleared" or "reconciled" flags: there was something about flagging particular legs which are partially unknown at the time of entry (involving currency exchange IIRC), and also a philosophical note that we don't care about freezing the ledger at some past instant in time.  Traditional item-by-item reconciliation seems to be largely a waste of time, but a simple balance assertion is not enough to differentiate between posting date limbo and missing transactions.

The flags have the same meaning as in Ledger, which is to say: whatever you want them to mean.

There aren't any specific tools to help you "clear" those transactions with a "!" flag on them, but it might be useful to create a tool that lists in Emacs-error format the transactions with a particular flag, so you can quickly iterate on them from within Emacs. This way you could quickly jump to all transactions which you had previously marked as suspicious. I could even enhance it to ignore all such uncleared transactions prior to a successful balance check.  If you think that might be useful let me know.

It's true that slightly incorrect posting dates vs. missing transactions won't differentiate readily, but in practice, if you insert balance assertions often enough (e.g. every couple of weeks when you update your ledger) figuring out what the issue is when a balance assertion fails isn't very difficult. If you look on the list, in recent messages with Matthew Harris we've discussed the idea of allowing per-posting dates so that a precise rendition of journal date can be created by the user even with differing settlement dates between accounts (e.g. in the case of a transfer between two accounts where the amounts have different dates). This would largely alleviate the issue of having to possibly fudge a posting's date and risking a connected account fail its balance assertion. But then again... in practice this occurs rarely.

I'd love to hear ideas on how to make this process better, especially if building simple tools could help.

Cheers,

 

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/fb33c1c1-aab4-4c65-915c-17b70f8a7c5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[captain...@gmail.com]

Hello Martin,

On Friday, December 26, 2014 5:23:15 PM UTC-5, Martin Blais wrote:

Hello Captain Poutine,

On Fri, Dec 26, 2014 at 4:48 PM, <captain...@gmail.com> wrote:

What is the philosophy for reconciling accounts to statements, aka "balancing the checkbook"?

What would you like it to be?

I'm setting up my system this weekend, so I don't speak with any authority.  My experience using Quicken & QuickBooks was that their "reconciliation tool" required manually checking off each individual transaction, which took far more time than the value it provided.  So flagging should probably be used in exceptional cases, rather than for every transaction.  But I do want to periodically add any transactions I didn't record (e.g., account service fees or small purchases that I forgot to enter) and check for incorrectly posted amounts, and for most accounts, "periodically" should probably be monthly when the official account statement is generated (although I should probably do a quick check weekly, to spot fraudulent charges faster).

I'd like to rephrase my question: "How do beancount users typically balance checking account ledgers against account statements, particularly in light of the phrase 'balance assertions provide a safeguard that allow us to change the details of past transactions with little risk, so there is no need to “reconcile” by baking the past into a frozen state'?"


At this time, I can't offer an informed opinion about either the Emacs error mode or Mr. Harris's ideas on multiple dates.

Cheers,
"Captain Poutine"

[Martin Blais]

On Fri, Dec 26, 2014 at 8:53 PM, Martin Blais <bl...@furius.ca> wrote:

On Fri, Dec 26, 2014 at 8:24 PM, <captain...@gmail.com> wrote:

Hello Martin,

On Friday, December 26, 2014 5:23:15 PM UTC-5, Martin Blais wrote:

Hello Captain Poutine,

On Fri, Dec 26, 2014 at 4:48 PM, <captain...@gmail.com> wrote:

What is the philosophy for reconciling accounts to statements, aka "balancing the checkbook"?

What would you like it to be?

I'm setting up my system this weekend, so I don't speak with any authority.  My experience using Quicken & QuickBooks was that their "reconciliation tool" required manually checking off each individual transaction, which took far more time than the value it provided.  So flagging should probably be used in exceptional cases, rather than for every transaction.  But I do want to periodically add any transactions I didn't record (e.g., account service fees or small purchases that I forgot to enter) and check for incorrectly posted amounts, and for most accounts, "periodically" should probably be monthly when the official account statement is generated (although I should probably do a quick check weekly, to spot fraudulent charges faster).

Sounds right to me.

Here's how I do it, which is similar to what you describe you want: my importer script flags all transactions as "correct" and then I quickly look at them to ensure they are okay, and insert a final balance assertion. Most of the time, the importer script itself creates the final balance assertion (I rarely happen to transcribe the actual balance amount from monthly PDF statements). I only manually flag transactions or postings for which I believe I will have to do some more related work with later on.

I'd like to rephrase my question: "How do beancount users typically balance checking account ledgers against account statements, particularly in light of the phrase 'balance assertions provide a safeguard that allow us to change the details of past transactions with little risk, so there is no need to “reconcile” by baking the past into a frozen state'?"

Using balance assertions and inspection should be enough. If you keep your balance assertions and you change a transaction in the past that affects an asserted account, you'll be forced to change the past in a way that maintains the correct balance, that is, possibly changing multiple transactions. Note that this assumes the balance assertions themselves are correct (which is pretty much always the case). Balance assertions are the checks that verify the sums are correct, and the effect increases the correctness of all other accounts connected to the asserted account. This is not a "perfect" system, and the more assertions you'll insert the more certain you will be that you incorporated external data correctly in your ledger file, but I think there is a balance between how much effort you'll want to put in asserting balances vs. how much conviction you need that your data is right.

Personally, I insert one balance assertion for all cash accounts that I update every time I update them, which is about once/week. For investment accounts, I'll typically assert the numbers of shares in all units in a lump say once every six months. My experience is that this is more than required to correctly transcribe all my data... once/month would be plenty over the cash accounts that I do assert. When I've made mistakes in the past, I've been able to go back and insert new balance assertions to narrow down more precisely where the problem has been, which is also nice. A balance assertion is your friend. I don't think I could feel great about my ledger data without them and I sometimes wonder how Ledger users do without.

At this time, I can't offer an informed opinion about either the Emacs error mode or Mr. Harris's ideas on multiple dates.

All we were saying is that by allowing dates on each posting a meticulous user could input the exact date for each posting and thus precisely reproduce the journal for the associated account. All balance assertions would correctly apply at their declared/imported dates. It removes the "time limbo" problem you alluded to.

[captain...@gmail.com]

Hardware problems have delayed my Beancount implementation, but I have done some thinking.

First, I expect to begin by entering transactions manually, but perhaps that's a mistake.

But returning to the idea of individually-dated legs and automatic splits to Limbo, could we discuss how to enter a rent check?

I'd like to associate 3 different dates (which can occur in almost any order) with my rent check:
1) The date I write / mail the check ("transaction date")
2) The date I incur the expense for budgetary purposes ("budgetary date")
3) The date the check clears ("posting date")

The difference between #1 and #2 is important if I paid December rent on Monday Dec 1 and then paid January rent comfortably early as above.  I used to do it this way in Quicken:
Account: [Checking]
2014-12-17, #123, Mr. Landlord, $1000, Category: [PrepaidExpenses]
Account: [PrepaidExpenses]
2015-01-01, NULL, Mr. Landlord,  $1000, Category: Rent

So this is cleaner:
2014-12-17 * "Mr. Landlord"
    Assets:Checking            900.00 USD
    2015-01-01 Expenses:Rent

But I still haven't addressed #3, which is the main purpose of classical checkbooks, and my landlord is really slow to deposit checks.  It also applies to my reconciliation issue, as I'd like to be able to run a balance report with & without limbo and compare it to the bank's Web site on a given day.  Could I do this for checks which are large and might take a while to post:
2014-12-17 * "Mr. Landlord"
    ????-??-?? Assets:Checking            900.00 USD
    2015-01-01 Expenses:Rent

How feasible is this, given that we've mixed budgetary fudging with posting-date limbo?
Would it be practical to get the reports that I want, e.g., "your checking balance on 2014-12-25 is $1500 including all outstanding checks (limbo) and $2400 without"?  A "most pessimistic" report might also be nice: current balance less checks in limbo but NOT adding deposits in limbo.
Is it clear to Beancountl that ????-??-?? represents "an unknown date after 2014-12-17"?

Another idea is to allow multiple transaction dates with one-letter prefixes:
T2014-12-17 B2015-01-01 P2015-02-01 * "Mr. Landlord"
    Assets:Checking            900.00 USD
    Expenses:Rent

Where "T", the transaction date, is optional, B is Budgetary, and P is Posting.   This probably suffers from the same lack of definition that plagued transaction-level dating.