Possible improvement to budgets using budget rules

[Tim Abell]

Hi Bryce,

Yes, that's pretty much it, though it's as much for day to day <£100 
decisions as for larger purchases. I plan to schedule everything I that 
I know the amounts and dates for (eg yearly car insurance and monthly 
rent/mortgage, income), and use the budget system for planning what I 
expect to spend on everything else (eg grocery shopping and petrol). I 
figure the only other piece of information I need is the account balances.

I don't think having gnucash look at past transactions will help me 
personally with forward planning. Gnucash doesn't have the information I 
have about changes in circumstances and plans (eg pay rise / tax rise / 
new car and all its expenses). I think it will be easier for me to tell 
it my plans explicitly in terms of individual transactions and budgets 
than figure out rules for educated guesses.

It's worth mentioning that I don't track every penny, especially cash, 
and instead just have a budgeted cash expenditure account that I try not 
to put too much through, so this reduces what I have to keep track of.

Of course all this is moot till I actually manage to stump up the code :-)

Tim Abell

Bryce Poole wrote:
> Tim,
>
> So if I understand you correctly you want the application to help you
> determine if you what your finances would look like if you decided to
> make a large extended purchase.  To answer this you are looking at
> your scheduled transactions to anticipate future expenses.  This
> coupled with the past income you can estimate your future finances.
> However, wouldn't this necessitate scheduling every expense?
>
> Why not average your last n months and extrapolate that into the
> future?  With enough past history, it seems that it would include all
> the previous scheduled transactions.  Or are your future expenses
> being estimated with scheduled transactions?
>
> I like your idea of anticipating your future budget in order to make
> an informed decision before a large purchase.
>
> Bryce
>
> On Thu, Aug 13, 2009 at 4:22 PM, Tim Abell<tim at timwise.co.uk> wrote:
>   
>> Hello,
>>
>> I have similar ambitions though a slightly different take. Thought I'd drop
>> you a quick line to let you know where I'm at and say hello!
>>
>> Like you I wish to be able to say yes/no to an optional expense based on all
>> the available information about current and future finances, something that
>> it turns out is rather hard to do in you head when put on the spot!
>>
>> My current plan is to draw a graph of predicted account balance over time,
>> based on scheduled transactions and budget amounts.
>>
>> For purchase decisions, I will then be able to make a quick mental
>> calculation looking at the graphs as to whether I would be happy with the
>> future low points. For goals I will be able to see how long it will take to
>> reach a desired balance, and I will be able to experiment with budgets and
>> scheduled transactions and see the long term effects. It will also help plan
>> regular inter-account transfers so that they average out correctly as
>> irregular transactions come and go.
>>
>> I have managed to get a graph of existing balances more or less functional,
>> and have since taken a break to move house and play with my neo freerunner
>> (yay!).
>>
>> In order to do the predicted balances I need to associate the budgets with
>> accounts (otherwise I can't tell which account will be affected), and pick a
>> date that the budgeted amount will be deducted (hmmm). I also had issues
>> with lack of access to schedules transactions from the guile side, but I
>> haven't looked at the code for some time.
>>
>> We shall see how much time I can find to apply to this, but I still hope to
>> do this at some point this decade!
>>
>> Some relevant bugs:
>> http://bugzilla.gnome.org/show_bug.cgi?id=350675
>> http://bugzilla.gnome.org/show_bug.cgi?id=452716
>> http://bugzilla.gnome.org/show_bug.cgi?id=570011
>> http://bugzilla.gnome.org/show_bug.cgi?id=570012
>>
>> My code is scattered around http://github.com/timabell
>>
>> Good luck in your ambitions, and thanks for your thoughts. I sure did read
>> to the end ;-)
>>
>> Yours
>>
>> Tim Abell
>> http://www.timwise.co.uk/
>>
>> Bryce Poole wrote:
>>     
>>> I'd like to start out by thanking the gnucash team for all their hard
>>> work.  You have made a truly great product, and I am very grateful for
>>> it.
>>>
>>> Background:
>>> Long story short.  I have used both gnucash and QuickBooks.  Both seem
>>> focused on tracking income/expenses.  While useful, this doesn't tell
>>> me "Do I have the money to go out to eat or not today?"  (I do
>>> recognise that gnucash does have some budgeting available.  This would
>>> be an enhancement to the amounts per month.)
>>>
>>> Money management, which would answer this, is made up of two parts: an
>>> expense tracker (which gnucash does swimmingly) and capital
>>> allocation. Capital allocation meaning, I have X dollars for going out
>>> to eat per month.
>>>
>>> I want a money management system that meets the following goals:
>>>  - I want to understand what my current state of affairs are this
>>> moment so that I can make decisions about what to do today.  (Do I
>>> have enough to buy x? Am I living within my means?)
>>>  - I want a system that helps manage extra money that comes in
>>> occasionally.  (What do I do with this bonus?  Do I blow it completely
>>> or do I use it to buy down my mortgage?)  I don't want to make these
>>> decisions in the heat of the moment.  I want to make them when I am
>>> calm and ready.
>>>  - I want to save for future expected expenses and build up a buffer
>>> to take care of life's unexpected events. (Like Thanksgiving comes
>>> around and my grocery bill goes up for a month.  I want money in the
>>> account accumulated and ready for this.)
>>>
>>> What I came up with is the following:
>>>  1. Everything is an expense account.  I have both real expenses and
>>> planned expenses.  Real expenses are groceries.  Planned expenses are
>>> "My new car when I save up $10,000".
>>>  2. I create a "budget" that is just a set of rules.  Rules determine
>>> how much of my income do I put into the account every month.  (These
>>> are allowed to change every month.)
>>>  3. Accounts are allowed to accumulate balances over the months.
>>> Last month's unused surplus is added to this month's available amount
>>> or vice versa.
>>>  4. I "balance" my budget every month.  If I spend more than the
>>> total accumulated surplus, I have accumulated a deficit.  I am
>>> expected to move money from an account with a surplus to make up for
>>> the deficit.  This keeps me honest with my budget.  (This may not be
>>> everyone else's requirement.  Keeping a negative accumulated balance
>>> should be perfectly acceptable from the software's standpoint.)
>>>
>>> This is how I think this can be implemented:
>>> (I am about to use "examples" from my life, but I am going to use
>>> fictitious numbers.  Any resemblance to actual numbers is
>>> coincidental.)
>>>
>>> Accounts:
>>> Every budget account is an "expense" account (from gnucash's
>>> standpoint).  Accounts have three relevant values:
>>>  - actual amount posted against the account for the month (I bought
>>> $85 worth of groceries this month),
>>>  - budgeted amount for the month (I allocate, using a rule, $95 for
>>> groceries this month)
>>>  - accumulated amount for this month (I have $10 this month of surplus
>>> which is added to the $105 from the running total of previous months
>>> meaning next month's available amount starts with $115.  I will spend
>>> this surplus at Thanksgiving to buy a REALLY big turkey.)
>>>
>>> My "savings" accounts are simply "planned expense" accounts that
>>> accrue a balance waiting for me to save up to a specific amount before
>>> I spend it.
>>>
>>> I had difficulty at first wondering, what about assets?  My best
>>> solution is to create an account that can accumulate money toward an
>>> assets, such as a mortgage.  I could create an account called "Extra
>>> Mortgage Payment" that I save up money to pay against my mortgage.
>>> Once it is large enough for my bank to accept, I write a check and
>>> post it against the "Extra Mortgage Payment" account.
>>>
>>> Budget Account Rules: (This is probably the most different thing that
>>> doesn't currently exist.)
>>> The rules encapsulate my decision of how much to allocate toward an
>>> account per month.  These are set up hopefully when I am sane and
>>> before I receive extra cash and my logic gets all blurry.  This helps
>>> take away the emotion of highs and lows in my income stream.  (Even
>>> though the latest technology entices me, I don't forget the fact that
>>> I want my mortgage paid down AS WELL AS buying the latest in
>>> technology.)  The rules that I create form a master plan.  They are
>>> executed each month by the software without my emotions (good or bad)
>>> getting in the way. (I still do want the ability to change the rules
>>> at anytime, even retroactively due to life changing events.)
>>>
>>> Rules can be both static and dynamic.  For example, I know that my
>>> water bill is static.  I pay $15 every month.  So I make a rule for
>>> the MONTHLY FIXED amount of $15.  My groceries are fairly consistent
>>> also, but I want to save up an extra $50 for Thanksgiving.  So
>>> normally I spend $100 per month.  So I add $10 per month for a MONTHLY
>>> FIXED of $110, but I set an ACCOUNT MAX of $50.  Over the months as I
>>> keep my grocery expenses below $110 per month, the surplus will begin
>>> to accumulate, but it will be capped at $50, I know that any more than
>>> $50 would be too much.
>>>
>>> Once all the static accounts are added up, it is subtracted from the
>>> income to determine the remaining income.  This remaining income is
>>> money that can be managed (or in other words, I can choose where to
>>> put this portion of my money).  So the dynamic rules come next.  By
>>> way of an example, let's say that I have a mortgage and that I want to
>>> put a portion of the remaining income against it.  I would take 5%
>>> (PERCENTAGE) of the remaining income for the extra payment up to $500
>>> per month, or MONTHLY MAX.
>>>
>>> Now I can put these four values together (MONTHLY FIXED, ACCOUNT MAX,
>>> PERCENTAGE, MONTHLY MAX) to make some really useful decisions/rules.
>>> For example, I want to save up for the annual car insurance payment.
>>> It is $1200 per year.  I have a slightly variable income so I can't
>>> just say put $100 per month in the insurance account, but I could put
>>> a guaranteed $80 per month expecting my extra income to make up the
>>> rest.  So I put a MONTHLY FIXED amount of $80 in the account.  Add 5%
>>> (PERCENTAGE) of the remaining into the account, not to exceed $1200
>>> ACCOUNT MAX.  Also, don't put more than $300 MONTHLY MAX into the
>>> account.  Just like that I can join all four parameters into a
>>> powerful rule that controls the budgeted/planned amount for the
>>> account that takes into account my variable income and it happens even
>>> when I have unexpected income.  As a bonus, the ACCOUNT MAX also
>>> serves as a reminder of how close I am to the goal.
>>>
>>> For clarification, I assume the percentages are actually just a
>>> weighted average.  So if all the accounts add up to 78% (not 100%),
>>> 78% is made equal to 100% and all of the remaining income is allocated
>>> using the weighted average.  This means that the user doesn't have to
>>> re-calculate the percentages every time one account's rule changes
>>> it's percentage.
>>>
>>> Also, I envision the percentage to be part of one of two items: an
>>> absolute percentage of income (like Richest Man in Babylon's pay
>>> yourself first 10% of your income first) or of the remaining income
>>> after fixed expenses are taken into account (5% of my manageable
>>> income for an extra house payment).
>>>
>>> The last rule is "just accept the expense".  I pay taxes every month.
>>> I don't plan the amount.  It accumulates as an expense and is removed
>>> from the total income when calculating the remaining income.
>>>
>>> So what did I do?
>>> I created a sample application that demonstrates the principles that I
>>> have discussed here.  It takes a gnucash database and displays the
>>> income and expenses.   It allows the user to create rules based on the
>>> criteria above: account max, monthly max, percentage of remaining
>>> income, and monthly fixed.  (I didn't include the ability to switch
>>> the percentage between Total Income and Remaining Income.  But I did
>>> do an automatic tithing calculation which is 10% of the Total Income
>>> for the Richest Man in Babylon calculation.)  These rules are valid
>>> for one month for one account.  They are stored back in the SQL
>>> database in a table "budget_rules".  It dynamically calculates an
>>> accumulation based on the rules, the income, and the expenses.
>>>
>>> One bit that may interest people is how I rendered the rule.  I have a
>>> two line rule.  The first line is the ACCOUNT MAX and has a three
>>> sided box above it to indicate it is the maximum.  The second line has
>>> the MONTHLY FIXED, the additional PERCENTAGE, and the MONTHLY MAX that
>>> looks like this: $100+5%<$200.
>>>
>>> I have also included the sample database I played with to demonstrate
>>> this.  It's small but I think it gets the point across.
>>>
>>> What do I want from the community?
>>> I would love some feedback. Do you like the idea?  Should we add it to
>>> gnucash or should it exist as a "sister" app?
>>>
>>> I potentially could add this feature to gnucash, but it would take me
>>> quite a while.  (I would have to learn the underlying library, the
>>> gnucash way of doing things, determine how to properly architecture it
>>> to fit the current architecture, and the like.)  For the record, I
>>> would LOVE to see gnucash incorporate these ideas and add summary
>>> accumulation and planned columns to the accounts on the summary page
>>> to make money management more accessible.
>>>
>>> More work that could be done:
>>>  - The budget rules could be extrapolated into the future and the
>>> expenses averaged to see the current situation X months from now.
>>>  - Multiple budgets could be added for evaluating different life
>>> decisions (what would my life look like if I buy this $150,000
>>> property).
>>>
>>> The Sample Implementation:
>>> Data storage
>>> I am using a SQLite database from the latest version of gnucash 2.3.x.
>>>  The rules are stored in a table "budget_rules".  The table is
>>> comprised of rule_guid, account_guid, month, monthly_fixed,
>>> monthly_max, percentage, and account_max.
>>>
>>> WARNING: THIS WILL ADD A NEW TABLE TO YOUR SQL DATABASE.  YOU WILL
>>> HAVE TO RUN SQLITE3 AFTERWARD AND TYPE: DROP TABLE budget_rules;  to
>>> get rid of it.
>>>
>>> *************** Always use a copy of your database if you run this
>>> against something that matters to you. :) *************
>>>
>>> Library:
>>> I am using Qt because I happen to know it.  I don't know the library
>>> gnucash is based on.  I respect their choice and make no complaint of
>>> it here.
>>>
>>> Sample App Architecture:
>>> The sample revolves around the class, BudgetClass.  The BudgetClass
>>> includes a vector of AccountClass.  The AccountClass queries the
>>> database to determine what the total expenses were for a month.  It
>>> has a vector of float that record the accumulated amount for the
>>> account.  The AccountClass also has a vector of RuleClass.  The
>>> RuleClass is in charge of creating/updating/deleting rules as they are
>>> used by the account.
>>>
>>> Qt specific:
>>> There is a BudgetModel that interacts with the BudgetClass.  There is
>>> also a delegate that colors the table and renders the rules in their
>>> special way.
>>>
>>> Log:
>>> There is a cool (to me) logging class called LogClass with helper
>>> Logger.h/c.  It is a macro that takes a domain that calls into
>>> Logger.h/c.  The logger function formats the call and sends it to the
>>> LogClass.  The LogClass evaluates the domain add determines if the log
>>> message is allowed.  Currently the domains are specified in the
>>> LogClass creator and it only outputs to cerr.  It is simplistic, but I
>>> think it could easily add a file for specifying domains and alternate
>>> outputs.
>>>
>>> To build the sample:
>>> Download the QT SDK.  Open the gnufinance.pro file from within
>>> qtcreator.  Build.  Run.  Enjoy.
>>>
>>> Known Issues:
>>> - It doesn't update the budgets when a rule has changed.  Just restart
>>> the application.
>>> - If compiled for the Mac, the rule editor doesn't stay up, it closes
>>> immediately.  If you use the debugger and walk the portion of the code
>>> that displays the rule editor (in the delegate), the editor will stay
>>> open and you can modify the rule's contents.  This is not a problem on
>>> Ubuntu.  I have not tested this in Windows.
>>> - I highly suspect that there are several calculating bugs still in
>>> the code.  DON'T USE THIS WITH ACTUAL MONEY!  THE ALGORITHMS HAVE NOT
>>> BEEN VERIFIED.
>>>
>>> If you have read all the way down here. THANK YOU!  I appreciate your
>>> consideration and feedback. What do you think?
>>>
>>> Bryce Poole
>>>
>>> My employer is Intel, but they are no way involved in the development
>>> of this sample.  Nothing I say or imply should be a taken as a
>>> reflection of the attitudes or opinions of Intel.
>>>  ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> gnucash-devel mailing list
>>> gnucash-devel at gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>>
>>>