AU2013200795A1 - Method and system for managing spending through accounting - Google Patents

Abstract

A method and apparatus are disclosed that provide for the management of spending through accounting. The method provides for the user to establish financial accounts that track cash assets, financial accounts that track total spending limits and financial accounts that track budgetary category spending limits. The user updates as required the spending limits by transferring value between financial accounts that track spending limits. The user at any time can view a statement of the current balance of the financial accounts that track cash assets and the current balance of the financial accounts that track spending limits. When the total spending limit is equal to the total cash assets available the budgetary category spending limits effectively organise the available cash and so the balance of accounts that track budgetary category spending limits may be used to make informed spending decisions.

Description

COMPLETE PATENT SPECIFICATION AUSTRALIA CASHSOFT METHOD AND SYSTEM FOR MANAGING SPENDING THROUGH ACCOUNTING DATE: 14th FEBRUARY 2013 INVENTORS: Agatino CARROLO METHOD AND SYSTEM FOR MANAGING SPENDING THROUGH ACCOUNTING RELATED INFORMATION [0001] The present patent application is based on the Australian Provisional Application No. AU2012900574 Filed 17th February 2012, hereby incorporated by reference. TECHNICAL FIELD [0002] The present invention relates generally to computer based money management systems for users and more particularly, to the management of spending through accounting, in a computer based system. BACKGROUND ART [0003] The field of financial accounting is well known to those skilled in the art. Accountants have been used by businesses and individuals to manage finances over the years. The development of the personal computer has enabled accounting to be simplified for accountants, businesses and personal users. The double entry bookkeeping system is a fundamental accounting system and is well known to those skilled in the art. Accounting rules group all finance related things into five fundamental types of accounts, Equity, Asset, Liability, Income and Expense. [0004] By definition accounting does not involve budgeting. However all current accounting programs provide a budgeting system. The budgeting systems provided by current accounting programs are over simplified, limited and not fully integrated with the programs accounting system. Generally speaking an account tracks a single financial quantity and "how much money I may spend" more commonly known as a budget/spending limit is a single financial quantity. Therefore it may be possible to track a budget/spending limit using accounts. If this was possible accounting and budgeting would combine to become accounting and all the benefits of accounting would flow over to budgeting. However no accounts exist in the definition of accounting that may enable this. This is the fundamental problem that lead to the division of accounting into accounting and budgeting. [0005] Accordingly, what is required is an accounting system that enables a user to perform accounting tasks and budgeting tasks through the use of accounts, transactions and statements. Thus accounting and budgeting are combined to become accounting which results in a standard, capable and integrated accounting system. SUMMARY OF INVENTION [0006] According to the present invention, a method and apparatus are disclosed that provide for the management of spending through accounting. The method provides for the user to establish financial accounts that track cash assets, financial accounts that track total spending limits and financial accounts that track budgetary category spending limits. The user updates as required spending limits by transferring value between financial accounts that track spending limits. The user at any time can view a statement of the current balance of the financial accounts that track cash assets and the current balance of the financial accounts that track spending limits. When the total spending limit is equal to the total cash available the budgetary category spending limits effectively organise the cash available and so the balance of accounts that track budgetary category spending limits may be used to make informed spending decisions. All financial events both those of the past and future are considered to be transactions between established accounts. Some common financial events are, when a user receives cash, when a user budgets cash and when a user spends cash. In this system all financial events are managed using accounts, transactions and statements. The method is operable in a computer environment such as a tablet computer, personal computer, a laptop computer, mobile phones, smart phones, personal digital assistants, or other computer systems that have a central processing unit, input and output means, memory means and optional data communication means for connection to the internet, a financial institution system, or the like. [0007] The present invention describes a method and system, which are implemented on a computer system that enables users to make informed spending decisions by maintaining spending limits which the user consults prior to spending. BRIEF DESCRIPTION OF DRAWINGS [0008] The foregoing and other objects and features of the present invention will become more fully apparent from the following description and accompanying drawings. Understanding that these drawings depict only typical embodiments of the invention and are, therefore not to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which: [0009] Figure 1 illustrates a computer system in accordance with the present invention; [0010] Figure 2 illustrates a block diagram of a user interface screen hierarchy in accordance with the present invention; [0011] Figure 3 illustrates a block diagram of the two financial account groups in accordance with the present invention; [0012] Figure 4 illustrates a user interface screen that is used to view, create, read, edit, copy, delete and purge accounts in the accounts data repository in accordance with the present invention; [0013] Figure 5 illustrates a user interface screen that is used to establish a new account, edit a established account and read a established account in the accounts data repository in accordance with the present invention; [0014] Figure 6 illustrates a user interface screen that is being used to establish a new account in the accounts data repository in accordance with the present invention; [0015] Figure 7 illustrates a user interface screen that is used to view a statement of the accounts established in the accounts data repository in accordance with the present invention; [0016] Figures 8-9 illustrates a user interface screen that is used to view, create, read, edit, copy, move up (within the same date), move down (within the same date), export (used to quickly record a transaction that is in the past transactions data repository into the future transactions data repository), reconcile, delete and purge transactions in the past transactions data repository in accordance with the present invention; [0017] Figure 10 illustrates a user interface screen that is used to record a new transaction, edit a recorded transaction and read a recorded transaction in the past transactions data repository in accordance with the present invention; [0018] Figures 11-21 illustrates a user interface screen that is being used to record new transactions in the past transactions data repository in accordance with the present invention; [0019] Figure 22 illustrates a user interface screen that is used to view a statement of the current balance, previous balance and change in balance of accounts established by the user in accordance with the present invention. This user interface screen consists of three sections namely, period, analysis and statement, which are explained in figures 23, 24, 25 in accordance with the present invention; [0020] Figure 23 illustrates the period section of the user interface screen illustrated in figure 22 in accordance with the present invention; [0021] Figure 24 illustrates the analysis section of the user interface screen illustrated in figure 22 in accordance with the present invention; [0022] Figure 25 illustrates the statement section of the user interface screen illustrated in figure 22 in accordance with the present invention; [0023] Figures 26-27 illustrates a user interface screen that is used to view, create, read, edit, copy, move up (within the same date), move down (within the same date), export (used to quickly record a transaction that is in the future transactions data repository into the past transactions data repository), delete and purge transactions in the future transactions data repository in accordance with the present invention; [0024] Figure 28 illustrates a user interface screen that is used to record a new transaction, edit a recorded transaction and read a recorded transaction in the future transactions data repository in accordance with the present invention; [0025] Figures 29-31 illustrates a user interface screen that is being used to record new transactions in the future transactions data repository in accordance with the present invention; [0026] Figure 32 illustrates a user interface screen that shows the users current average monthly income which is calculated from data in the future transactions data repository and enables the user to generate a statement that shows the expected withdraws and deposits for established accounts in a user specified period of time. DESCRIPTION OF EMBODIMENTS [0027] It will be readily understood that the components of the present invention, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the embodiments of the system and method of the present invention, and represented in figures 1 through 32 is not intended to limit the scope of the invention but is merely representative of the present embodiments of the invention. [0028] The present embodiments of the invention will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout. [0029] The present invention describes a method and system that is implemented on a computer system to enable users to manage spending through accounting. After the user installs the system the user records a transaction into the past transactions data repository that establishes the spending limits by transferring value from an established budgeted account to established budget accounts. Each time the user receives cash the user records a transaction into the past transactions data repository that records the transfer of money. In the same transaction the user changes the spending limits by transferring value (equal to the amount of cash that was received) from an established budgeted account to an established income buffer budget account. The user on a regular basis (preferably monthly) records a transaction into the past transactions data repository that changes the spending limits by transferring value from the income buffer budget account to other budget accounts. The user at any time may record a transaction into the past transactions data repository that changes spending limits by transferring value from one budget account to another budget account. Each time the user spends cash the user records a transaction into the past transactions data repository that records the transfer of money. In the same transaction the user records the change in spending limits by transferring value (equal to the amount of cash that was spent) from an established budget account to an established budgeted account. Each time the user spends credit the user records a transaction into the past transactions data repository that records the transfer of money. In the same transaction the user records the change in spending limits by transferring value (equal to the amount of credit that was spent) from an established budget account to another established budget account to prepare for the credit repayment. At any time the user may view a statement which shows the current balance of the budget accounts thus the user prior to spending can check their spending limits to ensure they do not overspend. In the following drawings the currency AUD is used as the currency of all accounts however any other currency could have been used instead by changing a system setting. [0030] The method and system are intended to operate in a personal computer environment, which environment not only includes desktop computer systems, but also laptops, palm sized personal computers, personal digital assistants, mobile phones, smart phones or by access through an internet service provider. [0031] The system is designed to operate in a graphical user interface mode where the user can manipulate data and information via such pointing devices as a mouse with keyboard entry also being provided among others. As such, the system is typically designed to be operated within a Windows type, MAC, JAVA, HTML, Android, IOS, EPOC etc., operating system that can be readily implemented by those skilled in the art. Browsing devices use JAVA, Flash, JAVA Script and HTML; others use resident operating systems. [0032] Figure 1 illustrates a computer system (3) which includes a processor (5), memory (4), storage device (6) and various other elements. The computer (3) may also include input means such as a keyboard (7), mouse (8) and output means such as a monitor (1). The computer system (3) may be connected to a local area network (LAN) or a wide area network (WAN) via a network interface connection (2). The input and output means may take other forms and this is understood by those skilled in the art. Further one or more elements of the computer system (3) may be located at a remote location and connected to the other elements over a network. Further the software instructions to perform the embodiments of the invention may be stored on a computer readable medium such as a compact disc. [0033] Figure 2 illustrates a block diagram of the user interface screen hierarchy. The main user interface screen (9) is the central user interface screen from which all user interface screens are accessible. The location of the user within this hierarchy is displayed at the top of each user interface screen. A back button is provided in every user interface screen to enable the user to go to the previous user interface screen in the user interface screen hierarchy. [0034] Figure 3 illustrates the financial account types defined in this system, divided into two groups, real (10) and budget (18). The real accounts (10) track money whilst the budget accounts (18) track spending limits. A transfer of value may only occur between accounts that belong to the same group (10), (18). All transfers of value between accounts must respect that the sum of the account withdraws must be equal to the sum of the account deposits. When dealing with transactions the user interface screen provides the user with the transfer totals for both real and budget accounts to assist the user in meeting this transaction requirement. The financial account types in the group Real (10) are the five basic financial account types Equity (11), Asset (12), Liability (13), Income (14) and Expense (15) and the two new financial account types Asset:Bank (16) and Asset:Cash (17). The five basic financial account types (11), (12), (13), (14), (15) are well understood by persons skilled in the art of accounting. The two new financial account types Asset:Bank (16) and Asset:Cash (17) enable the user to create asset accounts that specifically track a cash asset such as money in a bank account, money in a wallet and money in a petty cash box. With the addition of these two new financial account types (16), (17) it is possible to differentiate between general Assets (12) and Cash Assets (16), (17). The financial account types in the group Budget (18) are the two new financial account types Budgeted (19) and Budget (20). The two new financial account types Budgeted (19) and Budget (20) enable the user to track spending limits. A Budgeted account (19) tracks the total spending limit. Generally speaking the user establishes one Budgeted account (19). The balance of a Budgeted account (19) increases when value is withdrawn from it. The balance of a Budgeted account (19) decreases when value is deposited into it. A Budget account (20) tracks a spending limit. Generally speaking the user establishes one Budget account (20) for every Expense account (15). The balance of a Budget account (20) increases when value is deposited into it. The balance of a Budget account (20) decreases when value is withdrawn from it. Therefore Asset:Bank (16) and Asset:Cash (17) accounts track cash assets whilst Budgeted (19) and Budget (20) accounts track spending limits. [0035] Figure 4 illustrates the user interface screen that enables the user to view, create, read, edit, copy, delete and purge accounts in the accounts data repository. The accounts that a given user has established are shown in the table (21) where each row (22) shows the name and active attributes of an established account. It is not intended that these accounts be limiting with respect to the implementation of the invention, but are merely illustrative of what types of accounts are possible. The user may focus on subset of the accounts in table (21) via the use of the table filter buttons (23). The accounts in table (21) are organised in such a way so the user may efficiently locate an account. [0036] Figure 5 illustrates a user interface screen that enables the user to establish a new account, edit an established account and read an established account (24) in the accounts data repository. This user interface screen when not in use is in the mode disabled (25). When in use the user interface screen may be in the new, edit or read mode (25). The account name (26) which also specifies the account type, account note (27) and account active (28) attributes are specified by the user when the account is established. The user at any stage may edit or read the attributes of an account established in the accounts data repository. [0037] Figure 6 illustrates a user interface screen that is being used to establish a new account in the accounts data repository. In this example the user is creating a new budget account to track the money that may be spent on groceries. [0038] Figure 7 illustrates a user interface screen that shows a statement of the accounts established by a given user in the accounts data repository. The statement shows the number of the different types of accounts the user has established as well as the total number of accounts established. [0039] Figure 8 illustrates the user interface screen that enables the user to view, create, read, edit, copy, move up (within the same date), move down (within the same date), export (used to quickly record a transaction that is in the past transactions data repository into the future transactions data repository), reconcile, delete and purge transactions in the past transactions data repository. The account filter section (29) enables the user to specify whether the transactions recorded in the past transactions data repository are shown in general mode or account mode. In this example no account is specified in the account filter section (30). Thus the transactions recorded in the past transactions data repository are shown in general mode in the table (31) where each row (32) shows the date and name attributes of a transaction. The user may focus on a subset of the transactions in table (33) via the use of the table filter buttons. [0040] Figure 9 illustrates the user interface screen that enables the user to view, create, read, edit, copy, move up (within the same date), move down (within the same date), export (used to quickly record a transaction that is in the past transactions data repository into the future transactions data repository), reconcile, delete and purge transactions in the past transactions data repository. The account filter section (34) determines whether the transactions recorded in the past transactions data repository are shown in general mode or account mode. In this example the account budget groceries is specified in the account filter section (35). Thus the transactions recorded in the past transactions data repository are shown from the point of view of the budget groceries account in the table (36) where each row (37) shows the date, name, notes, action, amount and reconcile attributes of a transaction. The user may focus on a subset of the transactions in table (38) via the use of the table filter buttons. [0041] Figure 10 illustrates a user interface screen that enables the user to record a new transaction, edit a recorded transaction and read a recorded transaction in the past transactions data repository. This user interface screen when not in use is in the mode disabled (42). When in use the user interface screen may be in the new, edit or read mode (42). All transfers of value between accounts must respect that the sum of the account withdraws must be equal to the sum of the account deposits. Also as previously stated transfers of value may only occur between accounts in the same group that is real (10) and budget (18). The transfer totals for real accounts (40) and budget accounts (41) provides the user with an overview of the transaction. The transfer totals are calculated from data in the transaction account table (45). The transaction date (43), transaction name (44) and transaction accounts involved (45) are specified by the user when the transaction is recorded. The user specifies for every account involved in the transaction the following information, the account name, any notes, whether money was withdrawn or deposited, the amount of money that was withdrawn or deposited and whether the withdraw or deposit of money has been reconciled. The user at any stage may edit or read the attributes of a transaction in the past transactions data repository. [0042] Figure 11 illustrates a user interface screen that is being used to record a new transaction in the past transactions data repository. After the user installs the system the user records a transaction into the past transactions data repository that establishes the opening balance of the users asset accounts. In this example the user is recording a new "Setup Asset" transaction into the past transactions data repository on the 22/01/2012. In this example the user will withdraw 50,000.00 AUD from the "Equity" account, deposit 12,000.00 AUD into the "Asset:Bank:Checking" account, deposit 38,000.00 AUD into the "Asset:Bank:Saving" account and deposit 0.00 AUD into the "Asset:Cash:Box" account. After the user records this transaction into the past transactions data repository the balance of the "Equity" account shall increase by 50,000.00 AUD, the balance of the "Asset:Bank:Checking" account shall increase by 12,000.00 AUD, the balance of the "Asset:Bank:Saving" account shall increase by 38,000.00 AUD and the balance of the "Asset:Cash:Box" account shall increase by 0.00 AUD. Therefore after the user records this transaction into the past transactions data repository the opening balance of the assets specified in the transaction shall be established. [0043] Figure 12 illustrates a user interface screen that is being used to record a new transaction in the past transactions data repository. After the user installs the system the user records a transaction into the past transactions data repository that establishes the opening balance of the users liability accounts. In this example the user is recording a new "Setup Liabilities" transaction into the past transactions data repository on the 22/01/2012. In this example the user will withdraw 250.00 AUD from the "Liability:Credit Card" account and deposit 250.00 AUD into the "Equity" account. After the user records this transaction into the past transactions data repository the balance of the "Liability:Credit Card" account shall increase by 250.00 AUD and the balance of the "Equity" account shall decrease by 250.00 AUD. Therefore after the user records this transaction into the past transactions data repository the opening balance of the liabilities specified in the transaction shall be established. [0044] Figure 13 illustrates a user interface screen that is being used to record a new transaction in the past transactions data repository. After the user installs the system the user records a transaction into the past transactions data repository that initialises the spending limits. In this example the user is recording a new "Setup Budgets" transaction into the past transactions data repository on the 22/01/2012. In this example the user will withdraw 50,000.00 AUD from the "Budgeted" account, deposit 9,000.00 AUD into the "Budget:Income Buffer" account, deposit 100.00 AUD into the "Budget:Clothing" account, deposit 250.00 AUD into the "Budget:Credit Card:Repayment" account, deposit 40,000.00 AUD into the "Budget:Emergency" account, deposit 600.00 AUD into the "Budget:Groceries" account, deposit 50.00 AUD into the "Budget:Recreation" account and deposit 0.00 AUD into the "Budget:Rent" account. After the user records this transaction into the past transactions data repository the balance of the "Budgeted" account shall increase by 50,000.00 AUD, the balance of the "Budget:Income Buffer" account shall increase by 9,000.00 AUD, the balance of the "Budget:Clothing" account shall increase by 100.00 AUD, the balance of the "Budget:Credit Card:Repayment" account shall increase by 250.00 AUD, the balance of the "Budget:Emergency" account shall increase by 40,000.00 AUD, the balance of the "Budget:Groceries" account shall increase by 600.00 AUD, the balance of the "Budget:Recreation" account shall increase by 50.00 AUD and the balance of the "Budget:Rent" account shall increase by 0.00 AUD. Therefore after the user records this transaction into the past transactions data repository the user shall be have more money to spend on income buffer, clothing, credit card repayments, emergencies, groceries, recreation and more money to spend in total. [0045] Figure 14 illustrates a user interface screen that is being used to record a new transaction in the past transactions data repository. The user after spending cash, records a transaction into the past transactions data repository that records the spending of cash and the change in spending limits. In this example the user is recording a new "Groceries (Supermarket)" transaction into the past transactions data repository on the 25/01/2012. In this example the user will withdraw 250.00 AUD from the "Asset:Bank:Checking" account, deposit 250.00 AUD into the "Expense:Groceries" account, withdraw 250.00 AUD from the "Budget:Groceries" account and deposit 250.00 AUD into the "Budgeted" account. After the user records this transaction into the past transactions data repository the balance of the "Asset:Bank:Checking" account shall decrease by 250.00 AUD, the balance of the "Expense:Groceries" account shall increase by 250.00 AUD, the balance of the "Budget:Groceries" account shall decrease by 250.00 AUD and the balance of the "Budgeted" account shall decrease by 250.00 AUD. Therefore after the user records this transaction into the past transactions data repository the user shall have less money in their bank checking account, more money spent on groceries, less money to spend on groceries and less money to spend in total. [0046] Figure 15 illustrates a user interface screen that is being used to record a new transaction in the past transactions data repository. The user after spending cash records a transaction into the past transactions data repository that records the spending of cash and the change in spending limits. In this example the user is recording a new "Buy Shares (Stock Exchange)" transaction into the past transactions data repository on the 25/01/2012. In this example the user will withdraw 10,000.00 AUD from the "Asset:Bank:Checking" account, deposit 9,750.00 AUD into the "Asset:Shares:Company" account, deposit 250.00 AUD into the "Expense:Brokerage Fees" account, withdraw 10,000.00 AUD from the "Budget:Emergency" account and deposit 10,000.00 AUD into the "Budgeted" account. After the user records this transaction into the past transactions data repository the balance of the "Asset:Bank:Checking" account shall decrease by 10,000.00 AUD, the balance of the "Asset:Shares:Company" account shall increase by 9,750.00 AUD the balance of the "Expense:Brokerage Fees" account shall increase by 250.00 AUD, the balance of the "Budget:Emergency" account shall decrease by 10,000.00 AUD and the balance of the "Budgeted" account shall decrease by 10,000.00 AUD. Therefore after the user records this transaction into the past transactions data repository the user shall have less money in their bank checking account, more money spent on brokerage fees, more money invested in shares, less money to spend on emergencies and less money to spend in total. [0047] Figure 16 illustrates a user interface screen that is being used to record a new transaction in the past transactions data repository. The user after spending credit records a transaction into the past transactions data repository that records the spending of credit and if required the change in spending limits to prepare for the repayment. In this example the user is recording a new "Movies (Local Cinema)" transaction into the past transactions data repository on the 25/01/2012. In this example the user will withdraw 50.00 AUD from the "Liability:Credit Card" account, deposit 50.00 AUD into the "Expense:Recreation" account, withdraw 50.00 AUD from the "Budget:Recreation" account and deposit 50.00 AUD into the "Budget:Credit Card:Repayment" account. After the user records this transaction into the past transactions data repository the balance of the "Liability:Credit Card" account shall increase by 50.00 AUD, the balance of the "Expense:Recreation" account shall increase by 50.00 AUD, the balance of the "Budget:Recreation" account shall decrease by 50.00 AUD and the balance of the "Budget:Credit Card:Repayment" account shall increase by 50.00 AUD. Therefore after the user records this transaction into the past transactions data repository the user shall owe more money on their credit card, have spent more money on recreation, have less money to spend on recreation and have more money to spend on credit card repayments. [0048] Figure 17 illustrates a user interface screen that is being used to record a new transaction in the past transactions data repository. The user after receiving cash records a transaction into the past transactions data repository that records the receiving of cash and the change in spending limits. In this example the user is recording a new "Paycheck (Company)" transaction into the past transactions data repository on the 27/01/2012. In this example the user will withdraw 1,250.00 AUD from the "Income:Employment:Company" account, deposit 375.00 AUD into the "Expense:Income Tax" account, deposit 875.00 AUD into the "Asset:Bank:Checking" account, withdraw 875.00 AUD from the "Budgeted" account and deposit 875.00 AUD into the "Budget:Income Buffer" account. After the user records this transaction into the past transactions data repository the balance of the "Income:Employment:Company" account shall increase by 1,250.00 AUD, the balance of the "Expense:Income Tax" account shall increase by 375.00 AUD, the balance of the "Asset:Bank:Checking" account shall increase by 875.00 AUD, the balance of the "Budgeted" account shall increase by 875.00 AUD and the balance of the "Budget:Income Buffer" account shall increase by 875.00 AUD. Therefore after the user records this transaction into the past transactions data repository the user shall have more money earned from employment, more money in their checking account, more money spent on income tax, more money to spend on the income buffer and more money to spend in total. [0049] Figure 18 illustrates a user interface screen that is being used to record a new transaction in the past transactions data repository. The user after spending cash records a transaction into the past transactions data repository that records the spending of cash and the change in spending limits. In this example the user is recording a new "Credit Card Repayment" transaction into the past transactions data repository on the 31/01/2012. In this example the user will withdraw 300.00 AUD from the "Asset:Bank:Checking" account, deposit 300.00 AUD into the "Liability:Credit Card" account, withdraw 300.00 AUD from the "Budget:Credit Card:Repayment" account and deposit 300.00 AUD into the "Budgeted" account. After the user records this transaction into the past transactions data repository the balance of the "Asset:Bank:Checking" account shall decrease by 300.00 AUD, the balance of the "Liability:Credit Card" account shall decrease by 300.00 AUD, the balance of the "Budget:Credit Card:Repayment" account shall decrease by 300.00 AUD and the balance of the "Budgeted" account shall decrease by 300.00 AUD. Therefore after the user records this transaction into the past transactions data repository the user shall have less money in their checking account, less credit card liability, less money to spend on credit card repayments and less money to spend in total.

[0050] Figure 19 illustrates a user interface screen that is being used to record a new transaction in the past transactions data repository. The user preferably at the beginning of each month changes the spending limits to enable further spending. In this example the user is recording a new "Monthly Budget (Feb 2012)" transaction into the past transactions data repository on the 01/02/2012. In this example the user will withdraw 3,500.00 AUD from the "Budget:Income Buffer" account, deposit 200.00 AUD into the "Budget:Clothing" account, deposit 0.00 AUD into the "Budget Credit Card" account, deposit 0.00 AUD into the "Budget:Emergency" account, deposit 1,200.00 AUD into the "Budget:Groceries" account, deposit 100.00 AUD into the "Budget:Recreation" account and deposit 2,000.00 AUD into the "Budget:Rent" account. After the user records this transaction into the past transactions data repository the balance of the "Budget:Income Buffer" account shall decrease by 3,500.00 AUD, the balance of the "Budget:Clothing" account shall increase by 200.00 AUD, the balance of the "Budget:Credit Card:Repayment" account shall increase by 0.00 AUD, the balance of the "Budget:Emergency" account shall increase by 0.00 AUD, the balance of the "Budget:Groceries" account shall increase by 1,200.00 AUD, the balance of the "Budget:Recreation" account shall increase by 100.00 AUD and the balance of the "Budget:Rent" account shall increase by 2,000.00 AUD. Therefore after the user records this transaction into the past transactions data repository the user shall have more money to spend on clothing, groceries, recreation and rent and less money to spend on the income buffer. [0051] Figure 20 illustrates a user interface screen that is being used to record a new transaction in the past transactions data repository. The user after making an appointment to spend money in the future may choose to change spending limits to ensure that they do not spend the money for the future appointment on other things. In this example the user is recording a new "Budget Booking" transaction into the past transactions data repository on the 02/02/2012. In this example the user will withdraw 25.00 AUD from the "Budget:Recreation" account and deposit 25.00 AUD into the "Budget:Recreation (Booked)" account. After the user records this transaction into the past transactions data repository the balance of the "Budget:Recreation" account shall decrease by 25.00 AUD and the balance of the "Budget:Recreation (Booked)" account shall increase by 25.00 AUD. Therefore after the user records this transaction into the past transactions data repository the user shall have less money to spend on general recreation events and more money to spend on booked recreation events. [0052] Figure 21 illustrates a user interface screen that is being used to record a new transaction in the past transactions data repository. The user at any time can change spending limits by recording a transaction into the past transactions data repository that records a change in spending limits. In this example the user is recording a new "Budget Sacrifice" transaction into the past transactions data repository on the 02/02/2012. In this example the user will withdraw 50.00 AUD from the "Budget:Recreation" account and deposit 50.00 AUD into the "Budget:Clothing" account. After the user records this transaction into the past transactions data repository the balance of the "Budget:Recreation" account shall decrease by 50.00 AUD and the balance of the "Budget:Clothing" account shall increase by 50.00 AUD. Therefore after the user records this transaction into the past transactions data repository the user shall have less money to spend on recreation and more money to spend on clothing. [0053] Figure 22 illustrates a user interface screen that is used to view a statement of the current balance or previous balance of asset, liability, budgeted and budget accounts established by the user. This user interface screen may also be used to view a statement of the change in balance between any two dates specified by the user of all accounts established by the user. The statement is calculated from data in the past transactions data repository and data in the period section shown in figure 23. The period section is shown in figure 23, the analysis section is shown in figure 24 and the statement section is shown in figure 25. [0054] Figure 23 illustrates the period section of the user interface screen illustrated in figure 22. The period section shows the current period of the statement and enables the user to specify a custom period. The three periods that the user is generally interested in are, the period between and including the system setup date and today's date, the period between and including the system setup date and any date after the system setup date and the period between and including any two dates. These periods are used to enable the user to view the current balance, previous balance and change in balance of accounts established in the accounts data repository respectively. Although the period is specified by two dates a statement mode signal is provided to inform the user if they can use the statement for spending decisions. When the user does not specify a period the statement period is the period between and including the system setup date and today's date and the statement is placed into present mode. When the user specifies a period the statement is placed into past mode. If the statement is in present mode the user can use the statement for spending decisions whilst if the statement is in past mode the user cannot use the statement for spending decisions. [0055] Figure 24 illustrates the analysis section of the user interface screen illustrated in figure 22. The analysis section consists of two budget integrity tests. The first budget integrity test checks to see if the users cash assets have been fully allocated for spending. The first budget integrity test is a comparison of the total current balance of the users cash assets (i.e. sum of the current balance of all established Asset:Bank (16) and Asset:Cash accounts (17)) and the total spending limit (i.e. sum of the current balance of all established budget (20) accounts). If these two sums are equal then the first budget integrity test returns a pass result otherwise it returns a fail result. The first budget integrity test is required to ensure that the user does not plan to spend more or less cash than they have. The second budget integrity test checks to see if any established budget (20) accounts have a negative current balance. If no established budget account has a negative current balance then the second budget integrity test returns a pass result otherwise it returns a fail result. The second budget integrity test is required to ensure that the user does not use established budget accounts with a positive current balance to make any spending decisions until no established budget account has a negative current balance. When both budget integrity tests return a pass result then the spending limits are said to be valid. [0056] Figure 25 illustrates the statement section of the user interface screen illustrated in figure 22. The statement section depending on the period specified by the user shows the current or previous balance of asset, liability, budgeted and budget accounts or the change in balance of accounts established in the accounts data repository. The user at any time can check the current balance of an established budget account to make an informed spending decision. Also the user at any time may use the statement to reconcile their established accounts or to understand past spending in order to plan future spending. [0057] Figure 26 illustrates the user interface screen that enables the user to create, read, edit, copy, move up (within the same date), move down (within the same date), export (used to quickly record a transaction that is in the future transactions data repository into the past transactions data repository), delete and purge transactions in the future transactions data repository. The account filter section (47) enables the user to specify whether the transactions recorded in the future transactions data repository are shown in general mode or account mode. In this example no account is specified in the account filter section (48). Thus the transactions recorded in the future transactions data repository, are shown in general mode in the table (49) where each row (50) shows the date and name attributes of a transaction. The user may focus on a subset of the transactions in table (49) via the use of the table filter buttons (51). [0058] Figure 27 illustrates the user interface screen that enables the user to create, read, edit, copy, move up (within the same date), move down (within the same date), export (used to quickly record a transaction that is in the future transactions data repository into the past transactions data repository), delete and purge transactions in the future transactions data repository. The account filter section (52) enables the user to specify whether the transactions recorded in the future transactions data repository are shown in general mode or account mode. In this example the budget rent account is specified in the account filter section (53). Thus the transactions recorded in the future transactions data repository are shown from the point of view of the budget rent account in the table (54) where each row (55) shows the date, name, notes, action, amount and reconcile attributes of a transaction. The user may focus on a subset of the transactions in table (54) via the use of the table filter buttons (56). [0059] Figure 28 illustrates a user interface screen that enables the user to record a new transaction, edit a recorded transaction and read a recorded transaction in the future transactions data repository. This user interface screen when not in use is in the mode disabled (60). When in use the user interface screen may be in the new, edit or read mode (60). All transfers of value between accounts must respect that the sum of the account withdraws must be equal to the sum of the account deposits. Also as previously stated transfers of value may only occur between accounts in the same group that is real (10) and budget (18). The transfer totals for real accounts (58) and budget accounts (59) provides the user with an overview of the transaction. The transfer totals are calculated from data in the transaction account table (66). The transaction date (61), transaction name (62), transaction cycle year (63), transaction cycle month (64), transaction cycle day (65) and transaction accounts involved (66) are specified by the user when the transaction is recorded. The user specifies for every account involved in the transaction the following information, the account name, any notes, whether money was withdrawn or deposited, the amount of money that was withdrawn or deposited and whether the withdraw or deposit of money has been reconciled. The user at any stage may edit or read the attributes of a transaction in the future transactions data repository. [0060] Figure 29 illustrates a user interface screen that is being used to record a new transaction in the future transactions data repository. In this example the user is recording a new regular pay check transaction into the future transactions data repository on the 03/02/2012. In this example the user in the future will withdraw 1,250.00 AUD from the "Income:Employment:Company" account, deposit 375.00 AUD into the "Expense:Income Tax" account, deposit 875.00 AUD into the "Asset:Bank:Checking" account, withdraw 875.00 AUD from the "Budgeted" account and deposit 875.00 AUD into the "Budget:Income Buffer" account. [0061] Figure 30 illustrates a user interface screen that is being used to record a new transaction in the future transactions data repository. In this example the user is recording a new regular rent payment transaction into the future transactions data repository on the 15/02/2012. In this example the user in the future will withdraw 2,000.00 AUD from the "Asset:Bank Checking" account, deposit 2,000.00 AUD into the "Expense:Rent" account, withdraw 2,000.00 AUD from the "Budget:Rent" account and deposit 2,000.00 AUD into the "Budgeted" account. [0062] Figure 31 illustrates a user interface screen that is being used to record a new transaction in the future transactions data repository. In this example the user is recording a new monthly budget transaction into the future transactions data repository on the 01/03/2012. In this example the user in the future will withdraw 3,500.00 AUD from the "Budget:Income Buffer" account, deposit 200.00 AUD into the "Budget:Clothing" account, deposit 0.00 AUD into the "Budget:Credit Card:Repayment" account, deposit 0.00 AUD into the "Budget:Emergency" account deposit 1,200.00 AUD into the "Budget:Groceries" account, deposit 100.00 AUD into the "Budget:Recreation" account and deposit 2,000.00 AUD into the "Budget:Rent" account. [0063] Figure 32 illustrates a user interface screen that shows the users current average monthly income which is calculated from data in the future transactions data repository. This user interface screen also enables the user to view a statement that shows the expected withdraws and deposits between period specified by the user for established assets and liability accounts. The account surplus amount is calculated by subtracting the account total withdraw amount from the account current balance. The account surplus amount enables the user see how much money to transfer to an account to prepare for future spending. [0064] The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive.

Claims (14)

1. A method for managing financial resources comprising: establishing a plurality of financial accounts comprising two types of financial accounts, a first type for tracking a total spending limit and a second type for tracking a budgetary category spending limit; and transferring value between accounts from said plurality of financial accounts to record a change in spending limits.

2. The method according to claim 1, further comprising the step of determining a balance with each of said plurality of financial accounts.

3. The method according to claim 2, further comprising the step of displaying a balance with each of said plurality of financial accounts after transferring value between accounts from said plurality of financial accounts.

4. The method according to claim 2, further comprising the step of determining the total spending limit and total available funding after transferring value between accounts from said plurality of financial accounts.

5. The method according to claim 4, further comprising the step of displaying the total spending limit and total available funding after transferring value between accounts from said plurality of financial accounts.

6. The method according to claim 2, further comprising the step of determining the number of said plurality of financial accounts with a balance less than zero after transferring value between accounts from said plurality of financial accounts.

7 The method according to claim 6, further comprising the step of displaying the number of said plurality of financial accounts with a balance less than zero after transferring value between accounts from said plurality of financial accounts.

8. An apparatus used to manage financial resources comprising: means for establishing a plurality of financial accounts comprising two types of financial accounts, a first type for tracking a total spending limit and a second type for tracking a budgetary category spending limit; and means for transferring value between accounts from said plurality of financial accounts to record a change in spending limits.

9. The apparatus according to claim 8, further comprising means for determining a balance with each of said plurality of financial accounts.

10. The apparatus according to claim 9, further comprising means for displaying a balance with each of said plurality of financial accounts after transferring value between accounts from said plurality of financial accounts.

11. The apparatus according to claim 9, further comprising means for determining the total spending limit and total available funding after transferring value between accounts from said plurality of financial accounts.

12. The apparatus according to claim 11, further comprising means for displaying the total spending limit and total available funding after transferring value between accounts from said plurality of financial accounts.

13. The apparatus according to claim 9, further comprising means for determining the number of said plurality of financial accounts with a balance less than zero after transferring value between accounts from said plurality of financial accounts.

14. The apparatus according to claim 13, further comprising means for displaying the number of said plurality of financial accounts with a balance less than zero after transferring value between accounts from said plurality of financial accounts.