Plim passed a significant milestone today. In an important validation of its entire design, not one, but two core concepts were confirmed in the wild.
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇
In January of this year, I started keeping parallel books for the household accounts - our real budget was still on YNAB, but I started tracking a shadow budget in plim. As expected, bugs were quickly found and feature gaps were filled in, but eventually, the only way forward was to pull off the training wheels and see if this baby could actually support my weight on its own.
So in March, I parted ways with YNAB and annointed plim as my One True Budget Tool.
Things were a bit wobbly at first. Under the shadowing scheme, YNAB had been quietly answering questions that I didn’t even realize I’d been asking, but flying solo now meant that I had to invent some habits and workflows to figure out how to ask and answer them in plim.
Once I figured those out, things went fine. Enough so, that as April began to wind down, I dared to ask the one question I’d been dreading all along - the one that had plagued my entire existence in YNAB.
Can I reconcile the budget against the bank?
Plim’s entire mantra is that it’s built entirely from bank records, so you might wonder how it could ever be wrong. But just because the theory says they should agree doesn’t mean that reality was going to cooperate. The only way to tell for sure was by looking.
But look at what, exactly? I decided that the most important question to agree on is: How much money do I have right now? (For some arbitrary value of “right now”.)
On the bank side, that should be easy enough - just look at the balance of each bank account at the “right now” time and add them up. That’s your actual cash on hand. (And to be clear: we’re talking about savings and chequing accounts only. Credit cards are about money you owe, not money you have.)
Over in plim, things are a little different. The funds you have are scattered throughout your bucket system, and some of that is sitting in the credit card buckets, waiting to pay the next bill, so in plim, the total has to include your CC buckets as well.
To compute the plim half of the reconciliation, you just set your look_at point to 23:59:59 on your “right now” date, pull the reckon report, and add up what’s left in all the buckets.
To my great surprise, that actually worked. Almost. I was out by $11.95. Close enough to confirm that my method was sound, but far enough apart to prove that there was a mistake somewhere. That number felt very much like a single transaction was missing, but where? And how was I supposed to find it?
Some Simple Sleuthing
I started the hunt by going back to the beginning. Did January reconcile? Like I said, I’d been avoiding this reconciliation question all along, so I still had no idea if January was balanced or not. I set my look_at time to midnight of Jan 31 and did the math, then checked against the bank. Cool! January matched, right down to the penny. What about February? Yup. March?
And that’s where I found it. I had pulled my last tallysheets for March on the 31st, but after consulting a later tallysheet from April 6, which still included that last few days of March, I discovered that there were two final transactions that had landed in the account on the 31st, after I had finished: a bank fee and a refund. And they totalled to $11.95.
I can’t remember ever being happier to find a mistake. Not only had plim told me that I’d made a mistake - it had actually told me the exact size of the transaction(s) I was looking for.
After accepting the missing records into March, that month too clicked into reconciliation lock-step, but it left a new hurdle in its wake. The mistake may have occurred in March, but I had found it in April, so this was going to test a second part of plim’s theory: the carry-forwards. Would correcting an issue in one month and percolating the corrections forward actually work?
I moved to the April vault and carried in the adjusted closing cistern from March, overriding the original starting numbers that April had already been built on…
And to my astonishment, it just… worked. This time, when I added up the April buckets, they matched the bank totals to the penny.
There’s no video evidence to confirm it, but let the record show that I did a little dance of joy.
Knowing nothing about accounting or financial software, I felt a bit like the farm-boy who went to NASA with a wild amateur theory, who years later gets to sit in the bleachers and watch his “theory” lift off for the stars.
It felt amazing.
Addendum
The sharp-eyed reader will notice that the original reconciliation error was one of my own making. I had gotten lazy with ingesting new tallysheets, trusting that they were always just duplicate records of previously accepted transactions, which was true - until it wasn’t.
So I’ve implemented some changes in plim to help fight those lazy impulses.
-
The
acceptcommand already told me when an incoming file included lines from the previous month, but I had let myself get into the habit of assuming they were always duplicate records. Nowacceptwill also tell me if any of those lines are about unknown transactions. I’ll be much less likely to skip those. -
I’ve also changed the way
assignprocesses duplicate records, so accepting a duplicating tallysheet will add no real friction. Now it shows me all exact duplicates waiting in the unassigned pile right away, so I can accept them all at once. By eliminating the annoyance of having to process each duplicate record on its own, I’m less likely to ignore the previous vault records whenacceptinga new tallysheet.
These new features always feel obvious when I make them. Why on earth didn’t I write the code that way in the first place? But hindsight needs no glasses, so I’ve stopped beating myself up over lessons like this and just enjoy the fact that it’s working now.
I’m sure a whole bunch of new and exciting issues will pop up the moment some stranger on the internet tries to take plim for a test drive in their own budgetary world, but for me here in mine, it’s starting to feel like plim is actually earning its keep.