Sticky Context

This post makes several references to the blog post on the single context problem. You don't need to have read it for this article to be useful, but it explains the problem in depth, and is used for contrast.

In the world of financial management, account-based systems are the backbone of tracking and organizing monetary transactions. However, these systems face a challenge known as the Single Context Problem. The problem can't be avoided in account-based systems and causes a number of issues, but chief among them are:

• Exponentially growing account complexity
• No ability to decompose existing accounts
• Cannot handle multiple perspectives

These combine to create a massive account surface area. You have two choices: either anticipate every possible category for your money in advance or invest significant time and money in secondary ledgering systems or hire an army human accountants. Whatever you choose, it's a nightmare.

It doesn't have to be that way. There is a clever way to side-step the single context problem by changing where you store the context.

To solve a big problem, think smaller

The single context problem stems from the restriction that you can only put information about money on accounts. As a result, every account must comprehensively describe the complete history of all the money it contains or risk losing data. To address this problem, we propose thinking smaller—describing individual pieces of money rather than relying solely on accounts.

Sticky context allows you to describe individual piece of money, instead of just accounts. The context sticks with the money the entire time it's in your system, no matter what accounts it moves through.

Now, let's illustrate this concept with practical examples.

Practical example

We'll use the same example from the single context problem post. We have a small baking business that sells two products: cookies, and cupcakes. We have two venues we sell at: an art fair, and a bake sale. Our goal is to break down our revenue, profit, and expenses by product and venue.

We'll start in the same place as before with three basic accounts(1): revenue, profit, and expenses.

We still want to be able to understand product and venue based revenue, but instead of creating new accounts for that, this time we'll rely on the sticky context property.

Each deposit we make into revenue we'll tag with the product that was sold, and the location we sold it at. Let's make a deposit and see how it looks.

Notice how the context is tagged on the deposit K1 itself, instead of having separate revenue accounts? We can still tell at a glance what product and location the money is from, but we keep our simple account structure!

Now, let's take this simple example and break down the revenue into profit and expenses. We know that for cookies our material/labor cost is $5 so we'll move $5 to expenses, and the rest to profit.

We split up the money into K2 (profit) and K3 (expenses) to categorize the money. Since context sticks with the money, the new credits in our profit and expenses accounts retain their information about the product and location. Additionally, the system keeps a record of K1 in our revenue account, so if we want to look at just revenue we don't need to try to work backward from profit and expenses.

We can still easily ask questions about our money by venue, or product, but instead of the 16 accounts required in a standard account-based system we still have the 3 simple accounts that made sense to us in the first place. This is the power of sticky context:

Sticky context allows you to keep detailed information about your money, without bloating your account system.

Simplifying your accounts isn't the only benefit though, let's get crazy and do some things that would be really nasty to model with accounts.

Lunch money

We sold cookies at the art fair through lunch time, and ended up needing some lunch. We spent $10 on a quick snack to keep going, and now we need to record that in our expenses.

Here we moved K2 over to expenses, and added an additional tag called lunch to help us remember what it's for. We can see at a glance that K4 was spent on lunch, and that it came out of our cookie profit at the art fair. There was no need to prepare a lunch or food account in advance, we just tagged the money as it moved.

In our account-based example, we would need at least the following accounts to capture the same information:

1. art fair revenue
2. cookie art fair revenue
3. cookie art fair profit
4. cookie art fair expenses
5. art fair fixed expenses
6. art fair cookie profit to fixed expenses

Even then, we'd be hoping that lunch or food, doesn't need to be distinct from other overhead expenses like booth fees or labor. If we need cupcake varieties of those accounts we're looking at 16+ accounts to keep up.

Freedom with String Theory

But what if I love having really specific accounts?

Not to worry, with String Theory you are still free to create as many accounts as you want. Whatever makes sense for how you think about your money is fine by us. However, you are no longer required to have a huge number of really specific accounts just to organize your money. You are free to have only meaningful accounts, while sticky context keeps track of the details.

Up next

Now that we've shown how String Theory's innovative context management can help you keep your accounts simple while keeping detailed business information. In our next post the Zero Sum Fallacy we'll talk about some of the financial assurances provided by double-entry accounting, and how String Theory improves upon them.

(1) String Theory uses groups instead of accounts, in most cases they are interchangeable terms. See the groups documentation for more information.