About My Finances

It's possible that this page is fully 50% of the impetus for publishing this website. I'm so profoundly fascinated by personal finances and the story that your income, expenses and investments say about you, that I'm eager to put my own life on the books and see how it holds up.

The truth is, though, I have a long way to go before I have anything close to a workable personal finances page. It's something that will surely involve the creation of a whole new library in PHP to parse my GnuCash file and extract the data that I want from it, and it may even result in the foundations of the new personal finance software that I've been wanting to create ever since my roommates and I managed our household expenses together on my very first web app, Bizlunch, back in the early 2000's.

So for now, we must be content with regular old transparency, rather than hypertransparency. Without further ado, I give you my personal GnuCash File. You can take a look by downloading GnuCash and opening the file with it.

Warning! This thing is a total mess. I keep wildly detailed accounts, and I've overloaded the system with all kinds of extra data, including a completely non-standard chart of accounts that includes accounts that I use for envelop budgeting; per-split quanitity data; and a sort of rough tagging system that I have yet to fully formalize. You can feel free to explore it, but it will undoubtedly be a confusing tangle of wires until I translate all the data into visuals at some point in the near future.

To get you started (for anyone who's crazy enough to actually download the file and take a look), here are a few things to watch out for:

Accounts Receivable vs Accounts Payable

I've all but scrapped liabilities in favor of keeping credit/debt accounts unified under Assets:Accounts Receivable. This is because most of my payables and receivables are with humans (like my roommate), with whom I go into and out of credit/debt status as we share expenses and square up. Thus, it's not uncommon for my Receivables to be in the red, indicating that I owe money on the account, instead of being owed money on it. I do still maintain a select few Liability accounts, but as a general rule, humans get accounts under Assets:Accounts Receivable, while businesses and other such entities get accounts in Liabilities.

Budgeting

My budgeting system is hugely complex. While GnuCash itself does have an adequate budgeting system for projecting expenses, it's not satisfactory to me in a number of ways:

  • Most importantly, it doesn't have any mechanism for envelop budgeting. In other words, the budget is static, based only on income assumptions made when the budget is made. What I wanted was an envelop budgeting system, where I could allocate new funds to an account and then deduct expenses from that account, giving me a realistic view of my current status given my real income and expenses. (For example, if I get a paycheck for $2,000, I can divide that $2,000 into various budget accounts until it's all used up. I might put $400 of it into a "rent" account, then when I pay rent, I deduct it from that same account, so I know where I'm at.)
  • Second, the built-in budgeting system only captures what you're going to spend your money on, not why you're going to spend it. This is because it's linked to expense categories, which are supposed to describe the "what" and not the "why".
  • Finally, I wanted something with a little bit less structure. Since the built-in budgeting was directly linked to your actual accounts, it wasn't easy to capture exactly what I wanted to capture.

So in an attempt to solve these problems, I created a parallel chart of accounts under the Budgets super-account. These budget accounts balance into a hidden account called Budgets:Budgeted Cash. Since my budget is not necessarily linked directly to income (i.e., I can arbitrarily allocate funds from savings or from loans or whatever, whever I want), this extra account allows me to maintain arbitrary budget amounts, and it allows me to create scheduled transactions that allocate funds regularly based on the amount that I want to be spending each month, independent of my actual income.

As a result of all this, I'm actually able to maintain a set of budget accounts that capture why I'm spending the money that I spend, even when that money bypasses my expense accounts completely. For example, I might buy a new seat for my bike. In my world, this is technically an investment in an asset, so if I ran an expense report, the new seat wouldn't be captured as an expense (because it's registered against the asset account that represents my bike, which, I know, is way more specific than most people would go). But I still spent the money, and I want to know how much money I spend and why. So when I register the transfer of money from my bank account into the asset account for my bike, I also register a parallel transfer from my Budgets:Personal Budget:Life Overhead:Transportation account back to Budgets:Budgeted Cash.

In some not too distant future, when I start working on my PHP GnuCash library, I'll be able to create reports from this that show a breakdown of why I spent my money (e.g., was this a personal expense? was it just overhead from living? was it charity? etc...) and—importantly—what the money was actually spent on, within each of those "why" categories. For example, I'll be able to show that, say, 30% of my expenditures are personal in nature, and of those personal expenses, 40% are food from a restaurant when I go on dates, 20% are gas expenses for road trips, and 40% are airfare and hostels for vacations, etc.

Extra Information

I've recently adopted a sort of tagging system that I use to capture extraneous information on splits. Much of this is for forward compatibility, for when I finally create an interface that will formalize and display this extra data. For now, though, it just tends to clutter my splits. My system is the following:

  • I use parentheses to capture which budget categories a split belongs to. This is in case I have a complex receipt that involves items across multiple budgets. For example, I might go to the grocery store and buy both toilet paper and tomatoes. The tomatoes come out of my food budget, while the toilet paper comes out of my personal hygiene budget. While this is captured directly in the system as extra budget splits after the expense splits, the system cannot know if it was the toilet paper or the tomatoes that represent the food expense. Thus, I add the budget in parentheses (e.g., (Budgets:Personal Budget:Life Overhead:Food:Food In)) after the description in the split to indicate which budget it came from. If it came from multiple budgets, I separate them with a pipe (|) character. If they're split unevenly, I add the amount in decimal or percentage after each budget account by adding a pound (#) sign.
  • I use square brackets ([]) to indicate quantities. If no unit is specified, the quantity is assumed to be pieces.
  • I use curly brackets ({}) to indicate tags. Tags are formulated the same way as accounts (with a colon (:) to indicate hierarchy), and multiple tags are separated by a pipe (|) character.

The Future

I'm really excited to have all these details finally available. It did actually take a considerable amount of time to set this all up, and I hope someday to be able to offer others the benefit of detailed data systems without all the hassel of setting them up. My goal is eventually to create a unified public data platform, for which the first pieces of data will be financial. As trivial as it may be, I dream of being able to find out what the average price per pound of tomatoes is in Florida vs Illinois, purchased from Mariano's vs purchased from Jewel, oranic vs normal.

For now, though, I cannot but offer my own raw data for anyone who wishes to interpret it. It's still important to me to offer my finances file, if only symbolically, because I still feel strongly about what our finances say about our lives. But for anyone who's actually crazy enough to be as interested in this stuff as I am, you'll have to wait a bit before it's actually easy to consume :).