How can I model budget-data for a budget application? - database

Question

I want to create an application which allows Users to budget money they already have into various categories for a given month.
I've already modeled and prototyped handling the data which is tangible; e.g. Bank Accounts, Transactions, Transfers. The problem I am running into is with relating this "real" data (the stuff sitting in your bank, or in your pocket, or on your bank statement) with these fake notions of Budgets (or, as I like to consider them, envelopes).
Here's a quick list of requirements that I've thrown together:
User can manage their Financial Accounts
User can manage their Financial Transactions
User can associate each Transaction with a Financial Account
User can transfer money between Accounts
User can assign available money to a given Budget Category, per-month
User can modify existing Monthly Budget Categories (reduce or increase)
User can view the amount of money remaining for a given Monthly Budget Category
User can view amount of money available to Budget (may be negative)
Money remaining from a Budget Category can carry over to the next month
User can view their Financial Account totals (should not be affected by budget)
User can create Budget Categories as goals that could eventually be closed (e.g. Savings for a new car)
(Probably some other Use-Cases I am forgetting)
The use-cases in bold are the ones I am struggling with.
I toyed with the idea of having a "MonthlyBudget" object, which each transaction could be related to; but this seemed overly-complicated to implement in a database because I'd have to implement a date-range instead of a simple date.
I played with the idea of treating these Monthly Budget Categories as Accounts, and one would simply perform Transfers to them; but then there'd be no way for the User to cross-check their bank statement with the data in the system.
I played with the idea of "fake money" in which Budgets would somehow make use of, thereby separating "real money" and "budget money" -- but couldn't think this through logically.
I'm a bit at a loss on finding a clear and concise way of implementing this, specifically using a relational-database for storage. If anyone has any suggestions or idea, I'd be very appreciative.

Answer 1

The reason why people experience frustration with the budget envelope method is that it ties budget allocations to specific money actually present, whereas money is fungible and can count against the budget, whatever the source. Moreover, when you write a check or swipe your credit card, it may be for a purchase that includes multiple budget items.
A typical commercial budget data model sets up budgets in periods (monthly in your definition) and budget items with amounts. When funds are disbursed, the payment is applied to the appropriate budget item(s), partially or in full. To find out what you have left to spend in your budget, subtract all the applied payments.
If this is for personal finance, people are on a cash basis. However, the same principles apply. So you would have a grocery bill of $220. Maybe $150 of that was for regular food we eat all week, and the other $70 was for a Christmas party. When you come home and enter the grocery bill into the computer, you would want options:
Apply the whole $220 to grocery, because it has to be made up somewhere;
Apply the $150 to grocery and apply the $70 to seasonal entertainment;
Apply the $150 to grocery and put the $70 aside, because I haven't set up a seasonal entertainment budget yet. We don't want to make the user stop the whole process to create more budgets in order to enter the grocery bill, or soon s/he won't be entering the grocery bill faithfully any more because it is just too much work.