Difference between revisions of "Zero-Sum Budgeting"

Revision as of 02:31, 2 December 2018

Zero Sum Budgeting - an experiment.

Most budget ideas and the current (v3.3) budget implementation use a separate data structure.

I think envelope budgeting can be implemented very efficiently by reusing the data structures already used for regular transactions.

A solution: Create another type of transaction.

There's already u(n)reconciled, (c)leared, (y)reconciled, (v)oid transactions. And (f)rozen I believe is unused. Let's create a new type - (b)udget. But the balances are handled differently.

It would require some UI and calculations changes --

1. The account budget balance is always maintained similarly to Running/Reconciled/Cleared Balances. But it would count all previous split-values *and* the (b)udget split amounts. However the budget running balance is not shown in the default register. This means, existing balances/register are unchanged.

Let's say we're in a bank account register

   1/1    Opening $10000 Running Balance=$10000, Cleared/Reconciled Balance= $0, Budget=$10000
   2/1    Income +$1000  Running Balance=$11000, Cleared/Reconciled Balance= $0, Budget=$11000
   3/1    Food -$50            Running Balance=$10950, Cleared/Reconciled Balance= $0, Budget=$10950
   4/1  <--- today              Running Balance=$10950, Cleared/Reconciled Balance= $0, Budget=$10950

2. We create another Register Action: "Allocate Budget". "Allocate Budget" means we create a (b)udget transaction with multisplits from assets to expense accounts. By default we allocate the whole $10950. The $10950 in an asset account means "the amount remaining to allocate".

   4/1 Budget Transaction type "b"
          Asset:Bank -$10950
          Expense:Food $200
          Expense:Gas $200
          Expense:Taxes $300
          Imbalance $10250

Now the state of the Bank register is:

   5/1 Running Balance=$10050, Cleared/Reconciled Balance=$0, Budget Balance= $0

And the Food register is:

   3/1 Food $50      Running Balance=$50 Cleared/Reconciled=$0 Budget=$50
   4/1 Budget $200 Running Balance=$50 Cleared/Reconciled=$0 Budget=$250
   5/1 <--- today    Running Balance=$50 Cleared/Reconciled=$0 Budget=$250

3. We can allow the imbalance account to collect unbudgeted/spare monies. Or we can decide to allocate an amount smaller than $10950, leaving the 'budget' balance in the bank register a positive value.

4. Now the Food account has several balances accessible via API

   Running Balance $50 - as usual counts all split-values from "n" "y" "c" including future splits.
   Unreconciled $50 - counts splits-values from "n"
   Cleared $0 - counts splits-values from "n" "c"
   Reconciled $0 - counts splits-values from "n" "y" c"
   Budget $250 - counts all split-values from "n" "y" "c" "b"

5. A Budget report could be created, comparing the various expenses' running balances vs the budget balance. The difference is the amount left to spend in this category. For the food account it's 250-50 = $200 left to spend.

6. Anytime the user wishes to allocate more budget to food, they can simply create (b)udget transaction from Bank or Imbalance account to the Food account. 7. This means, in the account register, we'll see regular transactions which can be reconciled with the bank statement. We'll also see budget transactions, not reconcilable with the bank statement. Perhaps they should be a different color/background. But this is ok, because their amounts do not affect the account running balance. The Reconcile window can also filter them out. The existing reports are unaffected. The query mechanism should ignore them by default.

What do we think of this?

The budget balance for an asset account represents "money remaining to allocate", and the budget balance for an expense account effectively represents "the upper limit that I'll allow this account to be". The budget balance, minus running balance represents "money left in envelope". I can increase envelope contents by transferring budget money from asset to the expense accounts.

I wouldn't know how to handle credit card nor loan interest.

An implementation was attempted, abusing the 'v'oided transactions to act as budget transactions, and modifying the status bar to display the voided/"Budget" balances.

Screenshots are available as follows: