Emacsen's Blog

Implementing Profit First with Plain Text Accounting

In my previous post, I discussed the principles of using Profit First, the Theory of Constraints, and Plain Text Accounting. Several people asked me to get into the practical of how Plain Text Accounting can work with Profit First, so that's what this post is about. If you haven't read the previous post, I suggest starting there.

I'll discuss two approaches to integrating Plain Text Accounting with Profit First, one that applies Profit First directly, and the other which lets you keep your traditional bank account structure while having most of the benefits of Profit First, which is what I do personally.

What is Plain Text Accounting?

Strictly speaking, Plain Text Accounting is about bookkeeping, rather than actual accounting. It's a way to store information about your accounts and transactions, and then to generate queries and reporting information from that data. Unlike most accounting packages, data in Plain Text Accounting software is all stored in plain text files in a simple but powerful file format.

The three most popular Plain Text Accounting packages are Beancount, hledger, and Ledger, which is the original. All three programs use a similar file format, though each has its own slight variations.

What is Profit First?

Profit First is a method of accounting for small businesses that prioritizes business health by enforcing prioritization of core business expenses such as taxes, owner compensation, and profit.

Profit First is based on a system called Envelope Budgeting, where the household uses physical envelopes to store cash that's then used to pay for various household expenses such as rent, utilities, and food. Profit First mirrors this by suggesting that business income is put into different bank accounts.

The Bank Accounts Profit First Recommends Are:

  1. Income
  2. Taxes
  3. Owner's Compensation
  4. Profit
  5. Rainy Day
  6. Operational Expenses

One of the key aspects of the system is that money flows in very predictable directions, from your income account to the other accounts. Then at tax time, money is withdrawn from the tax account, owner's compensation from the owner's compensation account, and so on.

Keeping the business money in multiple accounts separate has several features. Firstly, by having clear delineations between accounts, it makes it more challenging to pull money out of one account and use it in another. It also makes it easy to use your bank accounts as a dashboard of your business's health at any time.

At the same time, setting up multiple accounts at most institutions can be challenging or cumbersome. Some banks only allow customers to have a single checking accounts or a single savings account. Others may allow for multiple account, but charge additional fees, or customers may find that the website or apps don't work properly with this configuration.

Using Profit First Accounts with Plain Text Accounting

If you use Profit First as described, with multiple accounts, integrating Profit First and Plain Text Accounting is trivial. You'd simply create Asset accounts for each of your Profit First themed bank accounts, such as:

Assets:MyBank:Taxes Assets:MyBank:Profit Assets:MyBank:OpEx

And so on, and then… well, that's it. You're done.

If your accountant complains about all of these accounts at tax time, you can use your Plain Text Accounting software to aggregate the values of the accounts when you submit your balance sheets to the accountant at tax time. Similarly, it won't matter to your accountant which accounts are used in your transactions.

Problem Solved.

Using Plain Text Accounting to "Fake" Profit First Accounts

If you're using a single bank account, like I do, that's where things become a little trickier.

I didn't want to change banks, and my bank wasn't very friendly to having me have six bank accounts, so I decided to find a way to implement Profit First without changing the underlying accounts. This turned out to be doable, but harder than I thought it would be.

In Double Entry Bookkeeping, money is neither created nor destroyed, and it also can't be in two places at once. If your money is in an account named Assets:MyBank:Checking, you can't earmark it to be in another account such as Assets:MyBank:Tax.

I struggled with this for several months until I came across a blog post entitled virtual postings aka envelopes which described how the author uses "Virtual Postings" to manage his personal budget. Unfortunately, the bookkeeping software I was using, Beancount, does not support virtual postings, but both Ledger and hledger do, which prompted me to switch.

Beancount is also very strict about the top-level account names, but since neither Ledger nor hledger are, I simply created a set of new accounts corresponding to the Profit First accounts, and use Virtual Postings to address them.

Because Profit First is based on Envelope Budgeting, I call these accounts Envelope accounts, such as Envelope:Income, Enveolope:Taxes and so on.

Then when entering a transaction, I make a virtual posting corresponding to the associated envelope. For example:

2024-01-01 * Hosting
    Expenses:Hosting:HostingProvider          100.00 USD
    Assets:Checking:MyBank
    (Envelope:OperatingExpenses)             -100.00 USD

Then instead of looking at my physical accounts, I can run hledger bal Envelope to look at my envelope accounts and get my snapshot/dashboard:

 50.00 USD  Envelope:Income
300.00 USD  Envelope:OperatingExpenses
 20.00 USD  Envelope:Profit
100.00 USD  Envelope:RainyDay
 50.00 USD  Envelope:Tax

And voilĂ , now we have Profit First without changing banks.

But it's not quite that simple...

Each transaction needs to be recorded twice - once for the physical account and once for the virtual account. Moreover, virtual posting don't balance. In Double Entry bookkeeping, money is neither created nor destroyed, it just moves through the system. In our case, because we're using the same money in our physical and our virtual accounts, the accounts can't balance. The effect of that is that it's more difficult to verify our virtual accounts and to know if they're accurate, and then to be sure our balances are what we think they should be.

Accounting for income is even a bit more tricky. When income comes in, it needs to be recorded from the income account (the income source), the physical asset it's going to (i.e. the real bank account), then each Envelope account according to the Profit First percentages.

While straightforward, it's a bit of a pain, as we can see in this example:

2023-11-03 * Income from Income Source
    Assets:Checking:MyBank                    100.00 USD
    Income:IncomeSource
    (Envelope:Profit)                          5.00 USD
    (Envelope:Tax)                            20.00 USD
    (Envelope:OwnerCompensation)              50.00 USD
    (Envelope:OperatingExpenses)              25.00 USD

Since the process of splitting the transaction into multiple accounts by percentage is not a feature of Plain Text Accounting, it's something that I do manually. I only draw my income from payment processors once a month, but if I were to draw them more frequently, I'd likely automate this process with some simple math and text templating. If I had frequent deposits made directly into my business account, I'd set up a second account at the bank specifically for income and then transfer over assets on a scheduled basis so I didn't have to do the Profit First math every time. While this isn't the six bank accounts that Profit First suggests, it's a middle ground that would be helpful.

On that note, I should mention that using these virtual accounts also makes working with the various CSV to ledger file conversion tools more challenging because the Plain Text Accounting tools I've seen aren't designed to record transactions twice. I could solve this with an intermediary processing step, but this isn't a problem for me since I manually go over my bank statements and put them into my books. If you wanted to automate this, I'd suggest that you have a secondary processing step where you run custom software to create the virtual transactions.

Can't We Cheat?

At this point, you might be thinking that all this work in creating and maintaining these envelope accounts is too much work, and it'd be easier to simply apply the Profit First percentages to your bank account's balance. After all- if tax is 20%, then just take your balance and say that 20% of it is tax.

That won't get us what we want because the idea of Profit First is that it applies as your income comes in. Money allocated to taxes will come out either annually or quarterly, and money allocated for owner's compensation will come out regularly as well, so the percentages as applied to the assets won't reflect that properly.

Finally, unlike with physical accounts, it's easy to pull money from your single account outside the Profit First model, for example to cover an unexpected bill. This goes against the Profit First model.

Is it Worth It?

With all the work involved with virtual accounts, is it worth doing?

For me, the answer has been yes.

Understanding my assets and income in terms of healthy accounts helped me understand by business in a way that I hadn't before, and I suggest that any small business owner look at Profit First as a way to have a better grasp of their finances.

That said, if I suggest that if you do want to use Profit First and your banking needs are anything beyond the trivial ones mine are, that you find a bank that supports multiple accounts and use the Profit First model directly. Not only will you be getting more benefit from the system, your Plain Text Accounting system will be much easier, and you won't have to do any of the virtual account stuff.

On the other hand, if you are keen to work with a bank that makes this difficult, or you want to "test the waters" of Profit First without changing everything, then using Virtual Accounts can be a nice way to use Profit First, and now you have the blueprint on how to implement it.

Accounting