Difference between revisions of "Budget Requirements"
(Moved the content over from the history page and added info on budget categories/Grouping) |
(Did some more work on the sections about saving money up in a budget) |
||
(5 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | This section defines the requirements for Gnucash budgets. It is intended to present | + | This section defines the requirements for Gnucash budgets. It is intended to present what we want out of budgets so that we can stop going around in circles on the variety of issues. |
=Some Fundamentals= | =Some Fundamentals= | ||
Before getting into the types of budgeting it is worth considering some fundamentals that apply to all budgets. | Before getting into the types of budgeting it is worth considering some fundamentals that apply to all budgets. | ||
+ | |||
+ | ==What is a budget? (And what kinda isn't)== | ||
+ | Lets take two examples: | ||
+ | Eg 1 - I'm a successful small business. I've entered all my predicated revenue and expenses into my budget for this financial year, and have found that by April next year I'll have a spare $10,000 to buy that extra forklift that will raise productivity. So, knowing the forklift will need a $1000 deposit, I budget $1000 in March, and then $9000 in April for it. The forklift gets paid for and delivered in April as planned - but cost $200 extra because it was imported from overseas and the exchange rates changed. Oh well, still worth the extra productivity - happy boss! | ||
+ | |||
+ | Eg 2 - We're a family of four. Money is always tight, but we make do quite well. We think it is important to regularly fun stuff - eating out, toys for the kids, holidays, etc. So we want the ability to save up for these throughout the year. So we enter in all of our known expenses into our budget, and figure out how much we can allocate to all of the "luxury" plans we have. So we want to enter $100 per month against each luxury account (Expense:Take away, Expense:Toys, Expense:Holidays) and have GNUCash add up the numbers as time goes on. | ||
+ | |||
+ | Eg 1 is 'budgeting' from an accounting perspective. The boss planned how much he wanted to spend and when, and spent that amount in those times. If time was delayed or brought forward, he/she can run reports to see the effects (in effect, controlling/managing their finances). Note that the money is spent at the time it was budgeted for. | ||
+ | This is why Eg 2 is "kinda not really" budgeting. It is the classic way many (most?) individuals like to have at least some of their money managed - they want to designated small portions of the <b>actual cash already in their accounts at the time</b> to a future application. The future application isn't necessarily of a specific amount - they just want it to keep accumulating until they spend it. The holiday is a classic example. They aren't going to spent $100 every month from the holiday account. They just don't want to spend that $100 every month so that they have $1200 at the end of the year to travel to a beach for Xmas (or whatever religious or non-religous holiday this family happens to like). GNUCash doesn't do this kind of budgeting easily - budget numbers represent an expected future state for that account. So when you enter a number against that account, you are saying that the account will change by that much. So the holiday account of this family is better viewed as an artificial sub-account of their bank account, rather than an Expense account. Indeed, many people solve the problem in exactly this way: They create the sub-accounts to their main bank account, and set up scheduled transactions every month to transfer the amounts in there. Because GNUCash will roll up the numbers into parent accounts, they can still see the total "real" amount of money in that account, whilst viewing the artificial sub-account when they wish to. The '''extreme''' disadvantage of this is that reconciling becomes very difficult. | ||
+ | |||
+ | Whilst you read this page (and definitely before you request features) you should consider exactly what you are requesting - does it make sense from an accounting perspective? Am I wanting something to help in budgeting for actual expenditure at a specific time? Or am I trying to get artificial numbers of money I can afford to spend on something at a given time? | ||
+ | |||
+ | The above is one of the main differences between using "Categories" vs "Accounts" for budgeting. GNUCash using the latter is VERY powerful. But for your individual application, it may not be intuitive. | ||
==Time Periods== | ==Time Periods== | ||
Budgets need to allows the user to set the overall time period for the budget (e.g. FY 17/18) and also the gradation of time within (e.g. budget by the month or the fortnight). Fortunately this is already a fundamental property of Gnucash and is easily implemented and maintained. | Budgets need to allows the user to set the overall time period for the budget (e.g. FY 17/18) and also the gradation of time within (e.g. budget by the month or the fortnight). Fortunately this is already a fundamental property of Gnucash and is easily implemented and maintained. | ||
+ | |||
+ | In some instances, the "ideal" budgeting tool would allow us complete flexibility in budgeting time periods between diffent accounts. For example, I might budget my internet bill at $59.99 per month (for 12 periods of the year). But I would budget my food at $200 per week. Of course, I would budget my train tickets as $7.80 per <i>working day</i>. | ||
+ | So selecting an account would change the periods (columns) to reflect the periodicity of that account, and the GUI would calculate/show the derived values within this period structure for the other accounts (so default would probably split the internet bill as $55.99/days_in_this_month when selected). | ||
+ | |||
+ | Unless people out there REALLY REALLY want this feature, I recommend we don't aim for the ideal... | ||
==Constrained vs Planned Budgeting== | ==Constrained vs Planned Budgeting== | ||
Line 18: | Line 36: | ||
Again, not a type of budgeting, but simply constraints that may be applied to any type of budget. In this situation, the entity is dependent on sufficient cash coming in BEFORE being able to pay expenses or make transfers. Different from 'constrained vs planned' of the previous section because in that situation the person was constrained to meeting a defined budget amount. In this one, the person is constrained by not being able to spend the money until they receive it. | Again, not a type of budgeting, but simply constraints that may be applied to any type of budget. In this situation, the entity is dependent on sufficient cash coming in BEFORE being able to pay expenses or make transfers. Different from 'constrained vs planned' of the previous section because in that situation the person was constrained to meeting a defined budget amount. In this one, the person is constrained by not being able to spend the money until they receive it. | ||
− | This situation is difficult to allow for in a budget, because it requires knowledge of when income/expenses are expected within the | + | This situation is difficult to allow for in a budget, because it requires knowledge of when income/expenses are expected within the budget period - something Gnucash budgets currently don't allow for. For this to work, more granuality would be required within each budget period (ability to split each period into "days" for data entry/viewing?). Either way, there is currently no feature request for this within Bugzilla. Users that want this should create one and/or post to the user mailing list. |
== Budget "Categories", and grouping budget accounts in Gnucash == | == Budget "Categories", and grouping budget accounts in Gnucash == | ||
Line 25: | Line 43: | ||
In Gnucash, the account tree groups together common accounts (which are basically categories of expenditure from a budget perspective), meaning the user does need anything separate to budget. | In Gnucash, the account tree groups together common accounts (which are basically categories of expenditure from a budget perspective), meaning the user does need anything separate to budget. | ||
− | In some circumstances, users require a different way of grouping their budgeted accounts to make the overall budgeting process more useful. For example, say the user's account breakdown groups all expenses under one branch, and income under another. However, for budgeting they want to view everything from their rental property under one branch, everything from their shares account in another etc etc. Without being able to have a separate budgeting account tree from the main tree, this | + | In some circumstances, users require a different way of grouping their budgeted accounts to make the overall budgeting process more useful. For example, say the user's account breakdown groups all expenses under one branch, and income under another. However, for budgeting they want to view everything from their rental property under one branch, everything from their shares account in another etc etc. Without being able to have a separate budgeting account tree from the main tree, this would require amending the main tree (which is not good accounting practice). Additionally, being able to create more than one different structure for different budget analysis would be impossible. |
− | + | In a way, this is also a philosophical discussion of "Report vs Main GUI". You can easily create saved reports that run purely on selected accounts - so one for your property that only has those accounts, and another for your Shares that has only those. The downside being you have to find the account in the main window if you want to change it - you can't tweak your budget as you look at the report (but you can open the report on one screen and the budget on another if you have dual monitors...). | |
+ | |||
+ | ==Saving up money for a big purchase in a budget== | ||
Many businesses and individuals need to track budgets over a long time period - even after closing the books and reopening new ones. Therefore budgets need some way of being able to hand across the budgeted amount to the next reporting period. If I budgeted $100 per month into my 'holiday' account, I want this amount to increase every time period until I eventually have a massive holiday expense out of that account when I take a trip to, let's say Cairns, Australia (awesome beaches! Where the bloody hell are ya?). In this case, I want the budgeted amount to continually get passed across to the total for the budget of the year, getting carried over to the next year (or time period) if I close the books. This money should not be touched for day to day use - i.e. When I check how much I can afford to budget I don't want this money being shown as able to be spent. | Many businesses and individuals need to track budgets over a long time period - even after closing the books and reopening new ones. Therefore budgets need some way of being able to hand across the budgeted amount to the next reporting period. If I budgeted $100 per month into my 'holiday' account, I want this amount to increase every time period until I eventually have a massive holiday expense out of that account when I take a trip to, let's say Cairns, Australia (awesome beaches! Where the bloody hell are ya?). In this case, I want the budgeted amount to continually get passed across to the total for the budget of the year, getting carried over to the next year (or time period) if I close the books. This money should not be touched for day to day use - i.e. When I check how much I can afford to budget I don't want this money being shown as able to be spent. | ||
− | + | But as discussed in previous sections - this is not really "budgeting". Budgeting is planning the future states of your accounts. In this case we are artificially sectioning out some of our money for a future purpose, rather than performing any accounting function. Whilst the website REFERENCE ME PROPERLY!!!! gives an idea of how to use liabilities, this also creates problems. We are not really incurring a liability here (you don't owe anyone, not even yourself...) Creation of a liability increases your assets, whereas this situation is decreasing the amount of cash '''available''' to spend, without actually changing how much cash you have... We could consider this situation as giving a loan to our future selves: We are taking money out of our accounts and giving it to a container to hold until it accumulates and gets spent. But again, this won't work well for most applications. If we move the money from an account to a container, we have to physically move it (eg create a new bank account to put it in, create an envelope to put the cash in, etc). Otherwise reconciling wont work properly. Further, if we don't spend the the money out of that physical container, it creates a burden: you have to physically transfer money from the container to the account you spent out of (or else it wont be accurate). | |
+ | |||
+ | So in a way, we want a container structure around our assets that can keep track of what some of that money is being "saved for". We don't want this to change your actual asset accounts (as they are usually reconciled against actual statements). We would further need this to fit in with the budgeting - ie We need to have this as another line item in the budget screen so that we can see what is allocated as "saved" against the various expense accounts, allowing us to know that we can't spend that money lest we go into the red. | ||
+ | |||
+ | Note that the user would be interested in two aspects of this: | ||
+ | - How close am I to being at zero in my actual assets (am I going to have cashflow problems if I buy that painting??) - a question related to the actual asset amount plus the amount of assets I have allocated to future use. | ||
+ | - How close am I to reaching my limit I have set for this container? (am I going to overspend on my art allocation if I buy that painting??) - a question related to the amount I have allocated to future spending against this expense account compared to the previous spending against this expense account. | ||
Line 74: | Line 100: | ||
==Hiding accounts not of Interest== | ==Hiding accounts not of Interest== | ||
− | Budgets can often get quite large. Most users are interested in being able to hide accounts that are not of interest to them. It is unclear (to the present author, Matt G, 31 Dec 15) whether they are aware of Gnucash's ability to set accounts as hidden and show/hide them at will. | + | Budgets can often get quite large. Most users are interested in being able to hide accounts that are not of interest to them. |
+ | It is unclear (to the present author, Matt G, 31 Dec 15) whether they are aware of Gnucash's ability to set accounts as hidden and show/hide them at will. This may be inconvenient to switch on/off with a large number of accounts present in the book but is an option that is available at the moment. | ||
==Ability to look at Budget Evolution over time== | ==Ability to look at Budget Evolution over time== | ||
Line 86: | Line 113: | ||
- ANY MORE AUTOMATION IDEAS? PLEASE EDIT THE WIKI OR EMAIL gnucash-user@gnucash.org. | - ANY MORE AUTOMATION IDEAS? PLEASE EDIT THE WIKI OR EMAIL gnucash-user@gnucash.org. | ||
+ | == | ||
= Gnucash Budget Implementation = | = Gnucash Budget Implementation = |
Latest revision as of 09:05, 26 January 2018
This section defines the requirements for Gnucash budgets. It is intended to present what we want out of budgets so that we can stop going around in circles on the variety of issues.
Contents
Some Fundamentals
Before getting into the types of budgeting it is worth considering some fundamentals that apply to all budgets.
What is a budget? (And what kinda isn't)
Lets take two examples: Eg 1 - I'm a successful small business. I've entered all my predicated revenue and expenses into my budget for this financial year, and have found that by April next year I'll have a spare $10,000 to buy that extra forklift that will raise productivity. So, knowing the forklift will need a $1000 deposit, I budget $1000 in March, and then $9000 in April for it. The forklift gets paid for and delivered in April as planned - but cost $200 extra because it was imported from overseas and the exchange rates changed. Oh well, still worth the extra productivity - happy boss!
Eg 2 - We're a family of four. Money is always tight, but we make do quite well. We think it is important to regularly fun stuff - eating out, toys for the kids, holidays, etc. So we want the ability to save up for these throughout the year. So we enter in all of our known expenses into our budget, and figure out how much we can allocate to all of the "luxury" plans we have. So we want to enter $100 per month against each luxury account (Expense:Take away, Expense:Toys, Expense:Holidays) and have GNUCash add up the numbers as time goes on.
Eg 1 is 'budgeting' from an accounting perspective. The boss planned how much he wanted to spend and when, and spent that amount in those times. If time was delayed or brought forward, he/she can run reports to see the effects (in effect, controlling/managing their finances). Note that the money is spent at the time it was budgeted for. This is why Eg 2 is "kinda not really" budgeting. It is the classic way many (most?) individuals like to have at least some of their money managed - they want to designated small portions of the actual cash already in their accounts at the time to a future application. The future application isn't necessarily of a specific amount - they just want it to keep accumulating until they spend it. The holiday is a classic example. They aren't going to spent $100 every month from the holiday account. They just don't want to spend that $100 every month so that they have $1200 at the end of the year to travel to a beach for Xmas (or whatever religious or non-religous holiday this family happens to like). GNUCash doesn't do this kind of budgeting easily - budget numbers represent an expected future state for that account. So when you enter a number against that account, you are saying that the account will change by that much. So the holiday account of this family is better viewed as an artificial sub-account of their bank account, rather than an Expense account. Indeed, many people solve the problem in exactly this way: They create the sub-accounts to their main bank account, and set up scheduled transactions every month to transfer the amounts in there. Because GNUCash will roll up the numbers into parent accounts, they can still see the total "real" amount of money in that account, whilst viewing the artificial sub-account when they wish to. The extreme disadvantage of this is that reconciling becomes very difficult.
Whilst you read this page (and definitely before you request features) you should consider exactly what you are requesting - does it make sense from an accounting perspective? Am I wanting something to help in budgeting for actual expenditure at a specific time? Or am I trying to get artificial numbers of money I can afford to spend on something at a given time?
The above is one of the main differences between using "Categories" vs "Accounts" for budgeting. GNUCash using the latter is VERY powerful. But for your individual application, it may not be intuitive.
Time Periods
Budgets need to allows the user to set the overall time period for the budget (e.g. FY 17/18) and also the gradation of time within (e.g. budget by the month or the fortnight). Fortunately this is already a fundamental property of Gnucash and is easily implemented and maintained.
In some instances, the "ideal" budgeting tool would allow us complete flexibility in budgeting time periods between diffent accounts. For example, I might budget my internet bill at $59.99 per month (for 12 periods of the year). But I would budget my food at $200 per week. Of course, I would budget my train tickets as $7.80 per working day. So selecting an account would change the periods (columns) to reflect the periodicity of that account, and the GUI would calculate/show the derived values within this period structure for the other accounts (so default would probably split the internet bill as $55.99/days_in_this_month when selected).
Unless people out there REALLY REALLY want this feature, I recommend we don't aim for the ideal...
Constrained vs Planned Budgeting
For some entities, a budget is just a plan that informs whether they are meeting what they intended at the start of the period. In this case, it is no large issue to them if they overspend in one area - they are able to adjust their plans dynamically (typically because they are their own master and have enough cash in hand). Others are legally or morally constrained to their budget. They cannot (physically or perhaps morally) overspend on this allocated budget. If they don't have enough, they simply cannot spend. Note that this constraining action is subtly different from cash flow dependence constraints, discussed in the next section.
Constrained vs planned is not a type of budget - any of the budget discussed in sections below can be constrained or planned. It is a consideration to know what the entity using Gnucash is looking for (i.e. someone legally constrained will need to more accurately track their spending and plan better to ensure they don't go over, whilst a planned budget may not even be checked until the time period is over.
Cash flow dependent Budgeting
Again, not a type of budgeting, but simply constraints that may be applied to any type of budget. In this situation, the entity is dependent on sufficient cash coming in BEFORE being able to pay expenses or make transfers. Different from 'constrained vs planned' of the previous section because in that situation the person was constrained to meeting a defined budget amount. In this one, the person is constrained by not being able to spend the money until they receive it.
This situation is difficult to allow for in a budget, because it requires knowledge of when income/expenses are expected within the budget period - something Gnucash budgets currently don't allow for. For this to work, more granuality would be required within each budget period (ability to split each period into "days" for data entry/viewing?). Either way, there is currently no feature request for this within Bugzilla. Users that want this should create one and/or post to the user mailing list.
Budget "Categories", and grouping budget accounts in Gnucash
Budget Categories are used in some financial programs to allow users to group expenditures and allocate overall budgets to that group.
In Gnucash, the account tree groups together common accounts (which are basically categories of expenditure from a budget perspective), meaning the user does need anything separate to budget.
In some circumstances, users require a different way of grouping their budgeted accounts to make the overall budgeting process more useful. For example, say the user's account breakdown groups all expenses under one branch, and income under another. However, for budgeting they want to view everything from their rental property under one branch, everything from their shares account in another etc etc. Without being able to have a separate budgeting account tree from the main tree, this would require amending the main tree (which is not good accounting practice). Additionally, being able to create more than one different structure for different budget analysis would be impossible.
In a way, this is also a philosophical discussion of "Report vs Main GUI". You can easily create saved reports that run purely on selected accounts - so one for your property that only has those accounts, and another for your Shares that has only those. The downside being you have to find the account in the main window if you want to change it - you can't tweak your budget as you look at the report (but you can open the report on one screen and the budget on another if you have dual monitors...).
Saving up money for a big purchase in a budget
Many businesses and individuals need to track budgets over a long time period - even after closing the books and reopening new ones. Therefore budgets need some way of being able to hand across the budgeted amount to the next reporting period. If I budgeted $100 per month into my 'holiday' account, I want this amount to increase every time period until I eventually have a massive holiday expense out of that account when I take a trip to, let's say Cairns, Australia (awesome beaches! Where the bloody hell are ya?). In this case, I want the budgeted amount to continually get passed across to the total for the budget of the year, getting carried over to the next year (or time period) if I close the books. This money should not be touched for day to day use - i.e. When I check how much I can afford to budget I don't want this money being shown as able to be spent.
But as discussed in previous sections - this is not really "budgeting". Budgeting is planning the future states of your accounts. In this case we are artificially sectioning out some of our money for a future purpose, rather than performing any accounting function. Whilst the website REFERENCE ME PROPERLY!!!! gives an idea of how to use liabilities, this also creates problems. We are not really incurring a liability here (you don't owe anyone, not even yourself...) Creation of a liability increases your assets, whereas this situation is decreasing the amount of cash available to spend, without actually changing how much cash you have... We could consider this situation as giving a loan to our future selves: We are taking money out of our accounts and giving it to a container to hold until it accumulates and gets spent. But again, this won't work well for most applications. If we move the money from an account to a container, we have to physically move it (eg create a new bank account to put it in, create an envelope to put the cash in, etc). Otherwise reconciling wont work properly. Further, if we don't spend the the money out of that physical container, it creates a burden: you have to physically transfer money from the container to the account you spent out of (or else it wont be accurate).
So in a way, we want a container structure around our assets that can keep track of what some of that money is being "saved for". We don't want this to change your actual asset accounts (as they are usually reconciled against actual statements). We would further need this to fit in with the budgeting - ie We need to have this as another line item in the budget screen so that we can see what is allocated as "saved" against the various expense accounts, allowing us to know that we can't spend that money lest we go into the red.
Note that the user would be interested in two aspects of this: - How close am I to being at zero in my actual assets (am I going to have cashflow problems if I buy that painting??) - a question related to the actual asset amount plus the amount of assets I have allocated to future use. - How close am I to reaching my limit I have set for this container? (am I going to overspend on my art allocation if I buy that painting??) - a question related to the amount I have allocated to future spending against this expense account compared to the previous spending against this expense account.
Types of Budgets People Use
Gnucash is designed to be a powerful and versatile accounting tool for both business and personal use. For this reason, it must allow budgeting for both typical business applications, and typical personal applications. Nothing implemented in budgets should violate the existing principles of the program (e.g. the double-entry book-keeping nature of Gnucash).
!!!!! PLEASE EDIT THE WIKI OR POST TO Gnucash USER EMAIL (gnucash-user@gnucash.org) if you think of any more types of budgeting!!!!!
Cash Flow Only Budgeting
Some people are only interested only in budgeting their expenses against their income (i.e. do not take into account. "Zero Sum Budgeting" is a form of cash flow budgeting that is based on having nothing left over - allocating every dollar of income (see section in this wiki on Zero Sum budgeting). In Cash flow budgeting, some people are dependent on this cash flow and some are not (i.e. some require the income before it can be spent, whilst others have reserves of cash that mean they are more interested in the figures at the end of the time period.
Others, who have reserves in place are more interested in being able to balance out the amount they are spending so that by the end of year they should be roughly on target. Others still prefer the zero-sum budgeting strategy of forcibly assigning expected income to expected expenses. The Gnucash Gui should be set up to allow intuitive and easy budgeting for people in these circumstances.
- Cash flow only budgeting doesn't necessarily mean "no" reserves - it simply means that the budget is only managing cash flow***
Ideally one looking to implement a cash flow budget would have a set amount of reserves to start with. This money would be allocated in either a reserve (savings) bucket and used towards expenses or not, it's really up to the user. As new income comes in a new decision is made by the user to either send the new income to the reserve bucket or to be used towards expenses, and the cycle repeats itself when the next paycheck comes in.
Some do not have reserves up front so they would need to save something towards the reserve each cycle until the reserve is built up to a set amount ie...3 months salary and the budget software should be flexible enough to allow this. --Chazdiezal (talk) 12:37, 30 December 2015 (UTC)
Full Budgeting
!!! ANYONE WHO KNOWS THE REAL NAME FOR THIS, PLEASE EDIT THIS WIKI OR EMAIL the user request email (gnucash-user@gnucash.org). !!!
The term full budgeting in this context refers to the concept of fully planning for the future states within an accounting system. I.e. it considers both cash flow (income and expense) but also the overall effect on the entity (change in assets, liabilities and/or equity). For example, If an entity (person, business, alien overlord...) budgets for receiving an income of $1000 per fortnight, but only budget expenses of $900. A cash flow budget is simply happy that we are 'in the green', spending less than we are earning (although zero sum will tell you to put the extra $100 to work...). In a full budget, every expected 'transaction' has an effect on the business. So we are budgeting for not only the $1000 income and $900 of expenses, but also for where the extra $100 is going to end up. Perhaps this is simply an increase to a cash account of $100. Or perhaps this residual is going to be transferred to a liability account to reduce debt. Perhaps $500 needed to be transferred from a shares account at the start of the month with that and $600 staying in a cash account at the end of the period. Regardless, a full budget must consider the initial state of all accounts (whether they be Income, expense, Assets, Liability or Equity) at the start of the period, then budget the changes made to them throughout the time.
Do not confuse this with testing the viability of different possible options (coming up next)...
Financial Options Analysis
Again, not sure what this is called (PLEASE EDIT THE WIKI OR WRITE TO THE USER EMAIL, gnucash-user@gnucash.org if it has a common name).
In this type of budgeting an entity wishes to compare a variety of different options available in order to analyse what the "best" course forward is. These get very complicated very quickly and would typically require multiple separate 'budgets' for each potential option, with the ability to nicely compare them at the end.
Mobile Integration For Budgeting
Many users also require integration with the mobile application and desktop version. The basic desire is to be able to check their phone/tablet whilst out/about and be able to review their budget and expenditure against an account to help inform purchasing decisions (e.g. "should I get pizza tonight? I budgeted $100 this month and I've already spent $130! Damn, I better buy a cheap frozen meal..."). At the time of writing (Dec 15), the mobile application does not open '.gnucash' files meaning that full integration is not available. This is separate from budgets - users should file enhancement requests with the Gnucash mobile app for this (or better yet, help them out with their development efforts!!!).
User Gui Requests/Wants
In this section we break down some of the specific design/layout requests that some persons wish for.
Hiding accounts not of Interest
Budgets can often get quite large. Most users are interested in being able to hide accounts that are not of interest to them. It is unclear (to the present author, Matt G, 31 Dec 15) whether they are aware of Gnucash's ability to set accounts as hidden and show/hide them at will. This may be inconvenient to switch on/off with a large number of accounts present in the book but is an option that is available at the moment.
Ability to look at Budget Evolution over time
It can be very handy to be able to understand how your budget has changed over time. This allows the user to better analyse the surprises that occurred and improve their budgets for future. A LOT MORE ANALYSIS IS NEEDED HERE! How would this information be viewed for more than one budget? Should the user select 'baselines' of budgets? Or is a new baseline formed everytime the user changes and clicks "Save"? More thought on who would use this and how is needed.
Automation of Common Actions
The following ideas are present for actions the budget should be able to do when requested: - Spread Amount over all future periods. Example: Want to budget $1000 over the course of a whole a whole year when budgeting monthly. Want to be able to enter 1000 in the first spot to begin the budgeting, right click and select "Spread over whole period". The budget then calculates the amount to put in each period from this spot to the end of the budget to spread the $1000 over the rest of the period broken into even chunks. - Be able to set the future budget based on past expenditure. Sometimes this expenditure will be the average of the last X months, and sometimes it would be the average of a specific defined time period by the user. - ANY MORE AUTOMATION IDEAS? PLEASE EDIT THE WIKI OR EMAIL gnucash-user@gnucash.org.
==
Gnucash Budget Implementation
This section looks more at how Gnucash budgets are to be implemented, noting the user requirements identified above.
General Gui vs Reports
Fundamentally, Gnucash should be useful. Having said this, a degree of design simplicity is required. For this reason, it should be fairly clear what should be expected out of the gnucash budget gui, and what is created by running reports.
Basically, anything needed to create/update/edit the budget needs to be within the gui. Any information gathered for processing of information or analysis should be done within reports.