https://www.reddit.com/r/plaintextaccounting/comments/1ojlocj/to_reconcile_or_not_to_reconcile
I am starting my PTA using Ledger but by the experience I had using GnuCash years ago, reconciliation just took me time and added an extra step to do.
I mean, I can run a balance on ledger and compare with the values on my bank accounts. The same goes for my credit cards. So, to me, marking the transactions as cleared seems like a waste of time. Is my view wrong?
It's your accounting system, so the process that works for you is right.
For me, "reconciling" means "making sure the accounting system matches reality",
however you can do that.
Periodically comparing balances with what your bank reports is the most typical way.
Marking journal entries with a status flag is completely optional.
It can be helpful in tricky reconciles, when balances don't agree and it's not easy to see why.
Then you might choose to check and mark one entry at a time, while watching how reports change.
Or you might just check the entries and skip the marking and reporting. This too can often work well.
It just depends on the situation.
Personally, I do use the status mark - not often to affect the reports, but more as a visual indicator that I have reviewed and finalised the entries (both manually-entered and csv-imported entries). In ledger-mode and my emacs theme, the "uncleared" entries stand out in red. Entries that I have marked cleared (*), I can normally ignore, reducing mental effort.
Some related docs:
If you generate journals from bank provided CSV’s, how can balances not agree?
I’ll assume you assure the CSV download is complete. Is there something that can go awry in the csv to journal transition process?
Sure! Just to name a few:
Reconciling, ie testing your reports against an external source of truth, is quick and guards against all such things, giving you confidence in your system.
I agree that if user software is defective, reconciliation is unlikely to work.
But if all journal entries are built using bank provided data, bank balances will almost always match. The one time I had this fail is when the bank dropped a posting because it used time stamps to the minute for unique transaction id’s and I had two ATM transactions within a minute.
Yes! That's a good example.
You noticed that it failed, so I guess there was some kind of reconciling at some point!
In traditional accounting world, I enter transactions in my journal from a source document (eg a receipt or invoice) as soon as possible after a transaction is completed.
I reserve the term “reconcile” to the process of assuring that for every account posting in my set of books, there is a matching posting on the statement from my bank. Our posting date may differ, because there is always some delay - from seconds (in an electronic transaction) to months (when someone is slow to present a paper check).
Honestly, I gave that up years ago. I write less than ten paper checks a year. The only record I have of checks written is the NCR copy in my checkbook. I throw any paper receipts I collect into a basket.
I find it infinitely more convenient to reverse engineer journal entries from files provided by my bank. These files are typically a CSV file of their ledger postings (date and amount) to my account along with some captured metadata that may help me recognize and recall the transaction.
I wonder what the best workflow is for lazy people like me who reverse-engineer journal entries?
Dennis
Interesting notes about your process.
My general definition of "reconcile" was "checking the accounting system matches reality". Checking the balances, or checking the transactions, are two ways to approach that. (And checking the transactions could mean checking the journal entries, or checking the app's report of transactions.) In fact, none of these is a complete check of correctness; but in PTA, normally any one of them will be sufficient in practice.
I'm with you on the convenience of converting bank data to journal entries (where possible and practical); many of us do the same. I'm guessing by "best workflow" you mean for reconciling in this setup, right ? For me it's "compare latest balances". That's a quick and pretty strong indicator that all is well. Especially combined with the permanent balance assertions I leave at points of interest, and all the other checks I run in strict mode.
Thanks for your reply. I do wonder how you spot fraud / forgery / identity theft or deal with people who don’t cash your checks (if you still write them).
BTW, I do enjoy your periodic updates on your personal workflow. Sounds like it is an evolving process.
Definitely, always evolving!
Reconciling should very likely catch those too - one of the benefits of accounting.
Ah, but your question points out an important step I forgot to mention. I do review all the imported entries as part of the process, ie I try not to just convert and use blindly. I do this review after importing the entries to the journal. (This is one reason I prefer the import-to-journal workflow over the keep-as-csv workflow.)
I'm not (usually) comparing them with an itemised bank statement, I'm just eyeballing them and investigating any mysteries. I don't mark an entry cleared (*) until I've done this. This should catch the two above.
Writing a check is one of the events I'll record in the journal manually, ASAP. (Spending cash, sending an invoice are some others.) I won't mark it cleared, which makes it stand out in red. When I see the transaction arrive in bank data, I'll discard the generated entry or combine it with the manual entry, and mark that cleared. So I'm aware of this because of (1) seeing a red entry when I edit the journal file and (2) seeing the bank's balance doesn't yet match my local balance. (While this lasts I can use -C/--cleared to ignore these uncleared entries, allowing me to reconcile the others.)