WO2001077933A1

WO2001077933A1 - System and method for automated tracking of financial transactions

Info

Publication number: WO2001077933A1
Application number: PCT/US2000/013716
Authority: WO
Inventors: Richard E. Pickering
Original assignee: Pickering Richard E
Priority date: 2000-04-06
Filing date: 2000-05-17
Publication date: 2001-10-18
Also published as: AU2000250280A1; WO2001077937A1; AU2000240749A1

Abstract

A system and method for automatically tracking financial activity for an end user (12). Transaction data are electronically received from at least one transaction data source (20, 22, 24, 26), the transaction data associated with an account of an end user (12). End users (12) may select which of their various credit card, debit card, checking account, etc., are to be part of the service. The transaction data is automatically sorted into categories based on identifier information in the transaction data.

Description

SYSTEM AND METHOD FOR AUTOMATED TRACKING OF FINANCIAL TRANSACTIONS

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation-in-part of U.S. Application Serial No. 09/271,522, filed March 18, 1999, the entirety of which is incorporated herein by reference.

FIELD OF THE INVENTION

This invention generally relates to a system and method of automated input and tracking of financial transactions useful for generating financial reports, such as budget reports and expense reports, for end users.

BACKGROUND OF THE INVENTION

Electronic financial information is prevalent in the economy due to the increasing use of automated transactions, credit and debit card services, and e- commerce conducted across the Internet. These transactions are typically made by electronic payment instruments such as a credit, charge or debit type card that utilize electronic means for transfer of payment, often at the point of sale. Other ways to make purchases are with personal (paper or electronic) checks.

Both consumers and business often desire to track financial items (income and expenses) and generate user reports, such as budget reports, expense reports, etc., in order to monitor financial transactions. Most personal or business financial systems currently available require the user to manually input data in order to generate meaningful reports. This is time consuming and laborious.

On the other hand, credit/debit and charge card companies and merchants provide details about the transactions a user makes. This transaction detail comes in the form of monthly statements or data that can be downloaded by the user. The user still must manually enter the data into the appropriate report fields in order to generate useful reports. In addition, most financial institutions (banks or brokerage houses) provide data to users that details the checks written, deposits made and cash withdrawn. Accordingly, it would be desirable to provide a system and method that would allow a user to receive an automated report for transactions conducted with that user's instruments by the use of electronic methods, thus reducing effort and inaccuracy associated with manual transaction report generation and reconciliation. It is to the provision of such an improved system and method that the present invention is primarily directed.

SUMMARY OF THE INVENTION

Briefly, the present invention is directed to a system and method for automatically tracking and presenting financial activity for an end user. Transaction data are electronically received from at least one transaction data source, the transaction data associated with an account of an end user. End users may select which of their various credit card, debit card, checking account, etc., are to be part of the service. The transaction data are automatically sorted into categories based on identifier information in or associated with the transaction data. In one embodiment, the transaction data includes merchant type identifiers such as, for example, standard industry codes ("SIC") indicative of the nature of the financial transactions. In another embodiment, the transaction data includes item identifier information that is used to automatically categorize each item of a multi-item transaction, e.g., receipt details from a merchant. The account service provider receives user transaction data from one or more transaction data sources according to the instructions made by an end user. In this way, the user can integrate some or all of his/her financial transactions into meaningful reports. A variety of other financial resources and comparison features are provided that are also available to end users. The above and other objects and advantages of the present invention will become more readily apparent when reference is made to the following description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of the system according to the present invention.

FIG. 2 is a block diagram of the account service provider according to the present invention.

FIGs. 3 and 4 are diagrams showing examples of category-coded checks useful in connection with the present invention.

FIG. 5 is a flow chart depicting the generation of transaction(s) by an end user credit/debit card transaction. FIG. 6 is a diagram pictorially representing the overall process according to the present invention and an example of a user report.

FIG. 7 is a flow chart illustrating the steps of processing transaction data according to the present invention.

FIGs. 8 and 9 are diagrams illustrating how a user may manually enter and categorize transaction data that the ASP does not otherwise automatically categorize.

FIG. 10 is a flow chart illustrating a process for prompting users to manually categorize transaction data and for seeking permission from end users to receive detailed transaction data from a merchant.

FIG. 11 is a diagram depicting a message that is provided to an end user in association with the process shown in FIG. 10.

FIG. 12 is an example of a screen displayed by the account service provider that shows budget comparison information for an end user.

FIG. 13 is an example of a screen displayed by the account service provider that shows category information by month. FIG. 14 is an example of a screen displayed by the account service provider that graphically compares expenses by category from month to month.

FIGs. 15 and 16 are examples of screens displayed by the account service provider that compares budget information for an end user with information for an average budget. FIG. 17 is an example of a screen displayed by the account service provider that shows a calendar for recording and scheduling transactions.

DETAILED DESCRIPTION OF THE INVENTION Referring to FIG. I, the present invention will be described. According to the present invention, an account service provider (ASP) 10 interfaces with one or more end users via user devices 12 and a plurality of transaction data sources. User device 12 may be a personal computer (PC), Internet-capable wireless communication device, web browser or any other device capable of communicating with the ASP 10 and performing basic graphic display or voice communication, computation and communication functions. Each end user generates financial transactions associated with one or more financial accounts. A web browser device is an example of a device that may be used by an end user to communicate with the ASP 10.

The term "user transaction data" is meant to refer to the transaction data associated with any account from which an end user may spend money or into which an end user may deposit or receive financial credits. User transaction data includes, but is not limited to, transaction data associated with credit card accounts, debit/ ATM card accounts, checking (paper and electronic) accounts, savings accounts, investment accounts, Internet accounts, user transaction recording devices (such as "smart cards" or hand-held computer devices, such as Palm® computing devices), that store transaction information.

Transaction data sources include card institutions 20, financial institutions 22, processors 24, merchants 26 and user transaction recording devices 28. Examples of card institutions 20 are credit card issuers, charge card issuers, debit card issuers, etc. Examples of financial institutions 22 are banks and/or brokerage firms that manage checking and savings accounts, investment accounts, etc. Processors 24 are, for example, transaction processors for card institutions 20, financial institutions 22, and merchants 26 as well as check processors for card institutions 20, financial institutions 22 and any other entity against which checks are drawn. In addition, processors 24 includes entities that receive user transaction data at the request or authorization of an end user, such as on-line or Internet banking or transaction data services provided by Yahoo!® and Intuit®, AOL®, Microsoft Money®, etc. Another example of a processor is a wireless network service provider that receives transaction data via wireless transmissions from a user transaction recording device 28. Merchants 26 are the entities from which users make transactions to purchase goods or services, receive credits for returns and exchanges, etc.

The ASP 10 also tracks non-transaction type data, such as account balance information, account posting information, etc.

End users communicate with the ASP 10 through one or more communication network(s). Similarly, the ASP 10 receives information from the transaction data sources via the communication network(s) 30. The communication network(s) 30 is, for example, the Internet, and/or any a combination of other wired and wireless networks. In other instances, the ASP 10 may have a dedicated data feed with a particular transaction data source. The end users are individuals or business entities (small or large) and each end user has an account with the ASP 10. When enrolling for service with the ASP 10, the end user identifies to the ASP 10 the transaction data sources for user transaction data to be automatically tracked and merged into a unified user report. As used hereinafter, the term "user report" is meant to include budget reports, expense reports (personal or business type) or other types of spending reports, including, but not limited to, profit and loss reports.

The end user provides information about the transaction data sources to be used by the ASP 10, such as transaction data from credit, debit, charge card, paper and/or electronic checking, investment and other accounts that the user wishes to be part of the service. The end user can be enrolled either directly with the ASP 10 or indirectly in conjunction with a benefit or service provider, including card institutions, financial institutions, processors, merchants, Internet portals, etc. The ASP 10 assigns a service account number or other identifier unique to each end user. The end user may also mail a signed registration form with other related information to the ASP 10 or related institution as noted above. The ASP 10 can be a stand-alone entity that end users subscribe to, or the functions that are performed by the ASP 10 can be integrated into the functions and services provided by card institutions 20, financial institutions 22, processors 24 and/or merchants 26 or other companies including Internet portals. Turning now to FIG. 2, the ASP 10 is shown in more detail. The ASP 10 comprises computing equipment 110, data storage equipment 120 and a communication interface 130. The computmg equipment 110 consists of one or more PCs, servers, computers or other computing equipment or device that execute(s) the processes described herein. Transaction data associated with end users is stored in a database residing on the data storage equipment 120. The data storage equipment may be any suitable large storage device or system known in the art. The communication interface device 130 is coupled to a communication network(s) and comprises a communication interface, such as for example, a modem bank, an ISDN device, DSL modem(s), wireless networks, etc. FIGs. 3 and 4 illustrate category code checks useful in connection with the present invention. The category-coded checks are either paper or electronic and may be used by an end user that has a checking account that is either serviced by the ASP or by any financial check processor that processes end user checks. Category coded checks enable the ASP to automatically sort a purchase paid for by the check. FIG. 3 shows an example of a category-coded check 200 that has a plurality of boxes 210 labeled with a corresponding category. When making a payment with the check 200, the end user checks a box that corresponds to the category for which the payment is made. FIG. 4 shows a category-coded check 300 that includes code block 310 in which an end user writes an alphanumeric code corresponding to the appropriate category. The end user selects the proper code from a list of alphanumeric codes 320 listed on the face of the check, the checkbook register or otherwise provided to the end user. Category-coded checks like those shown in FIGs. 3 and 4 enable the ASP to automatically sort purchases/payments into the appropriate category for user report generation. In addition, as described further hereinafter, category-coded checks assist the ASP in processing check payments to avoid double counting of charge card payments for user report purposes.

FIG. 5 illustrates the basic process by which transaction data is generated when a user conducts a transaction. In step 40, the end user conducts transaction(s), such as a purchase, deposit, credit, etc. The purchase may be by credit card, debit card, category- coded check, electronic check, cash, smart card, etc. Transaction data associated with the transaction is generated in step 42. For example, if the transaction was the purchase of a good or service from a merchant with a credit, debit or charge card, then the transaction data generated will include a merchant type identifier, such as a standard industry classification (SIC) code. The merchant type identifier is used by the ASP 10 to identify and classify the purchase of goods or services into report categories. This transaction data may also include an item type identifier that identifies the particular item purchased. This is particularly useful to categorize items in a multi-item purchase transaction. Next, in step 44, the transaction data is transmitted or downloaded to the ASP 10 tlirough one of a variety of communication means as already described from a transaction data source. The ASP 10 will know which transaction data source to receive information from on behalf of an end user based on the transaction data sources identified by an end user at enrollment or any time when a user adds, deletes or modifies a transaction data source. The processing of user transaction data will be described in more detail with reference to FIGs. 6 and 7, in conjunction with FIG. 1. FIG. 6 shows the operation of the ASP at a higher operational level and FIG. 7 shows more detail aspects of the ASP's operation.

Referring first to FIG. 6, in general terms, the ASP receives transaction data from one or more transaction data sources, sorts the transaction data into categories (if information in or associated with the transaction data allows the ASP to do so), updates user reports based on new transaction data, and displays user reports, such as a budget report or expense report.

Turning now to FIG. 7, the ASP 10 receives transaction data from one or more transaction data sources (card institution 20, financial institution 22, processor 24, merchants 26 or user transaction recording device 28) in step 50. The ASP 10 then segregates the transaction data, if necessary, and stores the transaction data associated with a corresponding user account for each end user in step 52. The storage of the segregated data can be in a raw form or in a stored database, electronic spreadsheet or other electronic format in a database of transaction data for an end user. Associated with or contained in some transaction data is an identifier that allows the ASP 10 to automatically sort the transaction information into an appropriate category; the identifier may be one field of information contained in the transaction data or may be appended to information in a transaction record. In step 54, the newly received transactions are processed according to one or more of a variety of criteria. After the transaction data is processed, one or more user report(s) for that end user is updated in step 56. The user report is useful to show the user historical financial information useful in financial analysis, budgeting, personal finance planning, business finance planning, etc. The types of processing that may occur in step 54 will be now explained.

According to one aspect of the invention, transaction data received by the ASP that is received from a transaction data source is automatically categorized into one of several spending or budget categories. There is an initial set of categories that are pre-assigned by the ASP 10 to all existing merchant type identifiers and by default, a transaction is automatically categorized according to that preset assignment. However, a user has the option of altering a pre-assigned relationship for certain transactions to change the corresponding spending or budget category. For example, the merchant type identifier (such as an SIC code) associated with a (credit card, debit card, etc.) transaction is used to categorize the transaction. It is worthy to again note that an end user may have multiple sources of data (different credit card accounts, debit card accounts, checking accounts, savings accounts, etc.) from which transaction data is received and processed.

Still referring to FIG. 7, another type of processing will be described to categorize individual items of a multi-item transaction. For example, if an end user shops at K-Mart, he/she makes a purchase in the automotive department and another purchase in the clothing department on the same or different transaction. Another example is the multiple types of spending a user makes at a hotel (room service/meals, lodging, cleaning, etc.) If the detail transaction data from the receipt at the merchant is made available to the ASP 10, then the ASP 10 is able to delineate specific charges by category within a specific retailer by an item identifier or by merchant department code. This allows for categorization of charges at a more micro level than simply capturing the amount of the total charge from the merchant by merchant type identifier.

Accordingly, at step 60, detailed electronic receipt type data from a merchant (or other source) is received by the ASP 10 that includes item type identifiers and corresponding amounts for each item in a multi-item transaction. The received information in step 60 is similar to an electronic receipt and it contains the same information typically included on a cash register receipt, such as item description, item identifier type code, department code, corresponding item amount, subtotal, tax and total amount. This data is obtained through a data feed that the ASP 10 negotiates for from a merchant or from a processor 24 that manages this information on behalf of a merchant. The detailed data may be sent tlirough the communication network(s) via dedicated modem connection, Internet, wireless network, or other means known in the art.

In step 62, the ASP 10 matches the detailed transaction information to the corresponding end user (based on the credit card account number) and determines whether a corresponding "general" transaction record appears in that user's transaction data which would have been received from a credit card processor or other financial institution. For example, it is possible that before the detailed transaction information is received by the ASP 10, a more generalized transaction has already been recorded that would include the same information as the detailed information. If so, then in step 64 that "general" transaction (which was not categorized at the micro level) is replaced with transaction information for each item that was purchased. This avoids double counting of the transaction(s). On the other hand, if no corresponding "general" transaction is present, in step 64, the transaction information for each item is stored as if a separate transaction. In essence, the ASP detects when transaction data received from two or more transaction data sources references the same data items for an end user so as not to double count the same transaction data.

From step 64, the process continues to step 54 where the more detailed transaction information is processed. Specifically, in step 54, the detailed transaction information is categorized based on an item identifier (product code, department code, etc.) for that item. The user report information is updated in step 56.

A further use of the electronic receipt received by the ASP for a user is to expedite user report processing. Specifically, the electronic receipt (embodied as a data file) can be transmitted to the end user (via email or otherwise downloaded). The user can review the items on the electronic receipt, complete an electronic user data input report based on the items in the receipt, and send the electronic receipt with the completed electronic user report for approval and processing. The electronic receipt also may be sent to a printer to be printed, if necessary. One use of the electronic receipt is to facilitate processing of expense reports. See co-pending U.S. Application No. 09/271,522, filed March 18, 1999, referred to above, for further details on automated expense reporting.

With reference to FIGs. 8 and 9, another processing feature that occurs in step 54 is the automatic reconciliation of user report information to detail transaction information provided by a transaction data source. Data in the user report is compared to some or all of the transaction information provided by a merchant or other source of that end user. A transaction that has not been categorized is flagged, so that the user can manually categorize it. This is useful when the transaction data received by the ASP does not include identifier information to enable the ASP to automatically sort it. Examples of such transaction data is data f esulting from transaction made by regular checks, cash purchases, some charge card transactions (whereby the merchant type identifier or item type identifier is not present) or any other transaction that does not include identifier information that the ASP can use to automatically categorize the transaction. One method of doing this involves notifying an end user when a transaction has not been automatically sorted in order to allow the end user to manually add it to the report. The ASP provides notification by, for example, sending an email message to an end user or displaying a message on a web page. The end user can edit the message to include category information to enable the transaction to be sorted according to information provided by the end user, and respond to the email message back to the ASP. In another method, the ASP displays a message in a web page to the end user during the end user's connection session with the ASP. FIGs. 8 and 9 are exemplary user interface screens that show how the ASP may display to the end user information about transactions that have not been categorized in order to allow the end user to manually categorize them.

Referring back to FIG. 7, still another processing feature that optionally occurs in step 54 is tracking of deposits into an account of an end user. Deposits/credits are contained in statement data transmitted from a financial institution to the ASP 10. For example if an end user makes deposits into a checking, savings, investment, etc., account, the ASP 10 will recognize the deposits and enter categorize them as income. The ability to track deposits has particular utility in automatically determining whether a user has been reimbursed by an employer for authorized business related credit card transactions, for example.

Another type of processing occurs in step 54 when transaction data provided to the ASP is from (paper or electronic) category-coded checks such as those shown in FIGs. 3 and 4. The category information identified on the face of a category-coded check is recorded with the transaction data by a check processor for the bank, investment company, etc., from which the check is drawn and processed. The check processor generates a corresponding digital category code that is transmitted to the ASP together with other transaction data associated with the category-coded check transaction. The ASP uses the digital category coded to automatically sort the transaction into the appropriate category for that end user.

Yet another processing feature that optionally occurs in step 54 is tracking data automatically entered into a user report to prevent double counting of data from two or more data sources. For example, an end user pays for a credit card bill with a check. The expenses on the credit card are processed into the user report as explained above. Subsequently, a user pays the credit card bill with a check and the check is entered into the user report from any other transaction data source. However, since the charge card transaction detail would have already been processed and accounted for in the user report, the dollar amount paid for by the check would be double counted in the user report. The ASP 10 prevents double counting if some or all of the charge card data has already been categorized and entered into a user report by matching the charge card transaction data to the payment of the charge card bill based on, for example, a combination of one or more of: the charge card payment due date, the "credit card" category indicated on a category-coded check, transaction identifier number if coded or otherwise identified on the check that pays that charge card bill, dollar amount, merchant identifier and/or merchant name. These are only examples of the manner in which the ASP determines a match. It should be understood that the source of the data for the charge card transactions may be different from the source of the data for the bank statement information necessary to detect and avoid double counting of a transaction. The foregoing description relates to processing of "on-line" type transactions.

Another type of transaction that can be uploaded to the ASP 10 for processing and inclusion in a user report is an "off-line" transaction. An example of a device from which the ASP 10 receives off-line transaction data is the user transaction recording device 28 shown in FIG. 1. For example, the user transaction recording device 28 stores data representing the transactions that have been initiated with it. For example, a user goes to a merchant and makes multiple purchases with a smart card or other user transaction recording device. The smart card records the transaction detail data for all of the purchases at check-out. The data from the smart card is periodically uploaded into an application that resides on the user device 12 (via the interface device 110) and ultimately to the ASP 10 the next time the user logs in to the ASP 10, or on demand. The ASP 10 automatically loads the transaction data from the smart card into a user report according to the methods described above. The ASP 10 would also compare the transaction data it receives from the smart card with monthly credit card data to be sure it does not "double count" the transaction data received by the ASP 10 from another transaction data source, following the procedures described above. Similarly, a user may enter "cash" transactions, i.e., those transactions in which cash was used to purchase goods or services. The user may enter the cash transactions either during a connection session with the ASP or during an off-line session, in which case the transaction data is uploaded at the next log in session. When entering a cash transaction, the user may select which category the expenditure is assigned to, or the ASP may suggest a category based on the name of the merchant.

Examples of other ways that off-line transaction data entered by a user into a user transaction device 28 or that a user submits to other third party financial (banking) service providers is received by the ASP 10 are described above in conjunction with FIG. 1. Transaction data (deposits, withdrawals, payments, etc.) from these sources are also processed by the ASP 10 to be incorporated into a user report.

FIGs. 10 and 11 illustrate still another feature according to the present invention. The ASP, in an attempt to obtain detailed transaction data from a particular merchant (called a target merchant hereinafter), may send an email or present a web page to an end user that contains a message similar to that shown in FIG. 11. The message achieves two functions: (1) to obtain directly from an end user sufficient information to categorize individual items purchased at a particular merchant that were not categorized to that level of detail by the ASP; and (2) to obtain permission from the end user to petition or request detailed transaction data information from the merchant in order to automatically categorize transaction data to that level of detail.

The ASP identifies a target merchant based on a variety of criteria, such as the spending behavior of a number of end users in step 140. In addition, each end user that frequently makes purchases at that target merchant is identified by searching through the transaction data of ASP end users. Once a target merchant is identified, the ASP in step 142 sends an email message or displays a particular web page during a connection session to an end user. The message is generated by the ASP and lists spending categories for products or services that can be purchased from a target merchant. As shown in FIG. 11, the message instructs the user to enter the approximate amounts (if not the exact amounts) that the end user spent on the various product categories at that merchant during a recent visit to that merchant that the ASP has processed (but not previously processed to that level of detail). In step 144, the user enters amounts in the various categories. The message, if contained in an email, operates as a Java™ or other applet that can add and subtract as numbers are entered to reach a total amount. In step 146, the user hits a "reply/send" button in the email message or a "submit" button on the web page to send the transaction data entered by the end user to the ASP to allow the ASP to categorize the transaction data to a more detailed level.

Next, in step 148, contained within the message is a statement requesting for authorization from the user to add his/her name to a petition to have that target merchant automatically send detailed transaction data to the ASP thereby allowing the ASP to automatically categorize transaction data to a greater level of detail. The end user may check a box that gives the ASP the authority to include that user's name on a petition that will ultimately be presented to the target merchant. Step 148 may occur before step 146 to force the end user to reply to the request before sending or submitting the transaction data. In step 150, the ASP accumulates permissions from end users and eventually petitions the target merchant to receive detailed transaction data for those end users that have given authorization to the ASP.

Other features and functions that are provided by the ASP will be described in conjunction with FIGs. 12-17. Some of these features are provided as a result of the ASP's ability to track financial information of multiple users and compare information among end users.

FIGs. 12-14 are examples of user interface screens generated by the ASP that display user report information in a variety of formats. FIG. 12 shows monthly comparison information for an end user. FIG. 13 shows detailed category information by month. FIG. 14 is a graphical comparison diagram of expenses by category. With reference to FIG. 12, the ASP will provide references (discount vendors, budget assistance, etc.) to an end user based information in a user report for an end user. The ASP may use a reference budget to compare an end user's actual spending/saving activity with a reference budget. The reference budget may be a user-determined budget, a budget set by the ASP, or an average or median budget for end users in similar income brackets. Moreover, in establishing a reference budget, the ASP may adjust for factors such as income/spending bracket, the end user's geographic location or other demographic variables (age, race, family size, profession, household members, etc.). In addition, the budget suggested by the ASP is generated for multiple levels of savings rates, so that end user's can pace themselves with respect to savings and spending activity in order to meet the suggested budget. For example, for end users in similar income brackets and/or having other common factors, the ASP generates a suggested budget with monthly spending caps in a variety of spending categories. The reference budget may be determined from empirical data from outside sources or from data accumulated by the ASP across all or a portion of end users that subscribe to the ASP, or a combination thereof. Each month the ASP compares the end user's actual financial activity with the suggested budget.

One use of the reference budget is if the end user is over budget across all categories or a specific category, the ASP provides certain tips or references for tips to the end user. One form of a reference is a hyperlink to the web site of one or more vendors, budget help resources, etc. For example, as shown at 400 in FIG. 12, if the ASP determines that an end user has expenses in a travel category that is more than some reference budget amount, the ASP may list links to several discount travel sites. Similar references are shown at 410 in FIG. 13 in which case the ASP has determined that an end user has above average entertainment expenses and provides a list of discount entertainment resources. Likewise, FIG. 14 shows category information in graphical format and provides a link to budgetary resources as shown at 420.

FIGs. 15 and 16 illustrate display screens that the ASP generates by comparing one end user's financial data with that of other end users and/or other data from outside sources. For example, the ASP may compare the financial information of end users in similar income brackets in order to provide meaningful advice to end users. FIG. 15 shows comparisons between an end user's monthly budget and "The American Budget", i.e., an average budget of those in a similar income bracket. The ASP will identify to the end user those categories that are above the average as well as those categories that are better than the average, as shown at 440. Furthermore, when the ASP identifies for an end user a category that is better than the average, the ASP may provide a message to that end user asking if that end user would be willing to share his/her spending tips/secrets with other end users in a similar income bracket. If so, the ASP would receive (via email or during a connection session a message) from that end user an explanation of the spending habits followed by that end user and share that information with other end users. FIG. 16 illustrates another example of how the ASP displays information that compares an end user's spending information with a reference budget. Also, end users may compare their financial information with other end users during electronic chat sessions.

Still another feature is to provide a grade or score to an end user based on how well that end user's budget compares to a reference budget.

Yet another feature is to provide spending opportunities to those end users who save a relatively large amount of money. These end users may, for example, be encouraged to make more expensive purchases for luxury type goods and/or services. The ASP may provide links to resources for such goods and/or services. Still another feature is to provide user interface or electronic chat rooms for end users in the same income bracket to share information directly with each other.

FIG. 17 illustrates an example of a calendar function that the ASP provides for an end user to enable the end user to schedule bill payments and to view transaction information. The data displayed in the calendar is from multiple transaction data sources and automatically provides a unique view of financial information.

The above description is intended by way of example only and is not intended to limit the present invention in any way except as set forth in the following claims.

Claims

What is claimed is:

1. A method for automatically tracking financial activity for an end user, comprising: electronically receiving transaction data from at least one transaction data source, the transaction data associated with an account of an end user; and automatically sorting the transaction data into categories based on identifier information in or associated with the transaction data.

2. The method of claim 1, and further comprising generating a report for an end user based on the categories of transactions and making the report electronically accessible to the end user.

3. The method of claim 1 , wherein the step of electronically receiving comprises receiving transaction data from a plurality of transaction data sources.

4. The method of claim 3, and further comprising the end user identifying the transaction data sources from which to receive transaction data for that end user.

5. The method of claim 3, and further comprising generating a report based upon transaction data from multiple accounts of an end user.

6. The method of claim 1, and further comprising notifying an end user when a transaction has not been automatically sorted in order to allow the end user to manually sort it.

7. The method of claim 6, and wherein the step of notifying comprises notifying an end user with a message, and further allowing the end user to edit the information in the message to include category information to enable the transaction to be sorted according to information provided by the end user.

8. The method of claim 1 , wherein the step of electronically receiving further comprises electronically receiving financial statement data for an end user including deposit transactions into an account of an end user.

9. The method of claim 1 , wherein the step of electronically receiving further comprises electronically receiving financial statement data for an end user including withdrawals from an account of an end user.

10. The method of claim 1, and further comprising the step of determining when a charge card transaction made by an end user has been reimbursed by detecting in the transaction data for an end user a corresponding deposit or credit into an account for that end user.

11. The method of claim 1 , and further comprising the steps of detecting when transaction data received from two or more transaction data sources references the same data items for an end user so as not to double count the same transaction data.

12. The method of claim 11 , wherein transaction data referencing the same data items is entered only once into a user report.

13. The method of claim 1 , wherein the step of automatically sorting is based upon merchant type identifier information included in or associated with the transaction data for a transaction.

14. The method of claim 1, wherein the step of automatically sorting is based upon item type identifier information in or associated with the transaction data for a transaction.

15. The method of claim 1 , wherein the step of electronically receiving comprises receiving transaction data for a multi-item transaction conducted by an end user at a merchant, wherein the step of automatically sorting is based upon item type identifier information included in the transaction data for the multi-item transaction.

16. The method of claim 15, and further comprising steps of determining whether transaction data for a multi-item transaction has been previously processed as a single transaction by locating a transaction record that matches the multi-item transaction, and if so, replacing transaction information for the single transaction with transaction information for the multi-item transaction.

17. The method of claim 1, and further comprising receiving off-line transaction data associated with a transaction of an end user.

18. The method of claim 17, wherein the step of receiving off-line transaction data comprises receiving transaction data stored in a user transaction recording device and relating to transactions made by an end user.

19. The method of claim 18, wherein the step of electronically receiving comprises receiving transaction data stored in the user transaction recording device from a processing entity that receives transaction data from the user transaction recording device.

20. The method of claim 1 , and further comprising: identifying a target merchant where a particular end user has made transactions; providing information to the particular end user that lists categories for products or services; receiving data from the particular end user indicating amounts in the categories for expenditures made at the target merchant; and sorting the data for the particular end user into appropriate categories.

21. The method of claim 20, and further comprising requesting authorization from the particular end user to seek permission to receive detailed transaction data from the target merchant for transactions made by the particular end user at the target merchant.

22. The method of claim 1, wherein the step of electronically receiving comprises receiving transaction data associated with transactions made with a category- coded check, wherein the identifier information in the transaction data for the category- coded check comprises a category code.

23. The method of claim 1 , wherein the step of automatically sorting comprises sorting transaction data corresponding to a transaction made with the category-coded check using the category code in the transaction data for the category coded check.

24. The method of claim 1 , wherein the step of electronically receiving comprises receiving transaction data from a user transaction recording device either directly from the user transaction recording device or from a processing entity that receives transaction data from the user transaction recording device.

25. An account service provider that tracks financial activity for a plurality of end users capable of communicating with the account service provider, comprising: a communication interface suitable for connecting with end user sites via a communications network and with at least one transaction data source; computing equipment coupled to the communication interface that electronically receives transaction data associated with at least one account of an end user from the at least one transaction data source and automatically sorts the transaction data into categories based on identifier information in or associated with the transaction data; and a data storage coupled to the computing equipment to store transaction data for each of the plurality of end users.

26. The account service provider of claim 25, wherein the computing equipment generates a report for an end user based on the categories of transactions and makes the report electronically accessible to an end user.

27. The account service provider of claim 25, wherein the computing equipment electronically receives transaction data from a plurality of transaction data sources.

28. The account service provider of claim 27, wherein the computing equipment receives information from an end user to identify transaction data sources from which to receive transaction data for that end user.

29. The account service provider of claim 27, wherein the computing equipment generates a report based upon transaction data from multiple accounts of an end user.

30. The account service provider of claim 25, wherein the computing equipment notifies an end user when a transaction has not been automatically sorted in order to allow the end user to manually sort it.

31. The account service provider of claim 30, wherein the computing equipment generates a message transmitted to the end user, and allows the end user to edit transaction data to include category information to enable the transaction to be sorted according to the information provided by the end user.

32. The account service provider of claim 25, wherein computing equipment receives financial statement data for an end user including deposit transactions into an account of an end user.

33. The account service provider of claim 25, wherein computing equipment receives financial statement data for an end user including withdrawals from an account of an end user.

34. The account service provider of claim 25, wherein the computing equipment determines when a charge card transaction made by an end user has been reimbursed by detecting in the fransaction data for an end user a corresponding deposit or credit into an account for that end user.

35. The account service provider of claim 25, wherein the computing equipment detects when transaction data received from two or more transaction data sources references the same data items for an end user so as not to double count the same transaction data.

36. The account service provider of claim 35, wherein the computing equipment enters transaction data referencing the same data item only once into a user report.

37. The account service provider of claim 25, wherein the computing equipment automatically sorts transaction data based upon merchant type identifier information in or associated with the transaction data for a transaction.

38. The account service provider of claim 25, wherein the computing equipment automatically sorts transaction data based upon item type identifier information in or associated with the transaction data for a transaction.

39. The account service provider of claim 25, wherein the computing equipment receives transaction data for a multi-item transaction conducted by an end user at a merchant, and automatically sorts the transaction data based upon item type identifier information included in the transaction data for the multi-item transaction.

40. The account service provider of claim 39, wherein the computing equipment determines whether transaction data for a multi-item transaction has been previously processed as a single transaction by locating a transaction record that matches the multi-item transaction, and if so, replacing transaction information for the single transaction with transaction information for the multi-item transaction.

41. The account service provider of claim 25, wherein the computing equipment receives off-line transaction data associated with a transaction of an end user.

42. The account service provider or claim 41, wherein the computing equipment receives transaction data stored in a user transaction recording device and relating to transactions made by an end user.

43. The account service provider of claim 42, wherein the computing equipment receives transaction data stored in the user transaction recording device from a processing entity that receives transaction data from the user transaction recording device.

44. The account service provider of claim 25, wherein the computing equipment identifies a target merchant where a particular end user has made fransactions; provides information to the particular end user that lists categories for products or services; receives data from the particular end user indicating amounts in the categories for expenditures made at the target merchant; and sorts the data for the particular end user into appropriate categories.

45. The account service provider of claim 44, wherein the computing equipment requests authorization from the particular end user to seek permission to receive detailed transaction data from the target merchant for transactions made by the particular end user at the target merchant.

46. The account service provider of claim 25, wherein the computing equipment receives transaction data associated with transactions made with a category- coded check, wherein the identifier information in the transaction data for the category- coded check comprises a category code, and automatically sorts transaction data corresponding to a transaction made with the category-coded check using the category code in the fransaction data for the category coded check.

47. The account service provider of claim 25, wherein the computing equipment receives transaction data from a user transaction recording device either directly from the user transaction recording device or from a processing entity that receives transaction data from the user transaction recording device.

48. The account service provider of claim 25, wherein the computing equipment generates user reports for a plurality of end users.

49. The account service provider of claim 48, wherein the computing equipment generates average spending and or saving information for one or more categories across a plurality of end users.

50. The account service provider of claim 49, wherein the computing equipment provides information to an end user with respect to category-specific spending of an end user.

51. The account service provider of claim 50, wherein the computing equipment provides suggestions to an end user to reduce spending in a category when it is determined that spending in that category for that end user is greater than a reference budget amount.

52. The account service provider of claim 50, wherein the computing device provides a link to a web site of one or more vendors selected by the computing device that provide assistance to the end user to alter spending in that category.

53. The account service provider of claim 52, wherein the computing equipment provides names of one or more category specific vendors to an end user based upon the comparison of that end user's spending habits in a category with respect to spending habits across a plurality of end users in that same category.

54. The account service provider of claim 25, wherein the computing equipment compares financial information of end users based on a variety of factors, including one or more of income brackets, spending brackets, geographic location and demographics.

55. The account service provider of claim 54, wherein the computing equipment displays information to an end user that illustrates comparison of financial activity of that end user compared to other end users having one or more comparable factors.

56. The account service provider of claim 54, wherein the computing equipment requests permission from an end user determined to have relatively good spending habits in a particular category to share spending tips of that end user with other end users in a comparable income bracket.

57. The account service provider of claim 54, wherein the computmg equipment displays a message to a first end user providing spending tips of second end user determined to have relatively good spending habits in a particular category for end users having one or more comparable factors.

58. The account service provider of claim 54, wherein the computmg equipment generates a reference budget for end users based on one or more comparable factors.

59. The account service provider of claim 58, wherein the computing equipment generates a suggested budget for end users in similar income brackets and for end users that save money at similar rates.

60. The account service provider of claim 49, wherein the computing equipment generates a grade or score for end users based on how they compare to other end users in one or more categories.

61. The account service provider of claim 25, wherein the computmg equipment detects when an end user is saving a relatively high amount of money and displays to the end user information for opportunities to spend money.

62. The account service provider of claim 25, wherein the computing equipment generates a reference budget for an end user based on a variety of factors, including one or more of income brackets, spending brackets, geographic location and demographics.