What I've always wanted was a way to relate each transaction to the
budget category and period it belongs to. So if I put off paying a bill
for a few months (maybe there's a dispute as to the correct amount
or something), when I finally do pay it it sould count against the
budget period it logically belonged to, not the one in which the
payment finally occurred. And it would be wrong to say I had
managed to go $1000 under budget simply because I postponed
paging a large bill.
There would seem to be a planned envelope of spending for each budget period,
estimates of committed spemding (which ought to fit within the
spending envelope), and actual spending when the cheque is in the
mail.
I'd like some mechanism that keeps track of all this gracefully.
But a savings-goal subaccount is a lovely stopgaps to make one feel
worried at the right moments about the big picture.
-- hendrik.
P.S. Maybe some thing this perverse, but I enjoy the practice we seem
to have of quoting the entire discussion in each message. It provides
a really convenient, printable summary. And I can delete old messages
that have been followed up on so as not to fill up the 20gig hard disk I've
just ordered :-).
Well, it's not quite perfect; sometimes there are several replies ot one
message. :-(
> Of course, what I suggested in the last message could probably be simply
> accounted for by having the budgeting module automatically put a Budgeting
> Balance transaction, similar to an Opening Balance transaction into every
> Expense and Income account. The Budgeting Balance would be adjusted every
> day to account for the increased money allowed for spending. This
> transaction could be turned on or off by a user interface switch.
>
> -Patrick
>
> On Thu, 30 Mar 2000, Bryan Larsen wrote:
>
> > On Thu, 30 Mar 2000, Patrick Baker wrote:
> > > > Expenditures are *discrete* events. I do not see the difference betweeen your
> > > > "velocity of money" approach and Quicken/MSMoney's approaches. The only
> > > > difference is that your base time period is much smaller (1 day rather than 1
> > > > month). Over the long term, your approach works, but in the short term it
> > > > falls down.
> > > The reason I was thinking more about this approach than a report scenario
> > > is because I don't tend to do a budget reconciliation at a particular time
> > > of year. I would like more of a continuous approach, and thus took the
> > > logical extreme in considering a velocity rather than looking at discrete
> > > transactions. I admit that it's a unfamiliar way of looking at things,
> > > and if it is not obvious to most then it should not be implemented.
> >
> > Mine's not all that familiar either.
> >
> > >
> > > I also was thinking about my approach because it's nice to have the
> > > expense accounts show how much you're allowed to spend at a particular
> > > moment in time, rather than the amount already spent from an aribitrary
> > > date when you started keeping track.
> >
> > That's exactly what I want. From my example:
> >
> > if the budget report says that a line item has a lower limit of $18 and
> > an upper limit of $36, and an actual of $14, that means I can blow $4 on
> > anything, and $18 on the line item.
> >
> > >
> > > Integrating budgeting with accounts then allows you to do things like
> > > transfer money between budget accounts if you want to cut back on
> > > something in order to do something else.
> > >
> > > -Patrick Baker
> >
> > In the budget realm, that's simply called adjusting your budget. I've never
> > used the Quicken virtual savings accounts, though.
> >
> > Bryan
> >
> > >
> > > >
> > > > With my prototype budget report, you can ask it for a budget report for any
> > > > arbitrary period, and it will give you a real answer on whether you are
> > > > spending too much or too little.
> > > >
> > > > For example, it knows that you are paid on the 1st of the month, or on a Friday
> > > > every 2 weeks. If you have a 17 day budget report that encompasses two pay
> > > > periods, there should be 2*pay in your budget, not 17*pay/14.
> > > >
> > > > Other expenses occur fairly regularly, but not on a known date. I fill up my
> > > > car for $18 approximately every 6 weeks (gotta love diesels). If I ask for
> > > > a report for the last 9 weeks, there should be either 1 or 2 fill ups, not 1.5
> > > > fill ups, so < $18 is under budget and > $36 is over budget.
> > > >
> > > > It's still possible to trick the system. For example, a 5.9 week report would
> > > > consider $36 over budget. No big deal -- you know your tank is full, so you
> > > > aren't worried. Conversely, a 6.1 week report where you didn't spend anything
> > > > on fuel, but your tank is empty.
> > > >
> > > > Extraordinary/contingency expenses are handled very similarly, but are handled
> > > > slightly differently. If you set up the above diesel expense as a
> > > > contingency instead, a 9 week budget report would have a lower limit of $9 and
> > > > an upper limit of $45. ($18/6 * 9 +/- $18) The idea is that you can be hit
> > > > with the full amount of the contingency expense at any time, so you should
> > > > always have $18 "saved".
> > > >
> > > > Obviously you don't balance your budget for weird periods. You should balance
> > > > your budget over the least common multiple of all of the periods. If that
> > > > means you need a ten year budget, so be it. You're obviously not going to
> > > > follow the same budget for ten years, but the fact that the budget balances for
> > > > the full ten year period means that it balances for the current year as well.
> > > >
> > > > This all works pretty sweet. One thing I'm looking forward to seeing is a
> > > > DAILY graph of the budget balance that doesn't swing wildly as large expected
> > > > expenses hit.
> > > >
> > > > Does this make sense to everyone?
> > > >
> > > > Bryan
> > > >
> > > > On Thu, 30 Mar 2000, Patrick Baker wrote:
> > > > > I've been thinking about budgeting issues for a while, since I have never
> > > > > found a financial application with the budgeting implemented in a clean
> > > > > way. To me, a budget amounts to specifying the "velocity of money". By
> > > > > that, I mean that you are specifying the flow per unit time which is going
> > > > > into various expense accounts. For instance, as you work at your job, you
> > > > > are paid so much per hour (or for the salaried among us, per year). This
> > > > > is then *your money*, except that your company hasn't gotten around to
> > > > > paying you yet. So in my mind the budget account Salary has a money
> > > > > "velocity" associated with it. You tell the program that you're going to
> > > > > receive 36,000 / year and at the end of January, and the program
> > > > > automatically deposits ~$100 / day into that account. That way it makes
> > > > > sense when the program transfers money from the Salary account into the
> > > > > budget account. The money didn't come from nowhere, but came as a result
> > > > > of the "integration" (for you math geeks) of the velocity of the money
> > > > > over the correct period of time.
> > > > >
> > > > > It works the same way with expenses. As you use electricity, you owe the
> > > > > electric company money at the rate you use the electricity. So your
> > > > > Utilities:Electricity account gets debited at a certain rate. When you
> > > > > get a bill, you (hopefully) bring that balance back to zero by depositing
> > > > > money into it.
> > > > >
> > > > > Bringing it back to the discussion about the honeymoon account, you know
> > > > > that you want $5000 on December 15. So you plug in that planned expense
> > > > > into your account, and specify how you would like to save for it (evenly
> > > > > from now until then, or maybe ramping up in the last couple of months
> > > > > because there are other expenses which will end by then). The program
> > > > > computes the budgeting function, and at each day, your balance becomes
> > > > > more and more negative, until you put money into it (or maybe the program
> > > > > could do this automatically). The object is to keep your expense/income
> > > > > accounts at $0.
> > > > >
> > > > > This then brings us back to the question about reconciling the accounts.
> > > > > If you were to transfer money inside GnuCash, then it would become
> > > > > difficult to reconcile your accounts, as has been pointed out in previous
> > > > > emails. The subaccount solution is in some sense suboptimal because you
> > > > > might have multiple accounts (investment and savings) and use multiple of
> > > > > them to save for the honeymoon. Because this is the case, what is
> > > > > necessitated is an idea of budgeting transactions versus actual
> > > > > transactions. When you get a paycheck, all of it gets deposited into your
> > > > > checking account, but then you can make a "budgeting transfer" to the
> > > > > honeymoon account, postdated to the date of your honeymoon. If you later
> > > > > break off your engagement and decide to spend your money on a car, you can
> > > > > make a budgeting transfer from the honeymoon account to the car account.
> > > > > This feature makes budgeting priority changes easier to deal with. If you
> > > > > had an unexpected car breakdown, you could decide to put off that
> > > > > vacation by transferring money out of that account and into the car repair
> > > > > account.
> > > > >
> > > > > You could view your accounts "with budgeting transactions"
> > > > > or "without budgeting transactions". Of course this would necessitate
> > > > > painful changes to the engine, but could result in a very clean budgeting
> > > > > framework for future financial planning functions.
> > > > >
> > > > > Of course budgeting could be done in a report framework, but as was
> > > > > pointed out, the psychological matter of seeing negative balances helps
> > > > > many to do better planning.
> > > > >
> > > > > -Patrick Baker
> > > > >
> > > > > On Thu, 30 Mar 2000, Scott Haug wrote:
> > > > >
> > > > > > On Thu, Mar 30, 2000 at 12:28:15PM -0600, Rob Browning wrote:
> > > > > > > Scott Haug <[EMAIL PROTECTED]> writes:
> > > > > > >
> > > > > > > > I'm not sure why you would treat it as a liability, but to be honest
> > > > > > > > I have no accounting background so maybe that is the best way. I
> > > > > > > > just treat my savings goals as bank accounts. They're merely
> > > > > > > > logical accounts used to meet a certain monetary goal, and since the
> > > > > > > > money in a savings goal doesn't actually leave the physical account
> > > > > > > > it was transferred from, I still consider it an asset and "Cash On
> > > > > > > > Hand."
> > > > > > >
> > > > > > > But if you really are transferring the money in gnucash from a bank
> > > > > > > account to a savings account, how can you reconcile with your bank
> > > > > > > statement each month? Those transfers will never show up in the bank
> > > > > > > statement, and so the balance will always be wrong, or am I missing
> > > > > > > something?
> > > > > >
> > > > > > Having a "wrong" balance is kind of the point. Its not a real account,
>its a
> > > > > > virtual or logical account set up so you can "set aside" money for a large
> > > > > > purchase or debt, such as a vacation or school tuition. The balance
>reflected
> > > > > > in a goal account should indicate to yourself, "that money shouldn't be
>used
> > > > > > for anything else", and having the goal account's balance factored into the
> > > > > > bank account's balance helps to achieve that. I don't know about anyone
>else,
> > > > > > but I have a pavlovian reaction when I see a negative balance in my
>personal
> > > > > > financial app, even if I know I have a positive balance in my actual
>physical
> > > > > > account.
> > > > > >
> > > > > > My original solution was to set up a separate goal account that stood apart
> > > > > > from the bank accounts, and make transfers from the bank account to the
>goal
> > > > > > account. If I remember correctly, this is more-or-less how quicken sets
>them
> > > > > > up. The problem is, as both you and Lauren pointed out, is that these
> > > > > > transfers aren't reflected in your monthly statement, making reconciliation
> > > > > > somewhat difficult and confusing. Using quicken, I usually factored that
>in
> > > > > > and would reconcile those transactions anyway, but I only had one goal
>account
> > > > > > at a time, so it wasn't too difficult. Multiple goal accounts, however,
>might
> > > > > > make this more than unreasonable.
> > > > > >
> > > > > > Lauren's solution is much more elegant, and it better takes advantage of
>the
> > > > > > superior structure already in place in gnucash. She suggests setting up a
>goal
> > > > > > account as a sub-account off a regular bank account, and debiting from the
>goal
> > > > > > account to a liability account (which makes sense to me, thanks Lauren!) to
> > > > > > represent setting aside money for the goal. The beautiful part is you
>don't
> > > > > > have to worry about these transactions showing up in your checking account,
> > > > > > since you're never actually touching the bank account. Therefore, monthly
> > > > > > reconciliations would work just like normal, without having to factor in
>any
> > > > > > goal account transactions. It gets better: the goal account's (typically)
> > > > > > negative balance would be factored into the bank account's balance on the
>main
> > > > > > window (since it's a sub-account), giving you the desired effect of a
> > > > > > (perceived) smaller balance without any fuss. The only minor downside of
>this
> > > > > > method is that for it to be most effective, these goal accounts must be
>tied to
> > > > > > a single bank account, whereas a separate, standalone goal account could
> > > > > > receive transfers from any bank account. But I believe its worth it for
>not
> > > > > > having to mess with it come reconcilation time.
> > > > > >
> > > > > > > If I'm right, then to do "savings goals", we'd probably need another
> > > > > > > abstraction. Maybe you'd have a "real balance", used for
> > > > > > > reconciliation, that ignores savings goal transfers, and then the
> > > > > > > "normal balance" that gnucash shows you by default that includes the
> > > > > > > savings goal transfers. This would probably require a new account
> > > > > > > type and some ugly, and possibly incorrect, monkeying around in the
> > > > > > > engine. Not sure off the top of my head...
> > > > > >
> > > > > > I don't think this is necessary. As mentioned, making a goal account a sub
> > > > > > account of a bank account (so many accounts!) is almost a perfect
>solution, and
> > > > > > doesn't require any code changes to gnucash, since its framework has been
>so
> > > > > > well designed! A new account type wouldn't hurt to help delineate a goal
> > > > > > account from a bank account, but it would have the exact same semantics as
>a
> > > > > > bank account and would be a different account type in name only.
> > > > > >
> > > > > > Anyway, I don't think these goal accounts would be used enough by most
>people
> > > > > > to deserve drastic, confusing changes to the stable structure already
>present.
> > > > > > What we have is sufficient. What /would/ be useful would be a druid that
>could
> > > > > > step people through setting one up, creating the requisite sub-bank
> > > > > > account/liability account combo. But it would basically just automate
> > > > > > something that isn't all that difficult to do manually.
> > > > > >
> > > > > > > --
> > > > > > > Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
> > > > > >
> > > > > > -Scott
> > > > > >
> > > > > > --
> > > > > >
> > > > > > --
> > > > > > Gnucash Developer's List
> > > > > > To unsubscribe send empty email to: [EMAIL PROTECTED]
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Gnucash Developer's List
> > > > > To unsubscribe send empty email to: [EMAIL PROTECTED]
> > > > --
> > > > -------------
> > > > Bryan Larsen, Senior Software Engineer & fall guy
> > > > Analog Design Automation: Analog Circuit Synthesis? Problem Solved.
> > > >
> > > > --
> > > > Gnucash Developer's List
> > > > To unsubscribe send empty email to: [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > --
> > -------------
> > Bryan Larsen, Senior Software Engineer & fall guy
> > Analog Design Automation: Analog Circuit Synthesis? Problem Solved.
> >
> > --
> > Gnucash Developer's List
> > To unsubscribe send empty email to: [EMAIL PROTECTED]
> >
> >
> >
>
>
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
>
>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
