WO2014164382A1 - Thematic repositories for transaction management - Google Patents

Thematic repositories for transaction management Download PDF

Info

Publication number
WO2014164382A1
WO2014164382A1 PCT/US2014/022215 US2014022215W WO2014164382A1 WO 2014164382 A1 WO2014164382 A1 WO 2014164382A1 US 2014022215 W US2014022215 W US 2014022215W WO 2014164382 A1 WO2014164382 A1 WO 2014164382A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
transaction
thematic
repository
data
Prior art date
Application number
PCT/US2014/022215
Other languages
French (fr)
Inventor
Trevino Rojas GERARDO
Original Assignee
Paybook, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Paybook, Inc. filed Critical Paybook, Inc.
Priority to US14/774,047 priority Critical patent/US10121208B2/en
Priority to BR112015022133A priority patent/BR112015022133A8/en
Priority to CA2941355A priority patent/CA2941355A1/en
Priority to EP14780012.2A priority patent/EP2965293A4/en
Priority to MX2015012116A priority patent/MX361879B/en
Publication of WO2014164382A1 publication Critical patent/WO2014164382A1/en
Priority to HK16108255.5A priority patent/HK1220281A1/en
Priority to US15/433,966 priority patent/US10366457B2/en
Priority to US16/526,567 priority patent/US20190355067A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12Accounting
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance

Definitions

  • FIG. 1 illustrates an example operating environment in which the techniques disclosed herein may be implemented, in accordance with certain embodiments.
  • FIG. 2 illustrates further details of one or more example computing device(s) of FIG. 1, in accordance with certain embodiments.
  • FIG. 3 illustrates an example user interface, in accordance with certain embodiments.
  • FIG. 4 illustrates another example user interface, in accordance with certain embodiments.
  • FIG. 5 illustrates yet another example user interface, in accordance with certain embodiments.
  • FIG. 6 illustrates an example process to create a thematic repository, in accordance with certain embodiments.
  • FIG. 7 illustrates an example user interface for creating a thematic repository, in accordance with certain embodiments.
  • FIG. 8 illustrates an example process to receive transaction data, in accordance with certain embodiments.
  • FIG. 9 illustrates an example process to extract transaction information from a user-selected file, in accordance with certain embodiments.
  • FIG. 10 illustrates an example process to designate transaction information to thematic repositories, in accordance with certain embodiments.
  • FIG. 11 illustrates an example process to share a thematic repository between multiple entities, in accordance with certain embodiments.
  • FIG. 12 illustrates an example process to apportion a monetary value between multiple entities, in accordance with certain embodiments.
  • Embodiments of the present disclosure are generally directed to techniques for using thematic repositories of a transaction management platform to facilitate the management of transaction activity, such as automating financial tasks involving receipt tracking, time tracking, expense reporting, and budgeting.
  • the transaction management platform may be used, for example, to manage personal transactions, business transactions, or both.
  • the financial transaction management platform may also include social features that enable collaboration and transaction sharing among entities, such as business and individual subscribers, who track and record their transactions.
  • Example Use Scenario(s) section provides an exemplary illustration of techniques involved in the utilization of various aspects of a transaction management platform, including thematic repositories, in accordance with certain embodiments.
  • a business traveler (User A) who works for Employer X is going on a business trip from Austin, Texas to Monterrey, Mexico to give a sales presentation. User A also works for Employer X on a project in Austin, Texas. To be reimbursed for business-related expenses regarding the Monterrey Trip, User A is expected to submit receipts or similar documentation showing reimbursable business-related expenses. User A is traveling with a companion (User B) as far as Laredo, Texas where User B will stop and visit family. That is, User B may not continue on to Monterrey, Mexico.
  • Employer X also employs an Austin-based computer consultant (User C) on an hourly basis who splits time between the Austin Project and a project in Hutto, Texas (the "Hutto Project”).
  • User C an Austin-based computer consultant
  • Employer X has a company checking account at Bank Y that is used to issue checks for the Austin Cl and the Hutto Project.
  • the Austin Project is financed by a lender (Bank Z) that requires Employer X to submit financial information and draw requests regarding the Austin Project on a weekly basis.
  • Employer X is also required to maintain separate accounts for the Austin Project and Hutto Project, and to accurately segregate time and expenses between these Projects. For this reason, Employer X instructs User A and User C to report their time and expenses working on the Austin Project on a daily basis.
  • Employer X also instructs User C to report his time and expenses working on the Hutto Project on a daily basis.
  • Employer X initially uses a client device to access the transaction management application and create a transaction management account named "Employer X Account.” As part of the account creation process, the employer may be assigned a transaction management account email, e.g., EmployerX@tmaexample.com.
  • Employer X may then log into the transaction management account by providing a username and a password and create a thematic repository named "Monterrey Trip Expenses" to manage transaction activity relating to expenses to be incurred in connection with User A's Monterrey trip.
  • Employer X may also create thematic repositories named "Austin Project” and "Hutto Project” to manage transaction activity relating to these projects.
  • a thematic repository may also be referred to as a "paybook.”
  • Employer X also adds User A and User C to the list of employees to be invited to collaborate with Employer X regarding thematic repositories.
  • Employer can add, view and/or select employees or other individuals for collaboration in using the transaction management platform in various embodiments.
  • Employer X may invite User A to access the transaction management application and join the Monterrey Trip Expenses thematic repository as a member so that both Employer X and User A can track expenses related to the Monterrey trip.
  • Employer X may also send an email invitation to User A to join the Austin Project thematic repository as a member.
  • Employer X may send an email invitation to User C to access the transaction management application in order to join the Austin Project thematic repository as a member and to join the Hutto Project thematic repository as a member.
  • Employer X may set permissions that allow only transaction data in the Master Austin Project thematic repository on the transaction management platform (TMP) server regarding User A to be shared with User A and that allow only transaction data in the Master Austin Project and Hutto Project thematic repositories on the TMP server regarding User C to be shared with User C.
  • Employer X may also send an email invitation to Bank Z to access the transaction management application and join the Austin Project thematic repository.
  • Employer X may set permissions that allow only particular transaction data in the Master Austin Project thematic repository on the TMP server to be shared with Bank Z that may be necessary for Bank Z to process draw requests or otherwise comply with lending requirements.
  • Employer X Because the Monterrey Trip is expected to last several days, Employer X has provided a cash advance of $500.00 to User A. Employer X may create a "User A Collect Account” under Monetary Receivables Accounts for $500.00. Employer X may tag the $500.00 advance with the applicable "GL Code" to ensure that his bookkeeping is accurate. Employer X may also create a User A Monterrey Expenses Account under Monetary Debit Accounts to keep track of business expenses that User A submits.
  • User A may receive the invitations from Employer X and may accept the invitations.
  • User A may use a client device to access the transaction management application and create a transaction management account named "User A Account.”
  • User A may be assigned a transaction management account email, e.g., UserA@tmaexample.com.
  • User A may log into the transaction management account and join the Monterrey Trip Expenses thematic repository and the Austin Project thematic repository created by Employer X. These are business-related thematic repositories, so User A may place the thematic repositories under the "business" portion of the transaction management account.
  • User A since User A likes to golf, he may create a thematic repository named "Golf under the "personal" portion of the transaction management account to manage golf-related transaction activity. User A may also create a personal thematic repository named "Laredo Trip" to manage travel-related transaction activity for his trip with User B to Laredo. He may add User B to his list of connections, and invite User B to join the Laredo Trip thematic repository, so that they can both track expenses related to the Laredo trip. User B may accept the invitation and join the Laredo trip thematic repository after creating his own user account.
  • User A may set up his accounts at Bank V and Bank W for tracking, and provide Bank V his UserA@tmaexample.com email address so the account information from Bank V may be sent directly to the transaction management platform (TMP) server for processing and input into User A's transaction management account.
  • TMP transaction management platform
  • Bank W may not offer this option and, instead, may provide bank statements directly to User A by email in portable document format (PDF).
  • PDF portable document format
  • User A may also enter data regarding the amount of cash he has on-hand and his credit card account information. User A may remember that he still owes $30.00 to User B for the purchase of golf balls earlier in the week and may record this data by creating a User B Debit Account in Monetary Debit Accounts. This account may now displayed in the monetary debit area of the dashboard. User A may also tag the transaction under the golf thematic repository. User A may notice by viewing the dashboard that a monetary debit account already is in place regarding the cash advance of $500.00 from Employer X.
  • User A and User B may stop at a gas station to refuel. They may also purchase a snack and golf tees for User A and sunglasses for User B. User A may pay because he still owes $30.00 to User B for the golf balls.
  • the gas station cashier may give a receipt to User A that itemizes the purchased items of gas, User A's snack and golf tees, and User B's sunglasses.
  • User A may take a photo of the receipt and use the photo input feature provided by the transaction input module of the transaction management platform.
  • the transaction data may be routed for quality control to quality control system (QCS) through a network to verify the accuracy and proper format of transaction data and perform other quality control measures.
  • QCS quality control system
  • User A may tag the digital representation of the receipt for entry into the "Monterrey Trip Expenses” thematic repository, the “Laredo Trip” thematic repository, and the "Golf thematic repository.
  • User A may configure the transaction data from the digital representation of the receipt by: (1) splitting the gas purchase equally between User A and User B; (2) tagging the snack purchase to the "Monterrey Trip Expenses" thematic repository and “Laredo Trip” thematic repository; and (3) further tagging the snack purchase to the Traveling Category and categorizing it as "food.”
  • User A may also tag the sunglasses purchase as being assigned to User B in the "Laredo Trip" thematic repository.
  • the transaction data in User A's member "Laredo Trip” thematic repository may be routed to the Master "Laredo Trip" thematic repository on the TMP server.
  • User B as a member of the "Laredo Trip” thematic repository group, may receive detailed information regarding the expenses attributed to each of User A and User B on the Laredo Trip via User B's transaction management account, thereby providing a convenient way of determining the age-old issue of "who owes who what?"
  • a User B "collect" account may be created in User A's transaction management account and the amount of the difference may be displayed on User A's dashboard.
  • User A may configure the golf tees transaction data to be identified in the "Golf thematic repository and "Laredo Trip" thematic repository.
  • User A may select the "Golf thematic repository for display on the Golf account dashboard, and request to view a report of transactions within the last two months.
  • User A may be provided with data graphics that show him the details regarding money spent with respect to User A's golf hobby. User A may see that money was spent on golf balls, golf grips, gas, snacks, green fees, lodging, and their respective percentages of the total of expenditures within the last two months.
  • User A may further configure the transaction data from the receipt to: (1) create a copy of the image of the receipt; (2) "redact” the golf tees transaction data and sunglasses transaction data since these are not business expenses; (3) authenticate the copy of the digital image; and (4) tag the snack and gas purchases to the Monterrey Trip Repository and assign each to Employer X as reimbursable business expenses.
  • the transaction data in User A's member "Monterrey Trip Expenses" thematic repository, along with the redacted and digitally signed copy of the image of the receipt may be routed to the Master "Monterrey Trip Expenses" thematic repository on the transaction management platform (TMP) server.
  • TMP transaction management platform
  • Employer X, as a member of the "Monterrey Trip Expenses" thematic repository group, may be provided with substantially immediate detailed information regarding the business expenses incurred by User A.
  • User A may use the currency conversion feature of the transaction management platform to convert Mexican pesos into U.S. dollars and may configure the parking expense transaction data to: (1) create copies of the digital images; (2) configure the images to superimpose a label that identifies the sales call and amount charged for parking in U.S. dollars; and (3) tag the parking expense to the Monterrey Trip Repository and assign them to Employer X as reimbursable business expenses.
  • the parking expense transaction data in User A's member "Monterrey Trip Expense" thematic repository, along with labeled copies of the digital images may be routed to the Master "Monterrey Trip Expense" thematic repository on the TMP server.
  • Employer X as a member of the "Monterrey Trip Expenses" thematic repository group, may be provided with substantially immediate detailed information regarding this business expense, including geocoding information that confirms the location of the parking lot and the amount of time that User A parked in the lot.
  • User A may also use the transaction management platform to enter his hours spent on the Austin Project and tag this information to his member Austin Project repository. User A may also enter the mileage for his trip to Monterrey. The data may be routed to the Master Austin Project thematic repository on the TMP server.
  • User C who also accepted Employer X's invitation, may enter his hours spent on each of the Austin Project and the Hutto Project in User C's respective member thematic repositories and such information may be routed to the Master Austin Project and Master Hutto Project thematic repositories on the TMP server.
  • Employer X may see, in a substantially real-time manner, each of User A's and User C's expenses and time, and may generate one or more reports regarding the projects.
  • the transaction management platform may flag the golf tees transaction data and allow Employer X to filter it, whether for viewing purposes or for reporting purposes.
  • Employer X may designate its company bank account at Bank Y for management of transaction activity using the transaction management platform. Employer X may use the "drag and drop input" feature of the transaction management platform to input the latest account statement that was sent by Bank Y in PDF format.
  • the transaction data may be routed for quality control (QC) to a quality control system (QCS) through a network to verify the accuracy and proper format of transaction data and perform other quality control measures.
  • QC quality control
  • QCS quality control system
  • Employer X may configure the Bank Y transaction data by tagging information relating to the "Austin Project” to the Austin thematic repository and tagging information relating to the "Hutto Project” to the Hutto thematic repository.
  • the Austin Project transaction data in Employer X's member "Austin Project” thematic repository (which may include the shared transaction data from User A, User C, and Bank Y regarding the Austin Project) may be routed to the Master "Austin Project” thematic repository on TMP server; and Bank Z, as a member of the "Austin Project” thematic repository group, may be provided with detailed information regarding the "Austin Project,” according to the permissions established by Employer X.
  • User A wants to collect the money owed by User B for the sunglasses and User B's share of fuel purchased on the Laredo Trip.
  • User A views the dashboard and notices that the User B Collect Account only shows $20.00 even though User A knows the sunglasses and one-half of the fuel expense was $50.00.
  • User B collect account User A reviews the transaction data detail relating to the amounts owed by User B for the Laredo Trip and also the credit applied from the amount owed by User A to User B for the golf balls.
  • User A sends User B a reminder notification regarding the $20 owed to User A.
  • User B is able to quickly confirm the amount owed by viewing the dashboard for his transaction management account and clicking on the Owe Account for User A which displays the transaction data detail relating to the amounts owed by User B for the Laredo Trip and also the credit applied from the amount owed by User A to User B for the golf balls.
  • FIG. 1 illustrates an example operating environment 100 in which techniques described herein may be implemented.
  • the operating environment 100 may include one or more client device(s) 102(1)-102(N), which may be coupled to one or more server(s) 106(1)- 106(N), across one or more network(s) 104(1)-104(N).
  • client device(s) 102(1)-102(N) i.e., the plural form
  • client device 102 i.e., the singular form
  • use of the singular form may include the plural form in certain implementations.
  • the client device 102, the server 106, or both may include various types of computing devices.
  • the client device 102, the server 106, or both may be implemented as a laptop computer, a desktop computer, a server, a smart phone, an electronic reader device, a mobile handset, a personal digital assistant (PDA), a portable navigation device, a portable gaming device, a tablet computer, a watch, a portable media player, a television, a set-top box, a computer system in a car, an appliance, a camera, a robot, a hologram system, a home -based computer system (e.g., intercom system, home media system, etc.), a projector, an automated teller machine (ATM), a pair of glasses with computing capabilities, and so on.
  • PDA personal digital assistant
  • ATM automated teller machine
  • a user may use the client device 102 to manage transaction activity.
  • the client device 102, the server 106, or both may be configured with, or otherwise include, one or more transaction management module 108, which may provide the functionality for carrying out the techniques described in this disclosure.
  • the transaction management module(s) 108 may include executable computer code that can be executed by one or more processors.
  • the transaction management module(s) 108 may include computer code which, when executed by one or more processors, allows a user of the client device 102 to manage transaction activity.
  • the computer code of the transaction management module(s) 108 may be stored locally within the client device 102, or may be provided across the network 104, for example, by the transaction management module(s) of the server 106.
  • the operating environment 100 may also include one or more storage devices 110(1)-110(N).
  • the storage device(s) 110 may store, for example, transaction data.
  • the client device 102, the server 106, or both may be coupled to the storage device(s) 110 across the network 104. Additionally or alternatively, the storage device(s) 110 may reside locally with respect to the client device 102, the server 106, or both.
  • the storage device(s) 110 may include one or more computer readable storage media. Exemplary computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data.
  • Computer storage media may include, but is not limited to, phase change memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device.
  • PRAM phase change memory
  • SRAM static random-access memory
  • DRAM dynamic random-access memory
  • RAM random access memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technology
  • CD-ROM compact disk read-only memory
  • DVD digital versatile disks
  • magnetic cassettes magnetic tape
  • magnetic disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store
  • the client device 102, the server 106, or both may be capable of accessing transaction information from one or more bank/financial institution servers (not shown).
  • bank/financial institution servers include servers associated with brokerage companies, credit card companies, financing companies, and the like.
  • the client device 102, the server 106, or both may provide transaction information received from the bank/financial institution server such that a user may be able to manage transactions corresponding to the transaction information received from the bank/financial institution server.
  • the bank/financial institution server may comprise various components similar to those of the client device 102, the server 106, or both.
  • any disclosure provided herein with respect to the client 102, the server 106, or both may also apply to bank/financial institution server.
  • the operating environment 100 may include a quality control (QC) device or system (not shown).
  • the client device 102, the server 106, or both may be coupled to the QC device across the network 104. Additionally or alternatively, the QC device may reside locally with respect to the client device 102, the server 106, or both.
  • the QC device may be configured to verify the accuracy and proper format of transaction data received from the client device 102, the server 106, or both, as a result of input by a user, or to perform other quality control measures regarding such transaction data.
  • the QC device may include or access one or more databases storing templates or other data for verifying the proper format of different types of transaction data.
  • the format of transaction data received from the client device 102, the server 106, or both may be compared with information stored in the one or more databases.
  • the QC device is capable of accessing templates, format data, or both, from a bank/financial institution server.
  • the QC device may perform quality control measures automatically. Additionally or alternatively, at least some of the quality control measures performed by the QC device may not be automatic (i.e., a human operator may be involved).
  • the QC device may comprise various components similar to those of the client device 102, the server 106, or both. Thus, it should be understood that various disclosures provided herein with respect to the client device 102, the server 106, or both, may also apply to QC device.
  • the operating environment 100 may include a transaction data compliance (TDC) unit (not shown).
  • the client device 102, the server 106, or both, may be coupled to the TDC unit across the network 104. Additionally or alternatively, the TDC unit may reside locally with respect to the client device 102, the server 106, or both.
  • the TDC unit may be used to verify that expenses submitted to a company for reimbursement are, in fact, reimbursable under the company's policies.
  • the TDC unit may include one or more databases that store information corresponding to reimbursable expenses.
  • the TDC unit may compare transaction data corresponding to expenses submitted by the user to the acceptable standards for reimbursable expenses stored in the database(s). Thus, expenses contrary to company policies may be flagged for non-compliance.
  • the TDC unit may be automatic, or may include operator involvement.
  • the TDC unit may comprise various components similar to those of the client device 102, the server 106, or both. Thus, it should be understood that various disclosures provided herein with respect to the client device 102, the server 106, or both, may also apply to the TDC unit.
  • FIG. 1 Those of ordinary skill in the art will appreciate that the hardware components and various functional modules depicted in FIG. 1 and elsewhere may vary. The illustrative components are not intended to be exhaustive, but rather are representative to highlight components that are utilized to implement the subject matter disclosed in the present application. For example, other devices/components may be used in addition to or in place of the hardware depicted. In addition, the various components illustrated in storage and memory may be alternatively located in any storage or memory across the network 104. The depicted example is not meant to imply architectural or other limitations with respect to the subject matter of this disclosure.
  • FIG. 2 illustrates further details of one or more example computing device(s) 200 (e.g., the client device 102, the server 106, or both) of FIG. 1.
  • the device 200 may include one or more processors 202, memory 204, one or more operating systems 206, one or more displays 218, one or more input/output (I/O) components 220, one or more network interfaces 222, or any combination thereof.
  • processors 202 may include one or more processors 202, memory 204, one or more operating systems 206, one or more displays 218, one or more input/output (I/O) components 220, one or more network interfaces 222, or any combination thereof.
  • I/O input/output
  • the memory 204 may include one or a combination of computer readable storage media.
  • Computer storage media includes volatile and non-volatile, removable and non- removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data.
  • Computer storage media includes, but is not limited to, phase change memory (PRAM), static random- access memory (SRAM), dynamic random-access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read- only memory (EEPROM), flash memory or other memory technology, compact disk readonly memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device.
  • PRAM phase change memory
  • SRAM static random- access memory
  • DRAM dynamic random-access memory
  • RAM random access memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read- only memory
  • flash memory or other memory technology
  • CD-ROM compact disk readonly memory
  • DVD digital versatile disks
  • magnetic cassettes magnetic tape
  • magnetic disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store information for access
  • the memory 204 may include an operating system 206.
  • the operating system 206 may be any platform that manages the execution of computer code and manages hardware resources.
  • the memory 204 may also include one or more applications, functional modules, or both.
  • the term "module" is intended to represent example divisions of the software for purposes of discussion, and is not intended to represent any type of requirement or required method, manner or necessary organization. Accordingly, while various "modules" are discussed, their functionality, similar functionality, or both, could be arranged differently (e.g., combined into a fewer number of modules, broken into a larger number of modules, etc.).
  • the modules may comprise computer instructions/code that may be stored in the memory 204 and may be executable by the one or more processors 202.
  • the memory 204 may include transaction management module(s) 108.
  • the transaction management module(s) 108 may comprise executable computer code which, when executed by the processor 202, allows a user to manage transaction activity.
  • Computer program code for the transaction module(s) may be: stored locally within the device 200, provided across network 104, or both.
  • the transaction management module(s) 108 may include a user interface module 208, a thematic repository module 210, a transaction input module 212, a transaction configuration module 214, a social module 216, or any combination thereof.
  • the transaction management module(s) 108 may generally receive input from a user, provide output to a user, or both.
  • the device 200 may utilize the functionality provided by the transaction management module(s) 108 to receive transaction-related information input, provide transaction-related information output, or both, to facilitate transaction management.
  • the input may include audio or speech, text, touch, or gesture input received e.g. via a sensor of the device 200.
  • the I/O components 220 may be configured to allow a user to interface with the device 200 via one or more I/O devices.
  • the I/O components 220 may provide an interface for such devices as a display 218, a keyboard (not shown), a mouse (not shown), a camera (not shown), an optical reader (not shown), a touchpad (not shown), or any combination thereof.
  • the display 218 may include, for example, a liquid crystal display (LCD), a plasma display, a cathode ray tube (CRT) monitor, a touch screen, any other kind of output display mechanism, or any combination thereof.
  • LCD liquid crystal display
  • CRT cathode ray tube
  • the transaction management module(s) 108 may include a user interface module 208, a thematic repository module 210, a transaction input module 212, a transaction configuration module 214, a social module 216, or any combination thereof.
  • the user interface module 208 may cause a user interface to be provided to a user (e.g., via the display 218 of the device 200).
  • the user interface may be used as a vehicle for operating the functionality provided by the transaction management module(s) 108, such as allowing the user to input data, receive data, view data, manipulate data, configure data, or any combination thereof.
  • the input data may cause the transaction management module(s) 108 to perform various tasks.
  • the user interface module 208 may be configured to provide a user interface that suits the particular device 200 being used by the user. For example, information may be presented to the user in a different manner when displayed on a mobile phone than when displayed on a personal computer.
  • the user interface of the transaction management module(s) 108 may be provided to a user via a web browser [e.g., software as a service (SaaS)], via a downloadable client application, or both.
  • a user may create a transaction management account in order to access/utilize the services provided by the transaction management module(s) 108.
  • Creating the transaction management account may involve the user providing certain requested personal information (e.g., name, username and/or email address), setting a secure password, and/or verifying that the user is a human and not a machine.
  • verifying that the user is a human and not a machine may be carried out by asking the user to drag and drop a menu item to a certain location. For example, the user may be presented with a word or an image, and the user may be asked to: recognize and select a corresponding word or image, and/or drag and drop a corresponding word or image to a certain location in the proximity of the presented word or image.
  • Verifying that the user is a human and not a machine may also be carried out by asking the user to complete a Completely Automated Public Turing test to Tell Computers and Humans Apart (CAPTCHA), a challenge-response test requiring the user to type letters and/or digits corresponding to those presented in a distorted image.
  • CATCHA Completely Automated Public Turing test to Tell Computers and Humans Apart
  • verifying that the user is a human and not a machine may be carried out by employing another method of attempting to prevent automated software from performing actions that degrade quality of service.
  • a user may be able to log in to the transaction management account by providing a username and/or an email address and a password, or any other suitable login credential(s) suitable for securely managing access to the user's transaction management account.
  • FIG. 3 illustrates an example user interface display of a master dashboard 300, in accordance with certain embodiments.
  • the master dashboard may be shown in a default configuration, highlighting a set of features commonly used or desired by users.
  • the default configuration of the master dashboard, as well as the specific features available to the user may vary depending on the status of the user who commonly logs into transaction management account. For example, the default configuration of the master dashboard 300 provided to an individual who uses the transaction management platform primarily for personal use may be different than the default configuration provided to a business owner who uses the transaction management platform primarily for business operations.
  • the default configuration of the master dashboard 300 and specific features provided may also vary depending on the type of user who commonly logs into transaction management account. As an illustrative example, the default configuration of the master dashboard 300 and available features for employees of a construction company may be different than the default configuration and features provided to the outside salespeople of a computer company.
  • master dashboard 300 Available features not fully detailed in the default configuration of master dashboard 300 may be accessed via links that provide drill-down paths to views or pages highlighting various levels of detail (i.e., providing varying levels of granularity) regarding such features.
  • the user can customize the master dashboard 300 such that the master dashboard 300 highlights the features most commonly used by that particular user.
  • FIG. 3 a certain configuration of features is illustrated in the master dashboard 300 of FIG. 3, it will be understood that the configuration is provided merely for illustrative purposes, and that the master dashboard 300, or any other aspect of the user interface, is not be limited to any particular configuration of features.
  • the master dashboard 300 includes an area for featuring one or more thematic repositories 302 (also referred to herein as "paybooks").
  • the thematic repository module 210 may provide the functional aspects related to the thematic repositories 302.
  • a user may create a thematic repository 302 to manage transactions that have one or more attributes under a common theme (as defined by the user).
  • the user may create each of the thematic repositories 302 to manage transaction types that correspond to the theme of the thematic repository.
  • the name the thematic repository 302 may be descriptive of the theme associated with the thematic repository 302.
  • a thematic repository 302 may be categorized under one or more other thematic repositories 302.
  • a first thematic repository 302a may be associated with a theme related to, but more narrowly defined than, a theme associated with a second thematic repository 302b. That is, in some embodiments, a thematic repository 302a may have a parent-child relationship with another thematic repository 302b.
  • the master dashboard 300 may include a monetary asset area 304 for identifying money that a user has, such as in the user's cash accounts 306, bank accounts (e.g., checking accounts 308, savings accounts 310, etc.), investment account(s) 312, or any combination thereof.
  • Bank accounts may include various types of accounts at a financial institution or brokerage house worldwide.
  • Cash accounts can include the user's "safe,” “cookie jar,” “wallet,” or any other repository where the user stores cash or cash equivalents.
  • the master dashboard 300 may include a monetary debit area 316 for identifying money that the user owes in connection with user's credit card accounts 314 and "IOU" accounts.
  • Credit card accounts 314 include any type of debit account involving the use of a credit card, credit line or similar payment mechanism.
  • "IOU" accounts may include amounts owed by the user to other individuals that are typically handled on an informal basis.
  • "IOU" accounts may also include amounts owed by the user to one or more business entities/companies. For example, the user may owe an employer for an unused cash advance. The amount owed for the cash advance may be indicated in an "IOU" account.
  • the master dashboard 300 may include a monetary receivables area 318 for identifying money that the user is owed in connection with "Collect" accounts.
  • "Collect" accounts may include amounts owed to the user by other individuals that are typically handled on an informal basis.
  • "Collect” accounts may also include amounts owed to the user by one or more business entities/companies. For example, the user may be owed an amount by an employer for reimbursable expenses (e.g., money spent by the user for business purposes in connection with the employer). The amount owed to the user by the employer may be indicated in a "Collect" account.
  • all accounts that the user sets up via the transaction management account may be listed in the master dashboard 300.
  • only select bank accounts or other accounts may be listed.
  • the user may select one or more bank accounts to list in the master dashboard 300, or the user may set a certain number of bank accounts that may be shown in accordance with a user-determined parameter.
  • the user may set the master dashboard 300 to show the five bank accounts with the highest balances, or the user may set the master dashboard 300 to show any bank account that satisfies a balance threshold.
  • the user may have options regarding the listing and configuring of other accounts described herein for display on the master dashboard 300.
  • the master dashboard 300 may display relevant or desired information corresponding to accounts created by the user, such as, but not limited to: bank name, balance, account number, type of account (e.g., checking, savings, etc.), country in which the account is held, date of the last transaction associated with the account, or any combination thereof.
  • relevant or desired information corresponding to accounts created by the user such as, but not limited to: bank name, balance, account number, type of account (e.g., checking, savings, etc.), country in which the account is held, date of the last transaction associated with the account, or any combination thereof.
  • Balances for the accounts may be displayed in any currency, or in any combination of currencies desired, along with the corresponding currency symbol(s).
  • the master dashboard 300 or pages available for linking from the master dashboard 300 may contain a currency conversion feature (not shown) that allows the user to display, calculate, or both, monetary information in one or more currencies by selecting from a plurality of currencies at the applicable exchange rate.
  • the user may select the default currency when setting up a particular account.
  • the user may click on or otherwise select a listed account or thematic repository 302 displayed in the master dashboard 300 to access additional information about the account, category or thematic repository, including detail about the transactions associated with the account, category, or thematic repository.
  • FIG. 4 illustrates an example user interface display of an account dashboard 400, in accordance with certain embodiments.
  • the account dashboard 400 may include many of the same or similar features as the master dashboard 300.
  • the user may create one or more budgets corresponding to one or more thematic repositories. For example, the user may set a limit for spending with respect to a thematic repository, and transactions associated with the thematic repository may be calculated against the limit for tracking and/or management purposes.
  • the master dashboard 300, the account dashboard 400, or both, may further include a "transaction display area" 402 (FIG. 4) that displays transaction-related data associated with a particular account or thematic repository 302.
  • the transaction display area 402 provides a list view of the most recent transactions associated with a particular account or thematic repository 302. For example, the transaction display area 402 may list the five most recent transactions corresponding to a particular account.
  • the transaction display area 402 may list the ten most recent transactions taking place in connection with the Laredo Trip repository if User A selects the thematic repository "Laredo Trip.” The user may have the option of customizing the transaction display area 402.
  • FIG. 5 illustrates an example user interface display of a transaction detail 500, in accordance with certain embodiments.
  • the master dashboard 300 may include a data graphics/analytics area 320.
  • the data graphics area 320 may include any type(s) of data graphic(s) suitable for reporting acquired data in a manner useful or desired by the user.
  • a non-exhaustive list of data graphics types may include pie charts, bar graphs, line graphs, pictographs, tables, or any combination thereof. It will be understood that each account dashboard 400 may have a similar data graphics area 320 that reports data associated with the particular account or thematic repository 302.
  • the data graphics area 320 of the account dashboard 400 might display a pie chart reporting statistics for the Laredo Trip thematic repository.
  • the pie chart might show various child thematic repositories 302 (e.g., "Food,” “Gas,” and “Golf), and their respective percentages, identifying the transactions related to the Laredo Trip thematic repository 302.
  • Each of the child thematic repositories 302 may be a part of one or more other parent thematic categories 302.
  • the descriptive child thematic repository 302 "Food” may be used to describe one or more transactions within the scope of each of the “Personal” and “Home” thematic categories 302.
  • the descriptive child thematic repository 302 "Food” may be used to describe one or more transactions within the scope of the "Monterrey Trip Expenses” repository.
  • a particular transaction is not limited to an exclusive association with a single thematic repository 302.
  • the data graphics area 320 may report statistics for a variety of features within the transaction management account.
  • the data graphics area 320 is not limited to reporting statistics for thematic repositories 302.
  • data graphics may be provided by default or by user request in one or more areas other than the master dashboard 300 and the account dashboard 400 of the transaction management account.
  • the master dashboard 300 may include one or more menus 322.
  • the user may select a menu 322 to navigate out of the master dashboard 300 and to another section of the transaction management account.
  • selecting a menu 322 modifies at least some of the information being displayed on the master dashboard 300 of the transaction management account.
  • the master dashboard 300 may include a search bar 324.
  • the user may search through transaction management account data via the search bar 324. Additionally or alternatively, the user may search and/or navigate through transaction management account data in any suitable manner, such as by using drop-down selected filters, radio button selected filters, voice commands and/or a tag cloud.
  • account dashboard 400 may have a similar features that allow the user to search and/or navigate through transaction data associated with a particular account.
  • the master dashboard 300 may include a notification area 326.
  • the notification area 326 may provide information to the user about transactions by a member of a shared thematic repository 302. Taking the facts of the Example Use Scenario(s) section, the notification area 326 may provide information to User A about actions taken by User B in connection with the shared Laredo Trip thematic repository.
  • the notification area 326 may also provide information to the user about the user's thematic repositories, accounts, transactions, or any combination thereof.
  • the transaction input module 212 may be configured to enable the input of transaction data in a variety of ways. As an initial matter, the user may be allowed to input information for setting up various accounts, thematic repositories, connections/collaborators and the like, in order to more efficiently track financial transactions.
  • FIG. 6 illustrates an example process 600 to create a thematic repository, in accordance with certain embodiments.
  • the transaction input module 212 may receive a request to create a thematic repository. The user may send or otherwise indicate a request to create a thematic repository by, for example, selecting a menu item from the master dashboard 300 or other user interface presented to the user.
  • the transaction input module 212 may receive a selection or other input of a theme associated with the thematic repository to be created.
  • the transaction input module 212 may receive a selection or other input of a name associated with the thematic repository to be created.
  • the transaction input module 212 may receive a selection or other input of a type associated with the thematic repository to be created.
  • the thematic repository may be associated with an account type, such as a bank account or a cash account.
  • the thematic repository may also be associated with a social connection type, such as an individual or a business entity.
  • the thematic repository may also be associated with a parent thematic repository type.
  • a thematic repository having a theme of "Paris” may be associated with a parent thematic repository having a theme of "Travel.”
  • the ability to associate a thematic repository with a type may allow a user to add a layer of classification to the thematic repository beyond the theme associated with the thematic repository. It should be understood that the aforementioned example types are non-exhaustive. That is, the user may be able to associate various other types with a thematic repository.
  • the transaction input module 212 may also receive a selection or other input of a default currency associated with the thematic repository to be created, at 610.
  • the transaction input module 212 may receive a selection or other input of an image associated with the thematic repository to be created.
  • the image may be displayed in connection with the thematic repository.
  • the image of a home 404 may be associated with a thematic repository used to manage transactions in relation to a user's home.
  • the image may help the user identify the thematic repository and/or allow the user to customize the aesthetics of thematic repository.
  • individual thematic repositories may be associated with their own images such that a first thematic repository may be associated with a first image while a second thematic repository may be associated with a second image, the second image being different from the first image.
  • the transaction input module 212 may create the thematic repository in accordance with the user inputs and save received thematic repository information in a data store, at 614.
  • FIG. 7 illustrates example user interface displays 700 for creating a thematic repository, in accordance with certain embodiments.
  • the transaction input module 212 may be configured to enable the creation of various financial accounts to allow the tracking of financial transaction information.
  • the transaction input module 212 may also be configured to allow a user to input information about one or more businesses for which the user would like to manage transaction activity using the transaction management platform (e.g., via the transaction management module(s) 108).
  • the user may also be allowed to input data regarding employees that might collaborate with the user regarding certain transaction activity using the transaction management platform.
  • the user may create multiple business accounts/profiles to manage transactions corresponding to multiple businesses. In certain instances, a transaction and/or transaction data may be associated with different business accounts/profiles.
  • the user may create a first thematic repository corresponding to a first business profile, and the user may create a second thematic repository corresponding to a second business profile.
  • the user may associate a transaction and/or transaction data to each of the first thematic repository and the second thematic repository such that the transaction and/or transaction data is associated with the first business profile and the second business profile.
  • the transaction input module 212 may also be configured to enable input of transaction data that will be tracked in the transaction management account.
  • FIG. 8 illustrates an example process to receive transaction data, in accordance with certain embodiments.
  • the transaction input module 212 may receive a request from a user to input transaction data.
  • the user may transmit the request via the user interface.
  • the request may comprise providing any suitable indication that the user wants to input transaction data, such as, for example, selecting a menu item designated for initiating the input of transaction data.
  • the transaction data may include one or more data items related to identifying or otherwise describing transaction-related information. For example, continuing to use the facts of the Example Use Scenario(s) section, User A purchases a snack, gas and golf tees at a gas station along the way, and also purchases a pair of sunglasses for User B at the same time. Terms used to describe these items and the amount paid for the items is considered transaction data.
  • transaction data with respect to the purchase transaction include, but are not limited to: the name of the business from which the items were purchased; the location of the business (including geocoding information); the date of purchase; the time of purchase; the method of payment; and details regarding the method of payment such as the debit or credit card used, the bank account associated with card, the name of the bank, the bank account type, and the bank account number; or any combination thereof.
  • the transaction-related information relating to the snack is collectively referred herein as the snack transaction data;
  • the transaction data relating to the gas is collectively referred to herein as the gas transaction data;
  • the transaction data relating to the golf tees is collectively referred to herein as the golf tees transaction data and the transaction data relating to the sunglasses is collectively referred to herein as the sunglasses transaction data.
  • the transaction input module 212 may provide, via the user interface, an input vehicle for receiving transaction data.
  • the input vehicle may be any mechanism by which the user may provide input that contains, at least in part, transaction data.
  • the transaction data may reside alongside non-transaction data, and the transaction data may either be automatically recognized, or the transaction data may be designated as such on-the- fly or at some later time by the user.
  • the transaction input module 212 may include or access a default library of transaction data that it may automatically recognize. Additionally or alternatively, the user may be able to define a library of transaction data that the transaction input module 212 may be able to automatically recognize.
  • the transaction input module 212 may receive the transaction data.
  • the transaction input module 212 may store the received transaction data.
  • the transaction input module 212 may cause the transaction data to be stored in the storage device 110 or in the memory 204.
  • the transaction input module 212 may be configured to enable the designation of bank accounts and tracking of financial information relating to those accounts.
  • bank/financial institution servers of one or more of the banks servicing bank accounts that the user designated for transaction activity management may be linked to the transaction management module(s) 108 such that transaction information from the respective bank accounts is pushed or otherwise downloaded to the storage device 110, the memory 204, or the transaction input module 212 via the network 104.
  • Transaction information push availability and frequency may vary depending on factors such as bank policy, bank location, and/or user settings.
  • the transaction input module 212 may receive transaction information from a bank in real-time or substantially real-time frequency, i.e., at or near the time each transaction occurs.
  • the transaction input module 206 may provide the transaction information to the user via the user interface.
  • the transaction input module 212 may be configured to receive transaction information from a bank each time the bank issues the user's bank account statement. When the transaction input module 212 receives the transaction information, the transaction input module 212 may provide the transaction information to the user via the user interface.
  • the transaction input module 206 may receive transaction information from a bank when the user manually downloads the information from a bank/financial institution server.
  • the transaction input module 212 may provide the transaction information to the user via the user interface.
  • FIG. 9 illustrates an example process 900 to extract transaction information from a user-selected file, in accordance with certain embodiments.
  • the user-selected file may comprise one or more files that include transaction data that the user wants to manage via the transaction management account.
  • the one or more selected files may comprise bank statements.
  • the bank may issue a bank statement as a password-protected file.
  • the user may also be able to password-protect the bank statement file.
  • the transaction input module 212 may add the bank account so that the user is able to manage transaction activity related to the bank account via the transaction management account.
  • the transaction input module 212 may receive a user-selected file; for example, the transaction input module 212 may receive a bank account statement containing bank account transaction data.
  • the user may select the file to input bank account transaction data via a drag-and-drop input feature, i.e., by dragging the file from a first location to a second location, and dropping the file at the second location.
  • the first location may be, for example, the operating system's "desktop" or a local file manager window.
  • the second location may be a transaction data input-designated area in the user interface of the transaction management platform.
  • the user may select the file to input the bank account transaction data by browsing to the file via a dialog box provided by the transaction input module 212 as the vehicle for providing transaction data input.
  • the user may select a digital representation of one or more transactions to be received by the transaction input module 212.
  • the user may select a digital representation of the bank statement or certain transactions listed in the bank statement to input bank account transaction data by using a photo input feature.
  • the transaction input module 212 may determine whether the format of the selected file is acceptable/supported.
  • the input file is transmitted to the QC device across the network.
  • the QC device may determine whether the format of the selected file is acceptable along with performing other quality control measures.
  • Acceptable file formats may include any file format in which financial transaction data is electronically communicated to the user, including but not limited to portable document format (PDF).
  • PDF portable document format
  • the QC device may determine whether the data pattern/format of the file matches the pattern/format of a stored template in a database residing in or accessible to the QC device. For example, if User A inputs a bank statement, the QC device may determine whether the format of the bank statement matches the format of an existing template in a database to allow bank account transaction data to be properly entered and organized. That is, the transaction input module 212 may parse the file for transaction data and organize the transaction data in accordance with predetermined parameters.
  • the QC device determines the format of the bank statement matches the format of a stored template a database
  • the bank account transaction data in the bank statement may be parsed and organized according to organization and other parameters of the stored template.
  • text that is not machine-encoded may be converted to machine-encoded text using optical character recognition (OCR) technology or the like.
  • OCR optical character recognition
  • the transaction input module 212 may include or otherwise access a default library of transaction data that it may automatically recognize. Additionally or alternatively, the user may be able to define a library of transaction data that the transaction input module 212 may be able to automatically recognize.
  • the QC device determines that the format of the bank statement does not match the format of a stored template in a database, then the user may be notified that the format of the bank statement is not recognized.
  • User A may either manually input the bank account transaction data or wait until notified the QC device has obtained a matching template.
  • the QC device may obtain a template of the bank statement from the bank as depicted or create a template for organizing the bank account transaction data from the bank statement input.
  • the transaction input module 212 may determine whether the user has selected a new file. If so, then the process 900 reverts to 902, where the transaction input module 212 may receive the new user-selected file. If the user does not try adding another file, then the process may end, at 916.
  • the user may select a plurality of files to be received by the transaction input module 212.
  • the user may use the drag and drop input feature to drag multiple files simultaneously from a first location to a second location, and drop the files simultaneously in the second location.
  • the user may drag-and-drop the files in parallel.
  • the user may also be allowed to select multiple files in series.
  • the user has the option of inputting data by taking a digital photo of the financial transaction data with a device having a digital camera using a "photo input feature.”
  • User A may input data to create the Laredo Trip thematic repository.
  • User A may also receive receipts such as the gas station receipt and similar proofs of payment while traveling to Laredo.
  • User A may have the option of inputting data by creating a digital image of the receipt using the photo input feature and associating the transaction data with the Laredo trip thematic repository.
  • the user may also have the option of using the photo input feature to take a digital photo of the item purchased or of identifying information associated with such item, such as a label or bar code.
  • the photo input feature may be used to input the parking expense transaction data.
  • the user may also have the option of associating various electronic files with a thematic repository, including electronic files not directly including transaction data.
  • a user may want to use a thematic repository to manage documents and/or images that are relevant or otherwise desired to be associated to the theme of the thematic repository.
  • the user may associate an image of a vehicle title or registration with a thematic repository designated for tracking the user's vehicle-related transactions.
  • the user may be able to access electronic files managed under the user's various thematic repositories.
  • the transaction configuration module 214 may provide for the configuring of transaction data.
  • the transaction configuration module 214 may receive a request from a user to configure the transaction data.
  • the request may comprise providing any suitable indication that the user wants to configure transaction data, such as, for example, selecting a menu item designated for initiating the configuration of transaction data.
  • the transaction configuration module 214 may proactive ly present the user with the option to configure transaction data, or may configure transaction data according to default parameters without user request.
  • the transaction configuration module 214 may provide, via the user interface, a vehicle for configuring the transaction data.
  • the user may configure transaction data by editing text or graphics displayed to the user. Further, the user may configure transaction data by selecting menu items via the user interface or in any manner suitable for transmitting configuration instructions to the transaction configuration module 214.
  • the configuration of transaction data may generate configuration data, and the transaction configuration module 214 may associate the generated configuration data with the transaction data.
  • the transaction configuration module 214 may store the transaction data and/or the associated configuration data.
  • the transaction data and/or the associated configuration data may be stored in the storage device 110 or in the memory 204.
  • the transaction configuration module 214 may receive a digital representation of one or more transactions via the transaction input module 212.
  • the digital representation may be presented to the user via the user interface displayed on the device 200.
  • the digital representation may comprise a purchase receipt that includes one or more transactions.
  • the transaction configuration module 214 may parse the digital representation to identify one or more transactions comprising configurable transaction data. For example, continuing with the facts of the Example Use Scenario(s) section, the transaction configuration module 214 may parse the digital representation of the purchase receipt for the snack, gas, golf tees and sunglasses.
  • the configurable transaction data may comprise information displayed to the traveler in descriptive terms "Gas,” “Snack,” “Golf tees,” and “Sunglasses;” and corresponding values "$W,” “$X,” “$Y,” and “$Z.” It should be understood that displayed configurable transaction data in this example may also include other information such as a time/date stamp, receipt number, and identifying information relating to the vendor. The transaction data may also comprise information that is not displayed to the traveler, such as geocoding information.
  • User A may also use the photo input feature to input the parking expense transaction data via the transaction input module 212.
  • the transaction configuration module 214 may parse the digital representation of the photo.
  • the configurable transaction data may comprise displayed configurable transaction data such as the image and may also comprise information that is not displayed to User A such as geocoding information associated with the digital photo.
  • the transaction configuration module 214 may provide, via the user interface, a vehicle for configuring the configurable transaction data within the digital representation.
  • the user may configure transaction data by editing text or graphics displayed to the user. Further, the user may configure transaction data by selecting menu items via the user interface.
  • the user may configure transaction data using touch screen gestures to indicate how the user wants to configure the transaction data.
  • the user may configure transaction data in any manner suitable for providing configuration instructions to the transaction configuration module 214.
  • the configuration of transaction data may generate configuration data.
  • the transaction configuration module 214 may associate the configuration data with the transaction data.
  • FIG. 10 illustrates an example process 1000 to designate transaction information to thematic repositories, in accordance with certain embodiments.
  • the transaction management module(s) 108 may receive transaction information.
  • the transaction information may be associated with a financial transaction.
  • Receiving information associated with a financial transaction may include receiving bank statement information. Additionally or alternatively, the receiving information associated with the financial transaction may include receiving purchase receipt information.
  • the transaction management module(s) 108 may determine, based on the information associated with the financial transaction, that the financial transaction is associated with a first theme and a second theme.
  • the thematic repository module 210 may designate at least a portion of the information associated with the financial transaction to a first repository.
  • the first repository may be configured to provide an aggregation of information associated with a plurality of financial transactions that are individually determined to be associated with the first theme. At least a portion of the information associated with the financial transaction may be designated to the first repository automatically. For example, at least a portion of the information associated with the financial transaction may be designated to the first repository automatically based at least in part on one or more predetermined rules. Additionally or alternatively, at least a portion of the information associated with the financial transaction may be designated to the first repository manually.
  • the thematic repository module 210 may designate at least a portion of the information associated with the financial transaction to a second repository.
  • the second repository may be configured to provide an aggregation of information associated with a plurality of financial transactions that are individually determined to be associated with the second theme. At least a portion of the information associated with the financial transaction may be designated to the second repository automatically. For example, at least a portion of the information associated with the financial transaction may be designated to the second repository automatically based at least in part on one or more predetermined rules. Additionally or alternatively, at least a portion of the information associated with the financial transaction may be designated to the second repository manually.
  • At least a portion of the information associated with the financial transaction may be designated to the first repository automatically and at least a portion of the information associated with the financial transaction may be designated to the second repository manually, or vice-versa.
  • the thematic repository module 210 may receive a request related to the financial transaction.
  • an indication that the financial transaction is associated with the first theme and the second theme may be provided, at 1012.
  • the social module 216 may enable the user to manage transaction activity socially.
  • the social module 216 may provide for the integration of one or more social networks.
  • a social network may be provided internally such that a user of the transaction management platform may interact with other users of the transaction management platform.
  • external social networks may be integrated within the transaction management platform via third party applications, thereby allowing the user of the transaction management platform to interact with users of the external social networks.
  • FIG. 11 illustrates an example process 1100 to share a thematic repository between multiple entities, in accordance with certain embodiments.
  • the social module 216 may receive, from a first entity, a selection of at least a second entity with which to share the selected thematic repository.
  • a sharing permission policy may be set.
  • the user may set the sharing permission policy.
  • a default or a system-defined sharing permission policy may be set.
  • the sharing permission policy may define the proposed sharing relationship between the first entity and the second entity. That is, the sharing permission policy may define rules with respect to what can and what cannot be shared between the first entity and the second entity.
  • the social module 216 may determine whether the second entity has a transaction management account. If the second entity has a transaction management account, then the social module 216 may notify the second entity of the proposed sharing relationship, at 1108. The social module 216 may also determine whether the second entity accepts the proposed sharing relationship, at 1114. If the second entity accepts the sharing relationship, then the social module 216 may notify the first entity that the second entity accepted the sharing relationship, at 1116. At 1118, the social module 216 may share the thematic repository between the first entity and the second entity.
  • the social module 216 may send an invitation to the second entity to create a transaction management account. The social module 216 may do so automatically, or at the request of the first entity. At 1112, the social module 216 may determine whether the second entity creates a transaction management account. If the second entity does not create a transaction management account, then the process 1100 may end. Similarly, if the second entity does not accept the proposed sharing relationship, then the process 1100 may end, at 1120.
  • FIG. 12 illustrates an example process 1200 to apportion a monetary value between multiple entities, in accordance with certain embodiments.
  • the transaction management module(s) 108 may identify, based on information associated with a financial transaction, at least one monetary value.
  • the transaction management module(s) 108 may determine whether the at least one monetary value is associated with an expenditure by a plurality of entities.
  • the transaction management module(s) 108 may apportion the at least one monetary value, at 1206.
  • the transaction management module(s) 108 may determine, based at least in part on at least one apportioned monetary value, that a first entity owes an owed monetary value to a second entity.
  • the transaction management module(s) 108 may provide an indication to at least one of the first entity or the second entity that the first entity owes the owed monetary value to the second entity.
  • at least a portion of the owed monetary value may be transferred to the second entity.
  • the first entity may transfer at least a portion of the owed monetary value to the second entity.
  • a third entity benefactor of the first entity may transfer at least a portion of the owed monetary value to the second entity.
  • the owed monetary value may be updated to an updated owed monetary value.
  • the updated monetary value may be a difference between the owed monetary value and the at least a portion of the owed monetary value transferred to the second entity.
  • An indication may be provided to at least one of the first entity or the second entity that the first entity owes the updated monetary value to the second entity.
  • processes for uploading/sharing a logo for a business profile may include prompting the user to select a logo image. The process may then proceed to upload a temporary file. Once the temporary file is uploaded, the uploaded image may be resized/cropped. The logo may be saved. The process may then proceed to switching the current profile to a new business identification (ID). The new business dashboard may then be displayed.
  • ID business identification
  • processes for creating employee accounts/profiles to link to an employer/company account may include prompting the user for a first name.
  • the process may proceed to prompting the user for a last name and an email address.
  • the user may be further prompted to select an existing department or enter a new department name.
  • the input may be validated and a request to create a new employee account may be generated.
  • a determination may be made as to whether the department exists. If the department exists, an employee profile may be created.
  • the process may then proceed to sending an activation email to the employee email address. After sending the email, the process may wait for user activation.
  • a determination may then be made as to whether the user's email is linked to a thematic repository. If the user's email is linked to a thematic repository, then the user may be prompted to approve an employee status with an existing account.
  • the process may then link the employee to the company.
  • the user may be prompted to determine if the user has an existing account to link. If the user has an existing account to link, then the user may be prompted to sign in to the account that is to be linked. A determination may be made as to whether the account is authenticated. If the account is authenticated, then the user may be prompted to approve an employee status with an existing account. The process may then continue as discussed above.
  • the user may again be prompted to sign in to the account to link. The process may then continue as discussed above.
  • an account creation form may be presented. The process may then continue to creating the user profile. After creating the user profile, the process may link the user to the company.
  • a template of employees may be processed. In some instances, all employees may be processed. Employees may also be processed by company department. Upon processing the template of employees, the user can view the employees and departments.
  • processes for the creation of employee accounts from a file may include prompting the user to select an input source. If the input source is a web service, a determination may be made as to whether the source is from a web service file or a direct connection. If the source is a web service file, the user may be prompted to upload the web service file. The process may then proceed to parsing the web service file for data. A list of employees may be created based at least in part on the parsed data.
  • the source from the web service is a direct connection
  • the user may be prompted for direct connection credentials (e.g., host, port, username, password, etc.).
  • the process may then proceed to requesting data from a service.
  • the process may then proceed to parsing received data and creating a list of employees.
  • the user may be prompted to upload the file.
  • a determination may be made as to whether the file is in an acceptable format. If the file is in an acceptable XLS format, the process may proceed to parsing XLS information and generating a list of employees. If the file is in an acceptable XML format, the process may proceed to parsing the XML structure for matching fields and generating a list of employees. If the file is in an acceptable CSV file, the process may proceed to parsing the rows for headers. The user may be prompted to select which columns correspond to one or more of first name, last name, email address, and department name. The information obtained from the CSV file may be used to generate a list of employees. [00166] If the file selected as the input source is not in an acceptable format, then the user may be informed that the file was unable to be uploaded. The user may be prompted to upload another file. The process may then continue as discussed above.
  • the process may proceed to adding an employee account, profile, or both, for each employee on the list.
  • a determination may be made as to whether each employee's corresponding department already exists. If the department does not exist, a new department listing may be created. The user may be prompted to customize a company activation email, and the activation email may then be sent to employees.
  • processes for updating employee information may include receiving an employee's identification (ID) to get employee data.
  • the process may also include receiving the employee's department ID to get department data.
  • the user may be presented with information associated with the employee, such as the employee's first name, last name, email address, and department.
  • the user may be presented the option to edit the employee data. If the user opts to edit the employee data, the process may continue to changing the output fields to input fields, and the user may be prompted to edit the employee information (e.g., first name, last name, and, email address, etc.). The process may then make a determination as to whether the changed data is valid.
  • the user may also be prompted to edit the department listing.
  • a determination may be made as to whether the department exists. If the department exists, the process may make a determination as to whether the changed data is valid. If the department does not exist, the process may continue to creating a new department listing before proceeding to determine if the changed data is valid.
  • the employee data may be updated, and the user may be notified that the employee data has been updated. If, on the other hand, the changed data is not valid, then the user may be informed of a validation error.
  • the output fields may again be changed to input fields, and the process may then continue as discussed above.
  • processes for tagging transaction data with GL codes may prompt the user for a label.
  • the user may also be prompted for a name.
  • a determination may be made as to whether the inputs are valid. If the inputs are valid, then a GL code may be created. The process may then proceed to reloading the GL code listings, and the GL codes may be received.
  • a determination may be made as to whether there are additional GL codes to be added. If there are additional codes to be added, then the user may be prompted for a label. The process may then continue as discussed above.
  • processes for updating the GL code for a category may include showing the user existing codes and categories. The user may be prompted to drag one or more GL codes on top of a category. A determination may be made as to whether the category has a GL code assigned to it. If the category does not have a GL code assigned, the process may proceed to attaching the GL code to the category. The updated category and the associated GL code may be displayed to the user.
  • the process may include detaching the existing GL code. A new GL code may then be attached to the category. The process may then continue as discussed above.
  • a transaction and/or transaction data may be automatically categorized into one or more categories.
  • the category may be a thematic repository.
  • One or more GL codes may be associated with the category.
  • the transaction and/or transaction data may be categorized into a "restaurants" category.
  • GL codes may be filtered automatically to present to a user the GL codes that correspond to the "restaurants" category.
  • the GL codes that correspond to the "restaurants" category may be "restaurants - business meal” and "restaurants - travel.”
  • the user may select one of these GL codes to accurately represent the nature of the transaction, which may have tax implications (e.g., a business meal may be 50% deductible as a business expense whereas a travel meal may be 100% deductible as a business expense).
  • processes for adding financial accounts may include causing a message to be displayed that prompts the user to select an account type. A determination may be made as to whether the user selects to add a cash account or a bank account.
  • the process may proceed to receiving account data (e.g., account name, starting balance, default currency, etc.) from the user.
  • account data e.g., account name, starting balance, default currency, etc.
  • the process may proceed to creating the cash account and storing data related to the cash account in a data store.
  • a message may be caused to be displayed that prompts the user to enter the name of a bank.
  • a determination may be made as to whether the bank is an existing bank. If the bank is an existing bank, then a determination may be made as to whether the bank supports a sync application. If the bank supports a sync application, then a message may be caused to be displayed that prompts the user to enter bank login credentials, such as a bank username and password. The bank credentials may be saved in a data store. The process may continue to waiting for the scheduled task to initiate.
  • the bank login credentials may then be sent to the bank's sync application. A determination may be made as to whether the bank login credentials are correct. If the bank login credentials are correct, then a determination may be made as to whether there is a requirement to answer a security question. If there is a requirement to answer a security question, then a message may be caused to be displayed that prompts the user to answer the bank security question. Upon receiving an answer to the bank security question, the answer may be sent to the sync application. A determination may be made as to whether the answer to the security question is correct. If the answer to the security question is correct, then financial information may be received from the bank.
  • bank login credentials are incorrect, then the user may again be prompted to enter bank login credentials and the process may continue as discussed above.
  • a message may be caused to be displayed that prompts the user to select a bank statement file.
  • the user may be presented with the option to drag and drop one or more bank statements, and data from the one or more bank statements may be imported as discussed below.
  • the user may also be presented with the option to request sync support for the user's bank.
  • processes for importing transactions may include receiving a user-selected file. A determination may be made as to whether the file is of a supported format. If the file is of a supported format, then a determination may be made as to whether the file is password protected. If the file is password protected, then a determination may be made as to whether the password is stored. If the password is stored, then a determination may be made as to whether the password is correct. If the password is correct, then data may be extracted from the file and an attempt may be made to find a supported template for the file.
  • the file may be sent to the new template development team so that a new template may be developed to support the file, the file type, the file format, or any combination thereof. Further, a message may be caused to be output to the user indicating that the file is not supported. The message may further include an indication that the user will be notified when the file is supported. A determination may be made as to whether there is an attempt to add another file. If there is an attempt to add another file, then the process may proceed to determining whether the file is of a supported format. If the file is of a supported format, then the process may proceed as discussed above.
  • a message may be caused to be output to the user indicating that the file is of an invalid format.
  • a determination may be made as to whether there is an attempt to add another file. If there is an attempt to add another file, then the process may proceed to receiving the user-selected file, determining if the new file is of a supported format, and so on, as discussed above. Otherwise, if there is no attempt to add another file, then the process may end, or the process may continually monitor to determine whether there is an attempt to add another file.
  • a stored password is incorrect (e.g., it is expired or was previously entered incorrectly), then the user may be prompted to enter a password for the file. Similarly, if the password is not stored, then the user may be prompted to enter a password for the file. The process may proceed by checking if any password entered by the user is correct, and the process may continue to prompt the user for a password if the password is again incorrect. Once a correct password is received, the process may proceed to extracting data from the file and attempting to find a supported template for the file as discussed above. [00188] If the file is not password protected, then the process may proceed to extracting data from the file and attempting to find a supported template for the file as discussed above.
  • processes for receiving/processing a receipt may include making a determination as to whether a mobile device is being used. If a mobile device is being used, then a window (or other indication) may be provided indicating that the user can take a picture or select a picture from a library (i.e., a data store). A determination may be made as to whether the user opts to select a picture from a library. If the user opts to select a picture from a library, then the process may proceed to receiving a selection of the picture.
  • any receipts digitally represented via received pictures may be processed (e.g., transaction data may be extracted and imported). Alternatively or additionally, received pictures may be processed on an ongoing basis (i.e., as they are received).
  • the user may take a picture using a camera of the mobile device.
  • the process may proceed to determining whether the picture is acceptable, which may include determining whether the picture satisfies certain conditions regarding quality and format of the picture. If the picture is determined to be acceptable, then a determination may be made as to whether the user opts to add another picture. The process may then continue as discussed above. Otherwise, if the picture is not determined to be acceptable, then the user may opt to take another picture. A determination may be made as to acceptability of each picture taken, selected, received, or any combination thereof.
  • processes for importing transactions may include receiving a digital representation of a receipt (e.g., a photo/picture/image of a receipt). A determination may be made as to whether the receipt is computer readable. If the receipt is computer readable, then the receipt may be processed with an optical character recognition (OCR) engine.
  • OCR optical character recognition
  • the process may then proceed to creating/adding transactions from the data extracted/processed by the OCR engine. These transactions may be displayed or otherwise provided to a quality assurance (QA) team or system. A determination may be made as to whether the receipt is QA readable. If the receipt is QA readable, then the process may proceed to setting, with respect to the transactions, description, date, amount, vendor, category, or any combination thereof. In some embodiments, further transaction details may be set. A determination may be made as to whether the transactions, individually or in combination, include valid data. If a transaction includes valid data, then the transaction is saved in a data store, and an indication of the transaction may be caused to be displayed to the user. If the transaction does not include valid data, then the process may proceed to setting, with respect to the transactions, description, date, amount, vendor, category, or any combination thereof. The process may then continue as discussed above.
  • QA quality assurance
  • transactions and/or transaction data may be extracted from documents (e.g., hard copies and/or electronic formats of receipts and/or invoices) on a summary level basis. That is, some details of one or more transactions and/or transaction data may not be extracted. Additionally or alternatively, transactions and/or transaction data may be extracted from documents (e.g., hard copies and/or electronic formats of receipts and/or invoices) on a line item level basis. That is, further details corresponding to one or more line item transactions and/or transaction data may be extracted. Thus, extraction may carried out on varying levels of granularity.
  • processes for importing transactions may include receiving, from a bank or other financial institution, a file (e.g., PDF, XML, OFX, QFX, CSV, etc.) that includes bank/financial statement information.
  • a file e.g., PDF, XML, OFX, QFX, CSV, etc.
  • the bank may send the file via email to the user at an email address associated with the transaction management module(s).
  • the email may be transmitted via simple mail transfer protocol (SMTP).
  • SMTP simple mail transfer protocol
  • a determination may be made as to whether the email address corresponds with a valid user. If the email address corresponds with a valid user, then the file is saved in a user directory (i.e., a data store).
  • a task may be scheduled to run at certain intervals (e.g., every five minutes). For example, the task may determine whether there are any files in the user directory that have yet to be processed. The task may further initiate extraction/importation of transaction data from any files
  • the email address does not correspond with a valid user, then the file may be deleted, designated not to be processed, or both.
  • processes for managing distance transactions may include determining whether a mobile device is being used. If a mobile device is being used, and if the mobile device provides global positioning system (GPS) functionality (or any other feature or system suitable for tracking distance), then a determination may be made as to whether to set the GPS to record distance. If the GPS is set to record distance, then a determination may be made as to whether the GPS is on or otherwise activated. If the GPS is on, then a determination may be made as to whether the GPS has synced. Otherwise, the user may be presented with a message indicating that the GPS is off or otherwise deactivated. If the GPS is on and has synced, then the user may be provided an indication that the GPS is ready for use. If the GPS has not synced, then the GPS may be queried for signal until, for example, it is determined that the GPS has synced.
  • GPS global positioning system
  • the user may also be prompted to provide an input indicating when the GPS is to start tracking distance.
  • start input is received from the user
  • the GPS may track distance until another input is received from the user indicating when the GPS is to stop tracking distance. While the GPS is tracking distance, the user may be presented with a map. If the user attempts to change the screen, the user may be presented with a warning regarding the in-process distance tracking.
  • stop input is received from the user
  • the data may be fetched from the GPS, including, for example, the tracked distance transaction data. The process may proceed to determining a price per unit distance (e.g., price per mile).
  • the user may be allowed to tag a location, tag a category, tag a business paybook, tag a personal paybook, post a comment, add a note, split a transaction, change a date, change a currency, attach a photo, tag a connection, or any combination thereof.
  • Splitting a transaction may include changing an item amount (e.g., changing a distance value or a monetary value), tagging an item to a category, tagging an item to a business paybook, tagging an item to a personal paybook, tagging an item to a contact from the user's connections, or any combination thereof.
  • Tagging an item to a category may include the item being automatically categorized in accordance with predefined rules.
  • the user may define rules for categorizing transaction data items, or the transaction management module(s) may be provided with default categorization rules, or both.
  • tagging an item to a contact may include choosing a contact, associating the contact with an amount/value, associating at least one of the item or the contact with a paybook, or any combination thereof.
  • Data that is added by the user may be saved in a data store.
  • a map feature or service that is capable of providing distances between two points via established routes (e.g., one or more roads).
  • processes for managing time transactions may include determining whether time is manually input. If time is manually input, then the user may be prompted to add time. The user may also be prompted to add a description and a price per hour. A determination may be made as to whether any more data is added. The user may be allowed to add other data in association with the time data similar to the manner discussed above with respect to managing distance transactions. Data that is added by the user may be saved in a data store.
  • the user may be prompted to determine if the stopwatch should have been stopped earlier and adjust the time accordingly. The user may then be prompted for a description. The process may then continue as described above.
  • a stopwatch should not be started, a determination may be made as to whether time is manually input. The process may then continue as described above.
  • processes for splitting transactions may include a determination as to whether the transaction is to be split by connection. If the transaction is to be split by connection, then a determination may be made as to whether the transaction is already split. If the transaction is already split, then the user may be presented with a list of connections on the transaction. A determination may be made as to whether the split amount is to be changed. If the split amount is to be changed, then the user may be prompted to add the amount. A determination may then be made as to whether the sum of the connections' amount is less than or equal to the total. If the sum of the connections' amount is less than or equal to the total, then the user may be presented with a list of connections on the transactions.
  • the user may be presented with a list of connections on the transactions.
  • the user may be presented with an error message. The user may be prompted to add a new connection. The process mav then continue as discussed above. [00211] If the transaction is not already split, then the user may be prompted to add a new connection. The process may then continue as discussed above.
  • the user may be prompted to choose a connection.
  • the user may be prompted to add a description and/or add an amount.
  • the process may then proceed to creating a collect transaction with the amount defined.
  • a determination may be made as to whether to tag another connection. If another connection should be tagged, then the user may be prompted to choose a connection and the process may continue as discussed above. If another connection should not be tagged, then the user may be presented with a list of items.
  • the transaction is not already itemized, then the user may be prompted to add a new item. A determination may then be made as to whether the amount is less than the total. If the amount is less than the total, then the process may continue to modifying the transaction to be a virtual container (parent transaction). A new sub-transaction (child) may be created equal to the item requested, and a second sub-transaction may be created with the remaining amount, inheriting all attributes from the parent. A determination may be made as to whether: an item should be renamed, the item amount should be changed, the item category should be tagged, the item should be tagged to a personal paybook, the item should be tagged to a business paybook, a connection should be tagged, or any combination thereof. The process may then continue as discussed above.
  • processes for generating expense reports may include identifying a thematic repository designated as a master of a group of thematic repositories.
  • the user of a particular transaction management account may designate the thematic repository as a master of the group of thematic repositories.
  • a user of a different transaction management account may, in some embodiments, designate the thematic repository as a master of the group of thematic repositories.
  • the transaction management module(s) may link the master thematic repository to one or more member thematic repositories.
  • one or more of the linked thematic repositories may be capable of communicating, i.e., sharing data, with one or more of the other linked thematic repositories.
  • the transaction management module(s) may receive transaction data and/or associated configuration data from a particular member thematic repository.
  • the member thematic repository's transaction data and/or associated configuration data may be routed to the master thematic repository.
  • the member thematic repository may push data to the master thematic repository, or the master thematic repository may pull data from the member thematic repository. It should be understood that data may also be routed from the master thematic repository to the member thematic repository in a similar manner.
  • the transaction management module(s) may determine whether any rule(s) and/or policy(ies) have been established. If the transaction management module(s) determine that a rule and/or policy has been established, then the transaction management module(s) and/or the TDC unit may check each data item received against the rule and/or policy.
  • the transaction management module(s) and/or the TDC unit may determine whether each data item violate the rule and/or policy. If it is determined that a particular data item does not violate any rule and/or policy, then the particular data item may be flagged as "compliant" (or the like) and stored. If, on the other hand, it is determined that a particular data item does not violates at least one rule and/or policy, then the particular data item may be flagged as "non-compliant" (or the like) and stored. The process may continue to checking whether there are data items that remain to be checked against the rule and/or policy. If there are data items that remain to be checked against the rule and/or policy, then the process may continue as discussed above until no data remains to be checked.
  • the transaction management module(s) may determine whether any reports have been requested. If so, the transaction management module may generate a report comprising one or more received data items.
  • the report may be generated automatically based at least in part on tags associated with the data items.
  • a business entity may manage business transactions via one or more thematic repositories that are shared with employees. Employees may associate business expenses/transactions with the thematic repositories.
  • the transaction management module(s) may pull the transaction data from the various business transactions to build an expense report.
  • a user may incur an expense on a personal account that is reimbursable by the user's employer.
  • the user may associate this transaction with the employer (e.g., by associating the transaction with a thematic repository shared between the employer and the user).
  • a reimbursable monetary value of the transaction may be indicated as a "Collect” transaction.
  • the transaction management module may automatically cancel the "Collect” transaction and apply the monetary value to an "Expense” transaction. This may allow the user to more accurately track personal budgets, as the reimbursable amount, once reimbursed, may no longer be indicated as a personal expense.
  • methods disclosed herein include, receiving, under control of one or more processors, information associated with a financial transaction.
  • the receiving information associated with the financial transaction may include receiving bank statement information.
  • the receiving information associated with the financial transaction may include receiving purchase receipt information.
  • the methods may include determining, based on the information associated with the financial transaction, that the financial transaction is associated with a first theme and a second theme.
  • At least a portion of the information associated with the financial transaction may be designated to a first repository.
  • the first repository may be configured to provide an aggregation of information associated with a plurality of financial transactions that are individually determined to be associated with the first theme.
  • At least a portion of the information associated with the financial transaction may be designated to the first repository automatically.
  • at least a portion of the information associated with the financial transaction may be designated to the first repository automatically based at least in part on one or more predetermined rules. Additionally or alternatively, at least a portion of the information associated with the financial transaction may be designated to the first repository manually.
  • At least a portion of the information associated with the financial transaction may be designated to a second repository.
  • the second repository may be configured to provide an aggregation of information associated with a plurality of financial transactions that are individually determined to be associated with the second theme.
  • At least a portion of the information associated with the financial transaction may be designated to the second repository automatically.
  • at least a portion of the information associated with the financial transaction may be designated to the second repository automatically based at least in part on one or more predetermined rules. Additionally or alternatively, at least a portion of the information associated with the financial transaction may be designated to the second repository manually.
  • At least a portion of the information associated with the financial transaction may be designated to the first repository automatically and at least a portion of the information associated with the financial transaction may be designated to the second repository manually, or vice-versa.
  • an indication that the financial transaction is associated with the first theme and the second theme may be provided.
  • the methods may include determining, based on the information associated with the financial transaction, that the financial transaction is associated with a financial account, and, in response to a request related to the financial transaction, providing at least an indication that the financial transaction is associated with the first repository, the second repository, and the financial account.
  • the financial account may be a bank account. Additionally or alternatively, the financial account may be a cash account.
  • the methods may include, in response to receiving a request from an entity to share the first repository with one or more other entities, allowing the one or more other entities access to at least a portion of the information associated with the first repository.
  • methods disclosed herein include identifying, based on the information associated with the financial transaction, at least one monetary value.
  • the methods may include determining whether the at least one monetary value is associated with an expenditure by a plurality of entities.
  • the at least one monetary value may be apportioned such that individual ones of the plurality of entities are associated with an apportioned monetary value.
  • the methods may include determining, based at least in part on at least one apportioned monetary value, that a first entity owes an owed monetary value to a second entity.
  • An indication may be provided to at least one of the first entity or the second entity that the first entity owes the owed monetary value to the second entity.
  • At least a portion of the owed monetary value may be transferred to the second entity.
  • the first entity may transfer at least a portion of the owed monetary value to the second entity.
  • a third entity benefactor of the first entity may transfer at least a portion of the owed monetary value to the second entity.
  • the owed monetary value may be updated to an updated owed monetary value.
  • the updated monetary value may be a difference between the owed monetary value and the at least a portion of the owed monetary value transferred to the second entity.
  • An indication may be provided to at least one of the first entity or the second entity that the first entity owes the updated monetary value to the second entity.
  • the first repository may be configured to provide an aggregation of information associated with a plurality of personal financial transactions that are individually determined to be associated with the first theme.
  • the second repository may be configured to provide an aggregation of information associated with a plurality of business financial transactions that are individually determined to be associated with the second theme.
  • At least one of the first repository or the second repository may be shared between an individual user account and a business entity account such that information designated to the respective at least one of the first repository or the second repository by a user of the individual user account is provided to the business entity account.
  • the business entity account may be associated with a business entity and the individual user account may be associated with an employee of the business entity.
  • the present disclosure includes one or more computer- readable media having computer-readable instructions therein that, when executed by one or more processors, cause the one or more processors to perform acts.
  • the acts may include receiving data associated with at least one financial transaction.
  • receiving the data associated with the at least one financial transaction may include receiving an input of one or more electronic files associated with at least one bank statement, and extracting data from the one or more electronic files associated with the at least one bank statement.
  • receiving the data associated with the at least one financial transaction may include receiving an input of one or more electronic files associated with at least one purchase receipt, and extracting data from the one or more electronic files associated with the at least one bank statement.
  • a determination may be made as to whether the individual electronic file matches one or more predefined templates.
  • data may be extracted from the individual electronic file in accordance with a matching predefined template.
  • At least a subset of the data may be associated with at least one thematic repository of a plurality of thematic repositories.
  • An individual thematic repository of the plurality of thematic repositories may, for example, be configured to aggregate data from a plurality of financial transactions that are individually determined to be associated with a theme of the individual thematic repository.
  • a user interface may be generated. The user interface may provide at least an indication that the at least a subset of the data is associated with the at least one thematic repository of the plurality of thematic repositories.
  • associating the at least a subset of the data with the at least one thematic repository of the plurality of thematic repositories may include automatically categorizing, based at least in part on a comparison of the extracted data to one or more predefined categorization rules, at least a subset of the extracted data into at least a first thematic repository of the plurality of thematic repositories.
  • associating the at least a subset of the data with the at least one thematic repository of the plurality of thematic repositories may include receiving a manual categorization of the at least a subset of the extracted data into at least a second thematic repository of the plurality of thematic repositories.
  • At least one thematic repository of the plurality of thematic repositories may be published such that at least a subset of data aggregated by the at least one thematic repository is accessible to multiple entities via one or more user accounts, the one or more user accounts being configured to provide thematic repository functionality.
  • Certain implementations disclosed herein include systems having one or more processors, memory, and a thematic repository module maintained in the memory and executed on the one or more processors to perform acts.
  • the acts may include receiving information associated with a transaction. Based on the information associated with the transaction, it may be determined that the transaction is associated with at least one thematic repository.
  • the at least one thematic repository of the plurality of thematic repositories may, for example, be configured to aggregate information from a plurality of financial transactions that are individually determined to be associated with a theme of the at least one thematic repository.
  • at least an indication that the transaction is associated with the at least one thematic repository may be provided.
  • the at least one thematic repository of the plurality of thematic repositories may include a first thematic repository configured to aggregate information from a plurality of financial transactions that are individually determined to be associated with a same financial institution account (e.g., a debit card account, a credit card account, a checking account, a savings account, an investment account, etc.). Additionally or alternatively, the at least one thematic repository of the plurality of thematic repositories may include a second thematic repository configured to aggregate information from a plurality of transactions that are individually determined to be associated with a same user-defined theme.
  • a first thematic repository configured to aggregate information from a plurality of financial transactions that are individually determined to be associated with a same financial institution account (e.g., a debit card account, a credit card account, a checking account, a savings account, an investment account, etc.).
  • the at least one thematic repository of the plurality of thematic repositories may include a second thematic repository configured to aggregate information from a plurality of transactions that
  • the at least one thematic repository may include a first thematic repository configured to aggregate data from a plurality of financial transacations that are individually determined to be associated with a first theme.
  • the first thematic repository may be associated with a second thematic repository.
  • the second thematic repository may be configured to aggregate data from a plurality of financial transactions that are individually determined to be associated with a second theme.
  • the systems may further include a user interface module maintained in the memory and executed on the one or more processors to perform acts.
  • the acts may include receiving a request related to the at least one thematic repository of the plurality of thematic repositories, and, in response to receiving the request related to the at least one thematic repository of the plurality of thematic repositories, causing to be displayed an aggregation of information from a plurality of transactions that are individually determined to be associated with the at least one thematic repository of the plurality of thematic repositories.
  • the acts may include generating a user interface that allows a user to view, manipulate, or both view and manipulate, at least a portion of the aggregation of information at varying levels of granularity.
  • allowing a user to manipulate the at least a portion of the aggregation of information includes allowing a first user to associate a monetary value with a second user.
  • the second user may be an employer of the first user, and the monetary value may be designated a business expense such that the employer is capable of generating an expense report based at least in part on the monetary value.
  • allowing a user to manipulate the at least a portion of the aggregation of information includes allowing a first user to split a monetary value such that at least a portion of the monetary value is associated with a second user.
  • allowing a user to manipulate the at least a portion of the aggregation of information includes allowing the user to add electronic documents that are determined to be associated with the aggregation of information.
  • the at least one thematic repository of the plurality of thematic repositories may include: a first thematic repository configured to aggregate information from a plurality of financial transactions that are individually determined to be associated with a same bank account, a second thematic repository configured to aggregate information from a plurality of transactions that are individually determined to be associated with a same system-defined theme, and a third thematic repository configured to aggregate information from a plurality of transactions that are individually determined to be associated with a same user-defined theme.

Abstract

Some implementations include techniques for utilizing thematic repositories for transaction management. The techniques may include receiving data associated with at least one transaction, and associating at least a subset of the data with at least one thematic repository of a plurality of thematic repositories. An individual thematic repository of the plurality of thematic repositories may be configured to aggregate data from a plurality of transactions that are individually determined to be associated with a theme of the individual thematic repository.

Description

THEMATIC REPOSITORIES FOR TRANSACTION MANAGEMENT
RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional Patent Application No. 61/775,485, filed on March 9, 2013, the entire contents of which are incorporated herein by reference. This application also claims priority to U.S. Provisional Patent Application No. 61/775,869, filed on March 11, 2013, the entire contents of which are incorporated herein by reference.
BACKGROUND
[0002] The process of recording and managing personal and/or business transactions that have a financial aspect may be complicated, protracted and monotonous. Tracking the various cash disbursements, charges, and itemized receipts for a household or produced during the course of a business trip may require a significant amount of time. This does not include the time and expense involved in actually entering the data in the first place. Additionally, accurately tracking and segregating an employee's time between different projects is often difficult. BRIEF DESCRIPTION OF THE DRAWINGS
[0003] The detailed description is set forth with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items or features.
[0004] FIG. 1 illustrates an example operating environment in which the techniques disclosed herein may be implemented, in accordance with certain embodiments.
[0005] FIG. 2 illustrates further details of one or more example computing device(s) of FIG. 1, in accordance with certain embodiments.
[0006] FIG. 3 illustrates an example user interface, in accordance with certain embodiments.
[0007] FIG. 4 illustrates another example user interface, in accordance with certain embodiments.
[0008] FIG. 5 illustrates yet another example user interface, in accordance with certain embodiments. [0009] FIG. 6 illustrates an example process to create a thematic repository, in accordance with certain embodiments.
[0010] FIG. 7 illustrates an example user interface for creating a thematic repository, in accordance with certain embodiments.
[0011] FIG. 8 illustrates an example process to receive transaction data, in accordance with certain embodiments.
[0012] FIG. 9 illustrates an example process to extract transaction information from a user-selected file, in accordance with certain embodiments.
[0013] FIG. 10 illustrates an example process to designate transaction information to thematic repositories, in accordance with certain embodiments.
[0014] FIG. 11 illustrates an example process to share a thematic repository between multiple entities, in accordance with certain embodiments.
[0015] FIG. 12 illustrates an example process to apportion a monetary value between multiple entities, in accordance with certain embodiments.
DETAILED DESCRIPTION
[0016] The process of recording and managing personal and business transactions that have a financial aspect is often complicated, protracted and monotonous. Tracking the various cash disbursements, charges, and itemized receipts for a household or produced during the course of a business trip typically requires a significant amount of time. This does not include the time and expense involved in actually entering the data in the first place. Additionally, accurately tracking and segregating an employee's time between different projects is often difficult.
[0017] For companies, tracking transactions such as travel and sales expenses is a cumbersome exercise for both the company as well as their employees, and there is often a duplicate effect in tracking those transactions, importing them into suitable databases, and auditing them for accuracy and compliance with company policies and government regulations. For example, in the U.S., today's business traveler typically averages four trips per month, 25 receipts per month, and spends between $1,200 and $1,500 per trip.
[0018] As another example, companies in the construction industry often have several ongoing projects and employ hourly workers who may work on more than one project at a time. The companies also often purchase materials in "bulk" that they then use on the various projects. To comply with lender requirements and audits regarding construction financing and draw requests, the construction companies and lenders may spend an inordinate amount of time tracking, segregating and confirming the accuracy of expenses and man-hours charged to a particular project.
[0019] Organizing, timely recording and then verifying the accuracy of expenses for business travelers and other employees, while necessary for U.S. GAAP accounting, Sarbanes-Oxley compliance, lender requirements and other business reasons, often involves tiresome, repetitive data entry and data checking that waste man-hours, reduce employee productivity and cut into company profit. As a result, individuals and companies continue to complain about the merits of expense reporting, citing lack of intuition and insufficient mobile platforms - not to mention being time-consuming and requiring the entering of redundant information. For the more than 6 million U.S. small and medium businesses (SMBs) each employing between one and 500 people— a business sector which contributed substantially to the $252 billion in total U.S. spending on business travel in 2011— the need for intelligent expense tracking and personal transaction management tools continue to manifest strongly.
[0020] Individuals or households dealing with their personal finances face similar issues; albeit typically on a smaller scale. The realm of personal finance has been augmented thanks to the Internet, where pen and paper have been replaced with convenient, secure, and automated ways to stay on top of expenses. The online banking industry is the result of consumers' desire to manage their finances either on a home computer or a mobile device. Originally, online banking was exclusively provided by banks, which offered online portals for account management, payments, and more.
[0021] Recently, third-party solutions have emerged. The number of financial management websites and other online personal finance management (PFM) solutions have also exploded, with some claiming to help the individual or business track expenses by charts and graphs while others simply provide a semi-automated way to manage expenses. These solutions may be so linear in nature that little real benefit may be afforded to a user on a grand scale. Furthermore, complicated user interfaces aggravate users who are already seeking an easier solution to the common and frustrating practice of managing personal finances.
[0022] In 2011, the American Banking Association reported that, among all consumers, 20% still prefer visiting a bank to conduct a bank transaction or to manage their accounts even if they know that the online solution exists. The primary reason is a lack of usability or other technology/security concerns. Thus, existing solutions have not been fully effective at achieving the convenience and reliability that consumers are looking for in a transaction management tool. [0023] Embodiments of the present disclosure are generally directed to techniques for using thematic repositories of a transaction management platform to facilitate the management of transaction activity, such as automating financial tasks involving receipt tracking, time tracking, expense reporting, and budgeting. The transaction management platform may be used, for example, to manage personal transactions, business transactions, or both. The financial transaction management platform may also include social features that enable collaboration and transaction sharing among entities, such as business and individual subscribers, who track and record their transactions.
[0024] Certain aspects of this disclosure are discussed with reference to an Example Use Scenario(s) section below. The Example Use Scenario(s) section provides an exemplary illustration of techniques involved in the utilization of various aspects of a transaction management platform, including thematic repositories, in accordance with certain embodiments.
[0025] This brief introduction is provided for the reader's convenience and is not intended to limit the scope of the claims. Furthermore, the techniques described in detail below may be implemented in a number of ways and in a number of contexts. One example implementation and context is provided with reference to the following figures, as described below in more detail. It is to be appreciated, however, that the following implementation and context is merely one illustrative, non-limiting example.
EXAMPLE USE SCENARIO(S)
[0026] For the purposes of illustrating the utilization of various aspects of a transaction management in a collaborative manner, consider the following example.
[0027] A business traveler (User A) who works for Employer X is going on a business trip from Austin, Texas to Monterrey, Mexico to give a sales presentation. User A also works for Employer X on a project in Austin, Texas. To be reimbursed for business-related expenses regarding the Monterrey Trip, User A is expected to submit receipts or similar documentation showing reimbursable business-related expenses. User A is traveling with a companion (User B) as far as Laredo, Texas where User B will stop and visit family. That is, User B may not continue on to Monterrey, Mexico.
[0028] Employer X also employs an Austin-based computer consultant (User C) on an hourly basis who splits time between the Austin Project and a project in Hutto, Texas (the "Hutto Project").
[0029] Employer X has a company checking account at Bank Y that is used to issue checks for the Austin Proiect and the Hutto Project. The Austin Project is financed by a lender (Bank Z) that requires Employer X to submit financial information and draw requests regarding the Austin Project on a weekly basis. Employer X is also required to maintain separate accounts for the Austin Project and Hutto Project, and to accurately segregate time and expenses between these Projects. For this reason, Employer X instructs User A and User C to report their time and expenses working on the Austin Project on a daily basis. Employer X also instructs User C to report his time and expenses working on the Hutto Project on a daily basis.
[0030] Employer X initially uses a client device to access the transaction management application and create a transaction management account named "Employer X Account." As part of the account creation process, the employer may be assigned a transaction management account email, e.g., EmployerX@tmaexample.com.
[0031] As an example, after creating the Employer X Account, Employer X may then log into the transaction management account by providing a username and a password and create a thematic repository named "Monterrey Trip Expenses" to manage transaction activity relating to expenses to be incurred in connection with User A's Monterrey trip. Employer X may also create thematic repositories named "Austin Project" and "Hutto Project" to manage transaction activity relating to these projects. As used herein, a thematic repository may also be referred to as a "paybook."
[0032] Employer X also adds User A and User C to the list of employees to be invited to collaborate with Employer X regarding thematic repositories. Employer can add, view and/or select employees or other individuals for collaboration in using the transaction management platform in various embodiments.
[0033] By using the features provided by a social module of the transaction management platform, Employer X may invite User A to access the transaction management application and join the Monterrey Trip Expenses thematic repository as a member so that both Employer X and User A can track expenses related to the Monterrey trip. Employer X may also send an email invitation to User A to join the Austin Project thematic repository as a member. Additionally, Employer X may send an email invitation to User C to access the transaction management application in order to join the Austin Project thematic repository as a member and to join the Hutto Project thematic repository as a member.
[0034] Employer X may set permissions that allow only transaction data in the Master Austin Project thematic repository on the transaction management platform (TMP) server regarding User A to be shared with User A and that allow only transaction data in the Master Austin Project and Hutto Project thematic repositories on the TMP server regarding User C to be shared with User C. [0035] Employer X may also send an email invitation to Bank Z to access the transaction management application and join the Austin Project thematic repository. Employer X may set permissions that allow only particular transaction data in the Master Austin Project thematic repository on the TMP server to be shared with Bank Z that may be necessary for Bank Z to process draw requests or otherwise comply with lending requirements.
[0036] Because the Monterrey Trip is expected to last several days, Employer X has provided a cash advance of $500.00 to User A. Employer X may create a "User A Collect Account" under Monetary Receivables Accounts for $500.00. Employer X may tag the $500.00 advance with the applicable "GL Code" to ensure that his bookkeeping is accurate. Employer X may also create a User A Monterrey Expenses Account under Monetary Debit Accounts to keep track of business expenses that User A submits.
[0037] User A may receive the invitations from Employer X and may accept the invitations. User A may use a client device to access the transaction management application and create a transaction management account named "User A Account." As part of the creation process, User A may be assigned a transaction management account email, e.g., UserA@tmaexample.com. User A may log into the transaction management account and join the Monterrey Trip Expenses thematic repository and the Austin Project thematic repository created by Employer X. These are business-related thematic repositories, so User A may place the thematic repositories under the "business" portion of the transaction management account.
[0038] Since User A likes to golf, he may create a thematic repository named "Golf under the "personal" portion of the transaction management account to manage golf-related transaction activity. User A may also create a personal thematic repository named "Laredo Trip" to manage travel-related transaction activity for his trip with User B to Laredo. He may add User B to his list of connections, and invite User B to join the Laredo Trip thematic repository, so that they can both track expenses related to the Laredo trip. User B may accept the invitation and join the Laredo trip thematic repository after creating his own user account.
[0039] Continuing in the personal portion of the transaction management account, User A may set up his accounts at Bank V and Bank W for tracking, and provide Bank V his UserA@tmaexample.com email address so the account information from Bank V may be sent directly to the transaction management platform (TMP) server for processing and input into User A's transaction management account. Bank W may not offer this option and, instead, may provide bank statements directly to User A by email in portable document format (PDF). It will be understood that bank statements or other financial transaction data may be presented to the user in a variety of formats other than PDF, and processed in the transaction management account.
[0040] User A may also enter data regarding the amount of cash he has on-hand and his credit card account information. User A may remember that he still owes $30.00 to User B for the purchase of golf balls earlier in the week and may record this data by creating a User B Debit Account in Monetary Debit Accounts. This account may now displayed in the monetary debit area of the dashboard. User A may also tag the transaction under the golf thematic repository. User A may notice by viewing the dashboard that a monetary debit account already is in place regarding the cash advance of $500.00 from Employer X.
[0041] On the way to Laredo, User A and User B may stop at a gas station to refuel. They may also purchase a snack and golf tees for User A and sunglasses for User B. User A may pay because he still owes $30.00 to User B for the golf balls. The gas station cashier may give a receipt to User A that itemizes the purchased items of gas, User A's snack and golf tees, and User B's sunglasses.
[0042] Using the transaction management platform on a mobile device with a digital camera, User A may take a photo of the receipt and use the photo input feature provided by the transaction input module of the transaction management platform.
[0043] After the transaction input module determines whether the general format of the digital image is acceptable, the transaction data may be routed for quality control to quality control system (QCS) through a network to verify the accuracy and proper format of transaction data and perform other quality control measures.
[0044] Using the features provided by the transaction configuration module of the transaction management platform, User A may tag the digital representation of the receipt for entry into the "Monterrey Trip Expenses" thematic repository, the "Laredo Trip" thematic repository, and the "Golf thematic repository.
[0045] As part of the configuration, User A may configure the transaction data from the digital representation of the receipt by: (1) splitting the gas purchase equally between User A and User B; (2) tagging the snack purchase to the "Monterrey Trip Expenses" thematic repository and "Laredo Trip" thematic repository; and (3) further tagging the snack purchase to the Traveling Category and categorizing it as "food." User A may also tag the sunglasses purchase as being assigned to User B in the "Laredo Trip" thematic repository.
[0046] The transaction data in User A's member "Laredo Trip" thematic repository may be routed to the Master "Laredo Trip" thematic repository on the TMP server. User B, as a member of the "Laredo Trip" thematic repository group, may receive detailed information regarding the expenses attributed to each of User A and User B on the Laredo Trip via User B's transaction management account, thereby providing a convenient way of determining the age-old issue of "who owes who what?"
[0047] Since User B owes money to User A for the sunglasses purchase and gas purchase, and this amount exceeds the amount that User A owed to User B for golf balls, a User B "collect" account may be created in User A's transaction management account and the amount of the difference may be displayed on User A's dashboard.
[0048] As part of the configuration, User A may configure the golf tees transaction data to be identified in the "Golf thematic repository and "Laredo Trip" thematic repository. User A may select the "Golf thematic repository for display on the Golf account dashboard, and request to view a report of transactions within the last two months. User A may be provided with data graphics that show him the details regarding money spent with respect to User A's golf hobby. User A may see that money was spent on golf balls, golf grips, gas, snacks, green fees, lodging, and their respective percentages of the total of expenditures within the last two months.
[0049] User A may further configure the transaction data from the receipt to: (1) create a copy of the image of the receipt; (2) "redact" the golf tees transaction data and sunglasses transaction data since these are not business expenses; (3) authenticate the copy of the digital image; and (4) tag the snack and gas purchases to the Monterrey Trip Repository and assign each to Employer X as reimbursable business expenses.
[0050] The transaction data in User A's member "Monterrey Trip Expenses" thematic repository, along with the redacted and digitally signed copy of the image of the receipt may be routed to the Master "Monterrey Trip Expenses" thematic repository on the transaction management platform (TMP) server. Employer X, as a member of the "Monterrey Trip Expenses" thematic repository group, may be provided with substantially immediate detailed information regarding the business expenses incurred by User A.
[0051] After dropping off User B in Laredo, User A may continue to Monterrey, Mexico. Upon arriving at an office to make a sales presentation, User A may be required to pay cash for parking at a self-serve lot that does not provide receipts. The sign at the lot may display the hourly rate and name of the lot. Using the transaction management platform on a mobile device with a digital camera, User A may take a photo of the sign, showing the name of the self-serve lot and the rate charged when he enters the lot. In this case, the transaction data may be the image itself and associated information such as geocoding information. This transaction data is collectively referred to in this particular example as the "parking expense transaction data." When User A leaves the lot, User A may take another photo of the sign. [0052] User A may use the currency conversion feature of the transaction management platform to convert Mexican pesos into U.S. dollars and may configure the parking expense transaction data to: (1) create copies of the digital images; (2) configure the images to superimpose a label that identifies the sales call and amount charged for parking in U.S. dollars; and (3) tag the parking expense to the Monterrey Trip Repository and assign them to Employer X as reimbursable business expenses. The parking expense transaction data in User A's member "Monterrey Trip Expense" thematic repository, along with labeled copies of the digital images may be routed to the Master "Monterrey Trip Expense" thematic repository on the TMP server. Employer X, as a member of the "Monterrey Trip Expenses" thematic repository group, may be provided with substantially immediate detailed information regarding this business expense, including geocoding information that confirms the location of the parking lot and the amount of time that User A parked in the lot.
[0053] User A may also use the transaction management platform to enter his hours spent on the Austin Project and tag this information to his member Austin Project repository. User A may also enter the mileage for his trip to Monterrey. The data may be routed to the Master Austin Project thematic repository on the TMP server.
[0054] User C, who also accepted Employer X's invitation, may enter his hours spent on each of the Austin Project and the Hutto Project in User C's respective member thematic repositories and such information may be routed to the Master Austin Project and Master Hutto Project thematic repositories on the TMP server. Employer X may see, in a substantially real-time manner, each of User A's and User C's expenses and time, and may generate one or more reports regarding the projects.
[0055] Further, if User A mistakenly tags the golf tees transaction data as a reimbursable business expense and the data is routed to the Master "Monterrey Business Expenses" thematic repository, the transaction management platform may flag the golf tees transaction data and allow Employer X to filter it, whether for viewing purposes or for reporting purposes.
[0056] Employer X may designate its company bank account at Bank Y for management of transaction activity using the transaction management platform. Employer X may use the "drag and drop input" feature of the transaction management platform to input the latest account statement that was sent by Bank Y in PDF format.
[0057] After the transaction input module determines whether the format of the digital image is acceptable, the transaction data may be routed for quality control (QC) to a quality control system (QCS) through a network to verify the accuracy and proper format of transaction data and perform other quality control measures. [0058] Employer X may configure the Bank Y transaction data by tagging information relating to the "Austin Project" to the Austin thematic repository and tagging information relating to the "Hutto Project" to the Hutto thematic repository. The Austin Project transaction data in Employer X's member "Austin Project" thematic repository (which may include the shared transaction data from User A, User C, and Bank Y regarding the Austin Project) may be routed to the Master "Austin Project" thematic repository on TMP server; and Bank Z, as a member of the "Austin Project" thematic repository group, may be provided with detailed information regarding the "Austin Project," according to the permissions established by Employer X.
[0059] If Employer X mistakenly tags a non-reimbursable expense (e.g., an expense that, according to lender policy, cannot be reimbursed) to the "Austin Project" thematic repository, then the transaction management platform flags the non-reimbursable expense and allows Bank Z to filter it, whether for viewing purposes or for reporting purposes.
[0060] After the trip, User A wants to collect the money owed by User B for the sunglasses and User B's share of fuel purchased on the Laredo Trip. User A views the dashboard and notices that the User B Collect Account only shows $20.00 even though User A knows the sunglasses and one-half of the fuel expense was $50.00. By clicking on the User B collect account, User A reviews the transaction data detail relating to the amounts owed by User B for the Laredo Trip and also the credit applied from the amount owed by User A to User B for the golf balls. User A sends User B a reminder notification regarding the $20 owed to User A.
[0061] User B is able to quickly confirm the amount owed by viewing the dashboard for his transaction management account and clicking on the Owe Account for User A which displays the transaction data detail relating to the amounts owed by User B for the Laredo Trip and also the credit applied from the amount owed by User A to User B for the golf balls.
EXAMPLE OPERATING ENVIRONMENT
[0062] FIG. 1 illustrates an example operating environment 100 in which techniques described herein may be implemented. The operating environment 100 may include one or more client device(s) 102(1)-102(N), which may be coupled to one or more server(s) 106(1)- 106(N), across one or more network(s) 104(1)-104(N). For simplicity of reference, components throughout this disclosure may be referred to in the singular form and in connection with a single generalized reference numeral. For example, the one or more client device(s) 102(1)-102(N) (i.e., the plural form) may be referred to as a client device 102 (i.e., the singular form). Nonetheless, it should be understood that use of the singular form may include the plural form in certain implementations.
[0063] The client device 102, the server 106, or both, may include various types of computing devices. For example, the client device 102, the server 106, or both, may be implemented as a laptop computer, a desktop computer, a server, a smart phone, an electronic reader device, a mobile handset, a personal digital assistant (PDA), a portable navigation device, a portable gaming device, a tablet computer, a watch, a portable media player, a television, a set-top box, a computer system in a car, an appliance, a camera, a robot, a hologram system, a home -based computer system (e.g., intercom system, home media system, etc.), a projector, an automated teller machine (ATM), a pair of glasses with computing capabilities, and so on.
[0064] In certain implementations, a user may use the client device 102 to manage transaction activity. For example, the client device 102, the server 106, or both, may be configured with, or otherwise include, one or more transaction management module 108, which may provide the functionality for carrying out the techniques described in this disclosure. For example, the transaction management module(s) 108 may include executable computer code that can be executed by one or more processors. In some embodiments, the transaction management module(s) 108 may include computer code which, when executed by one or more processors, allows a user of the client device 102 to manage transaction activity. The computer code of the transaction management module(s) 108 may be stored locally within the client device 102, or may be provided across the network 104, for example, by the transaction management module(s) of the server 106.
[0065] The operating environment 100 may also include one or more storage devices 110(1)-110(N). The storage device(s) 110 may store, for example, transaction data. The client device 102, the server 106, or both, may be coupled to the storage device(s) 110 across the network 104. Additionally or alternatively, the storage device(s) 110 may reside locally with respect to the client device 102, the server 106, or both. In certain implementations, the storage device(s) 110 may include one or more computer readable storage media. Exemplary computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Computer storage media may include, but is not limited to, phase change memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. As defined herein, computer storage media does not include communication media, such as modulated data signals and carrier waves. As such, computer storage media includes non-transitory media.
[0066] In some embodiments, the client device 102, the server 106, or both, may be capable of accessing transaction information from one or more bank/financial institution servers (not shown). It should be understood that bank/financial institution servers include servers associated with brokerage companies, credit card companies, financing companies, and the like. The client device 102, the server 106, or both, may provide transaction information received from the bank/financial institution server such that a user may be able to manage transactions corresponding to the transaction information received from the bank/financial institution server. The bank/financial institution server may comprise various components similar to those of the client device 102, the server 106, or both. Thus, it should be understood that any disclosure provided herein with respect to the client 102, the server 106, or both, may also apply to bank/financial institution server.
[0067] In some implementations, the operating environment 100 may include a quality control (QC) device or system (not shown). The client device 102, the server 106, or both, may be coupled to the QC device across the network 104. Additionally or alternatively, the QC device may reside locally with respect to the client device 102, the server 106, or both. The QC device may be configured to verify the accuracy and proper format of transaction data received from the client device 102, the server 106, or both, as a result of input by a user, or to perform other quality control measures regarding such transaction data. In some embodiments, the QC device may include or access one or more databases storing templates or other data for verifying the proper format of different types of transaction data. For example, the format of transaction data received from the client device 102, the server 106, or both, may be compared with information stored in the one or more databases. In some embodiments, the QC device is capable of accessing templates, format data, or both, from a bank/financial institution server.
[0068] In some cases, the QC device may perform quality control measures automatically. Additionally or alternatively, at least some of the quality control measures performed by the QC device may not be automatic (i.e., a human operator may be involved). The QC device may comprise various components similar to those of the client device 102, the server 106, or both. Thus, it should be understood that various disclosures provided herein with respect to the client device 102, the server 106, or both, may also apply to QC device.
[0069] In some implementations, the operating environment 100 may include a transaction data compliance (TDC) unit (not shown). The client device 102, the server 106, or both, may be coupled to the TDC unit across the network 104. Additionally or alternatively, the TDC unit may reside locally with respect to the client device 102, the server 106, or both. The TDC unit may be used to verify that expenses submitted to a company for reimbursement are, in fact, reimbursable under the company's policies. The TDC unit may include one or more databases that store information corresponding to reimbursable expenses. The TDC unit may compare transaction data corresponding to expenses submitted by the user to the acceptable standards for reimbursable expenses stored in the database(s). Thus, expenses contrary to company policies may be flagged for non-compliance.
[0070] The TDC unit may be automatic, or may include operator involvement. The TDC unit may comprise various components similar to those of the client device 102, the server 106, or both. Thus, it should be understood that various disclosures provided herein with respect to the client device 102, the server 106, or both, may also apply to the TDC unit.
[0071] Those of ordinary skill in the art will appreciate that the hardware components and various functional modules depicted in FIG. 1 and elsewhere may vary. The illustrative components are not intended to be exhaustive, but rather are representative to highlight components that are utilized to implement the subject matter disclosed in the present application. For example, other devices/components may be used in addition to or in place of the hardware depicted. In addition, the various components illustrated in storage and memory may be alternatively located in any storage or memory across the network 104. The depicted example is not meant to imply architectural or other limitations with respect to the subject matter of this disclosure.
EXAMPLE DEVICE(S)
[0072] FIG. 2 illustrates further details of one or more example computing device(s) 200 (e.g., the client device 102, the server 106, or both) of FIG. 1. The device 200 may include one or more processors 202, memory 204, one or more operating systems 206, one or more displays 218, one or more input/output (I/O) components 220, one or more network interfaces 222, or any combination thereof.
[0073] The memory 204 may include one or a combination of computer readable storage media. Computer storage media includes volatile and non-volatile, removable and non- removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, phase change memory (PRAM), static random- access memory (SRAM), dynamic random-access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read- only memory (EEPROM), flash memory or other memory technology, compact disk readonly memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. As defined herein, computer storage media does not include communication media, such as modulated data signals and carrier waves. As such, computer storage media includes non-transitory media.
[0074] The memory 204 may include an operating system 206. The operating system 206 may be any platform that manages the execution of computer code and manages hardware resources. The memory 204 may also include one or more applications, functional modules, or both. The term "module" is intended to represent example divisions of the software for purposes of discussion, and is not intended to represent any type of requirement or required method, manner or necessary organization. Accordingly, while various "modules" are discussed, their functionality, similar functionality, or both, could be arranged differently (e.g., combined into a fewer number of modules, broken into a larger number of modules, etc.). The modules may comprise computer instructions/code that may be stored in the memory 204 and may be executable by the one or more processors 202.
[0075] For example, the memory 204 may include transaction management module(s) 108. The transaction management module(s) 108 may comprise executable computer code which, when executed by the processor 202, allows a user to manage transaction activity. Computer program code for the transaction module(s) may be: stored locally within the device 200, provided across network 104, or both.
[0076] As will be discussed in further detail below, the transaction management module(s) 108 may include a user interface module 208, a thematic repository module 210, a transaction input module 212, a transaction configuration module 214, a social module 216, or any combination thereof. In certain implementations, the transaction management module(s) 108 may generally receive input from a user, provide output to a user, or both. For example, the device 200 may utilize the functionality provided by the transaction management module(s) 108 to receive transaction-related information input, provide transaction-related information output, or both, to facilitate transaction management. The input may include audio or speech, text, touch, or gesture input received e.g. via a sensor of the device 200.
[0077] The I/O components 220 may be configured to allow a user to interface with the device 200 via one or more I/O devices. The I/O components 220 may provide an interface for such devices as a display 218, a keyboard (not shown), a mouse (not shown), a camera (not shown), an optical reader (not shown), a touchpad (not shown), or any combination thereof. The display 218 may include, for example, a liquid crystal display (LCD), a plasma display, a cathode ray tube (CRT) monitor, a touch screen, any other kind of output display mechanism, or any combination thereof.
EXAMPLE TRANSACTION MANAGEMENT MODULE(S)
[0078] As noted above, the transaction management module(s) 108 may include a user interface module 208, a thematic repository module 210, a transaction input module 212, a transaction configuration module 214, a social module 216, or any combination thereof.
[0079] The user interface module 208 may cause a user interface to be provided to a user (e.g., via the display 218 of the device 200). The user interface may be used as a vehicle for operating the functionality provided by the transaction management module(s) 108, such as allowing the user to input data, receive data, view data, manipulate data, configure data, or any combination thereof. The input data may cause the transaction management module(s) 108 to perform various tasks. In certain instances, the user interface module 208 may be configured to provide a user interface that suits the particular device 200 being used by the user. For example, information may be presented to the user in a different manner when displayed on a mobile phone than when displayed on a personal computer.
[0080] In some embodiments, the user interface of the transaction management module(s) 108 may be provided to a user via a web browser [e.g., software as a service (SaaS)], via a downloadable client application, or both. In some cases, a user may create a transaction management account in order to access/utilize the services provided by the transaction management module(s) 108.
[0081] Creating the transaction management account may involve the user providing certain requested personal information (e.g., name, username and/or email address), setting a secure password, and/or verifying that the user is a human and not a machine. In certain embodiments, verifying that the user is a human and not a machine may be carried out by asking the user to drag and drop a menu item to a certain location. For example, the user may be presented with a word or an image, and the user may be asked to: recognize and select a corresponding word or image, and/or drag and drop a corresponding word or image to a certain location in the proximity of the presented word or image. Verifying that the user is a human and not a machine may also be carried out by asking the user to complete a Completely Automated Public Turing test to Tell Computers and Humans Apart (CAPTCHA), a challenge-response test requiring the user to type letters and/or digits corresponding to those presented in a distorted image. However, verifying that the user is a human and not a machine may be carried out by employing another method of attempting to prevent automated software from performing actions that degrade quality of service.
[0082] Upon establishing a transaction management account, a user may be able to log in to the transaction management account by providing a username and/or an email address and a password, or any other suitable login credential(s) suitable for securely managing access to the user's transaction management account.
[0083] Once logged in, a user may be provided with a summary view related to features provided by the transaction management module(s) 108. This summary view is also referred to herein as a "master dashboard." FIG. 3 illustrates an example user interface display of a master dashboard 300, in accordance with certain embodiments. The master dashboard may be shown in a default configuration, highlighting a set of features commonly used or desired by users. The default configuration of the master dashboard, as well as the specific features available to the user may vary depending on the status of the user who commonly logs into transaction management account. For example, the default configuration of the master dashboard 300 provided to an individual who uses the transaction management platform primarily for personal use may be different than the default configuration provided to a business owner who uses the transaction management platform primarily for business operations.
[0084] The default configuration of the master dashboard 300 and specific features provided may also vary depending on the type of user who commonly logs into transaction management account. As an illustrative example, the default configuration of the master dashboard 300 and available features for employees of a construction company may be different than the default configuration and features provided to the outside salespeople of a computer company.
[0085] Available features not fully detailed in the default configuration of master dashboard 300 may be accessed via links that provide drill-down paths to views or pages highlighting various levels of detail (i.e., providing varying levels of granularity) regarding such features. In some embodiments, the user can customize the master dashboard 300 such that the master dashboard 300 highlights the features most commonly used by that particular user. Although a certain configuration of features is illustrated in the master dashboard 300 of FIG. 3, it will be understood that the configuration is provided merely for illustrative purposes, and that the master dashboard 300, or any other aspect of the user interface, is not be limited to any particular configuration of features.
[0086] The master dashboard 300 includes an area for featuring one or more thematic repositories 302 (also referred to herein as "paybooks"). The thematic repository module 210 (FIG. 2) may provide the functional aspects related to the thematic repositories 302. A user may create a thematic repository 302 to manage transactions that have one or more attributes under a common theme (as defined by the user). The user may create each of the thematic repositories 302 to manage transaction types that correspond to the theme of the thematic repository. The name the thematic repository 302 may be descriptive of the theme associated with the thematic repository 302. In some embodiments, a thematic repository 302 may be categorized under one or more other thematic repositories 302. For example, a first thematic repository 302a may be associated with a theme related to, but more narrowly defined than, a theme associated with a second thematic repository 302b. That is, in some embodiments, a thematic repository 302a may have a parent-child relationship with another thematic repository 302b.
[0087] The master dashboard 300 may include a monetary asset area 304 for identifying money that a user has, such as in the user's cash accounts 306, bank accounts (e.g., checking accounts 308, savings accounts 310, etc.), investment account(s) 312, or any combination thereof. Bank accounts may include various types of accounts at a financial institution or brokerage house worldwide. Cash accounts can include the user's "safe," "cookie jar," "wallet," or any other repository where the user stores cash or cash equivalents.
[0088] The master dashboard 300 may include a monetary debit area 316 for identifying money that the user owes in connection with user's credit card accounts 314 and "IOU" accounts. Credit card accounts 314 include any type of debit account involving the use of a credit card, credit line or similar payment mechanism. "IOU" accounts may include amounts owed by the user to other individuals that are typically handled on an informal basis. "IOU" accounts may also include amounts owed by the user to one or more business entities/companies. For example, the user may owe an employer for an unused cash advance. The amount owed for the cash advance may be indicated in an "IOU" account.
[0089] The master dashboard 300 may include a monetary receivables area 318 for identifying money that the user is owed in connection with "Collect" accounts. "Collect" accounts may include amounts owed to the user by other individuals that are typically handled on an informal basis. "Collect" accounts may also include amounts owed to the user by one or more business entities/companies. For example, the user may be owed an amount by an employer for reimbursable expenses (e.g., money spent by the user for business purposes in connection with the employer). The amount owed to the user by the employer may be indicated in a "Collect" account.
[0090] In some embodiments, all accounts that the user sets up via the transaction management account may be listed in the master dashboard 300. In other embodiments, only select bank accounts or other accounts may be listed. For example, the user may select one or more bank accounts to list in the master dashboard 300, or the user may set a certain number of bank accounts that may be shown in accordance with a user-determined parameter. As another example, the user may set the master dashboard 300 to show the five bank accounts with the highest balances, or the user may set the master dashboard 300 to show any bank account that satisfies a balance threshold. Similarly, the user may have options regarding the listing and configuring of other accounts described herein for display on the master dashboard 300.
[0091] The master dashboard 300 may display relevant or desired information corresponding to accounts created by the user, such as, but not limited to: bank name, balance, account number, type of account (e.g., checking, savings, etc.), country in which the account is held, date of the last transaction associated with the account, or any combination thereof.
[0092] Balances for the accounts may be displayed in any currency, or in any combination of currencies desired, along with the corresponding currency symbol(s). In some embodiments, the master dashboard 300 or pages available for linking from the master dashboard 300 may contain a currency conversion feature (not shown) that allows the user to display, calculate, or both, monetary information in one or more currencies by selecting from a plurality of currencies at the applicable exchange rate. In other embodiments, the user may select the default currency when setting up a particular account.
[0093] In some embodiments, the user may click on or otherwise select a listed account or thematic repository 302 displayed in the master dashboard 300 to access additional information about the account, category or thematic repository, including detail about the transactions associated with the account, category, or thematic repository.
[0094] In some embodiments, if the user clicks on or otherwise selects the name of a particular account or thematic repository 302, the user is presented with a summary view or "account dashboard" associated with that account or thematic repository 302. FIG. 4 illustrates an example user interface display of an account dashboard 400, in accordance with certain embodiments. The account dashboard 400 may include many of the same or similar features as the master dashboard 300. [0095] In some embodiments, the user may create one or more budgets corresponding to one or more thematic repositories. For example, the user may set a limit for spending with respect to a thematic repository, and transactions associated with the thematic repository may be calculated against the limit for tracking and/or management purposes.
[0096] The master dashboard 300, the account dashboard 400, or both, may further include a "transaction display area" 402 (FIG. 4) that displays transaction-related data associated with a particular account or thematic repository 302. In some embodiments, the transaction display area 402 provides a list view of the most recent transactions associated with a particular account or thematic repository 302. For example, the transaction display area 402 may list the five most recent transactions corresponding to a particular account. Similarly, using the facts of the Example Use Scenario(s) section, the transaction display area 402 may list the ten most recent transactions taking place in connection with the Laredo Trip repository if User A selects the thematic repository "Laredo Trip." The user may have the option of customizing the transaction display area 402.
[0097] From the transaction display area 402, the user may be able to drill-down to further details of an individual transaction. FIG. 5 illustrates an example user interface display of a transaction detail 500, in accordance with certain embodiments.
[0098] Referring back to FIG. 3, the master dashboard 300 may include a data graphics/analytics area 320. In some embodiments, the data graphics area 320 may include any type(s) of data graphic(s) suitable for reporting acquired data in a manner useful or desired by the user. A non-exhaustive list of data graphics types may include pie charts, bar graphs, line graphs, pictographs, tables, or any combination thereof. It will be understood that each account dashboard 400 may have a similar data graphics area 320 that reports data associated with the particular account or thematic repository 302.
[0099] Taking the facts of the Example Use Scenario(s) section, if User A selects the thematic repository 302 "Laredo Trip," the data graphics area 320 of the account dashboard 400 might display a pie chart reporting statistics for the Laredo Trip thematic repository. The pie chart might show various child thematic repositories 302 (e.g., "Food," "Gas," and "Golf), and their respective percentages, identifying the transactions related to the Laredo Trip thematic repository 302. Each of the child thematic repositories 302 may be a part of one or more other parent thematic categories 302. For example, the descriptive child thematic repository 302 "Food" may be used to describe one or more transactions within the scope of each of the "Personal" and "Home" thematic categories 302. Similarly, the descriptive child thematic repository 302 "Food" may be used to describe one or more transactions within the scope of the "Monterrey Trip Expenses" repository. Thus, a particular transaction is not limited to an exclusive association with a single thematic repository 302.
[00100] It should be understood that the data graphics area 320 may report statistics for a variety of features within the transaction management account. In other words, the data graphics area 320 is not limited to reporting statistics for thematic repositories 302. Further, in some embodiments, data graphics may be provided by default or by user request in one or more areas other than the master dashboard 300 and the account dashboard 400 of the transaction management account.
[00101] The master dashboard 300 may include one or more menus 322. In some embodiments, the user may select a menu 322 to navigate out of the master dashboard 300 and to another section of the transaction management account. In other embodiments, selecting a menu 322 modifies at least some of the information being displayed on the master dashboard 300 of the transaction management account.
[00102] The master dashboard 300 may include a search bar 324. The user may search through transaction management account data via the search bar 324. Additionally or alternatively, the user may search and/or navigate through transaction management account data in any suitable manner, such as by using drop-down selected filters, radio button selected filters, voice commands and/or a tag cloud. It should be understood that account dashboard 400 may have a similar features that allow the user to search and/or navigate through transaction data associated with a particular account.
[00103] The master dashboard 300 may include a notification area 326. The notification area 326 may provide information to the user about transactions by a member of a shared thematic repository 302. Taking the facts of the Example Use Scenario(s) section, the notification area 326 may provide information to User A about actions taken by User B in connection with the shared Laredo Trip thematic repository. The notification area 326 may also provide information to the user about the user's thematic repositories, accounts, transactions, or any combination thereof.
[00104] The organization and placement of the areas in the master dashboard 300 of FIG. 3 and the account dashboard 400 of FIG. 4 [and aspects of the user interface(s) in general] is merely illustrative and not limited by the present disclosure, and variations in the placement, size, and shape of the areas would be readily apparent to those of ordinary skill in the art of user interface design.
[00105] The transaction input module 212 may be configured to enable the input of transaction data in a variety of ways. As an initial matter, the user may be allowed to input information for setting up various accounts, thematic repositories, connections/collaborators and the like, in order to more efficiently track financial transactions.
[00106] FIG. 6 illustrates an example process 600 to create a thematic repository, in accordance with certain embodiments. At 602, the transaction input module 212 may receive a request to create a thematic repository. The user may send or otherwise indicate a request to create a thematic repository by, for example, selecting a menu item from the master dashboard 300 or other user interface presented to the user. At 604, the transaction input module 212 may receive a selection or other input of a theme associated with the thematic repository to be created. At 606, the transaction input module 212 may receive a selection or other input of a name associated with the thematic repository to be created.
[00107] At 608, the transaction input module 212 may receive a selection or other input of a type associated with the thematic repository to be created. For example, in certain embodiments, the thematic repository may be associated with an account type, such as a bank account or a cash account. The thematic repository may also be associated with a social connection type, such as an individual or a business entity. The thematic repository may also be associated with a parent thematic repository type. For example, a thematic repository having a theme of "Paris" may be associated with a parent thematic repository having a theme of "Travel." The ability to associate a thematic repository with a type may allow a user to add a layer of classification to the thematic repository beyond the theme associated with the thematic repository. It should be understood that the aforementioned example types are non-exhaustive. That is, the user may be able to associate various other types with a thematic repository.
[00108] In some embodiments, the transaction input module 212 may also receive a selection or other input of a default currency associated with the thematic repository to be created, at 610.
[00109] At 612, the transaction input module 212 may receive a selection or other input of an image associated with the thematic repository to be created. In some instances, the image may be displayed in connection with the thematic repository. For example, referring back to FIG. 4, the image of a home 404 may be associated with a thematic repository used to manage transactions in relation to a user's home. The image may help the user identify the thematic repository and/or allow the user to customize the aesthetics of thematic repository. Thus, individual thematic repositories may be associated with their own images such that a first thematic repository may be associated with a first image while a second thematic repository may be associated with a second image, the second image being different from the first image. [00110] Upon receiving various selections or other input from the user in association with the thematic repository to be created, the transaction input module 212 may create the thematic repository in accordance with the user inputs and save received thematic repository information in a data store, at 614. FIG. 7 illustrates example user interface displays 700 for creating a thematic repository, in accordance with certain embodiments.
[00111] The transaction input module 212 may be configured to enable the creation of various financial accounts to allow the tracking of financial transaction information. The transaction input module 212 may also be configured to allow a user to input information about one or more businesses for which the user would like to manage transaction activity using the transaction management platform (e.g., via the transaction management module(s) 108). For example, the user may also be allowed to input data regarding employees that might collaborate with the user regarding certain transaction activity using the transaction management platform. The user may create multiple business accounts/profiles to manage transactions corresponding to multiple businesses. In certain instances, a transaction and/or transaction data may be associated with different business accounts/profiles. For example, the user may create a first thematic repository corresponding to a first business profile, and the user may create a second thematic repository corresponding to a second business profile. The user may associate a transaction and/or transaction data to each of the first thematic repository and the second thematic repository such that the transaction and/or transaction data is associated with the first business profile and the second business profile.
[00112] In addition to enabling input of information in setting up various features of the transaction management account, the transaction input module 212 may also be configured to enable input of transaction data that will be tracked in the transaction management account. FIG. 8 illustrates an example process to receive transaction data, in accordance with certain embodiments.
[00113] At 802, the transaction input module 212 may receive a request from a user to input transaction data. For example, the user may transmit the request via the user interface. The request may comprise providing any suitable indication that the user wants to input transaction data, such as, for example, selecting a menu item designated for initiating the input of transaction data.
[00114] The transaction data may include one or more data items related to identifying or otherwise describing transaction-related information. For example, continuing to use the facts of the Example Use Scenario(s) section, User A purchases a snack, gas and golf tees at a gas station along the way, and also purchases a pair of sunglasses for User B at the same time. Terms used to describe these items and the amount paid for the items is considered transaction data. Other possible parameters that may be considered transaction data with respect to the purchase transaction include, but are not limited to: the name of the business from which the items were purchased; the location of the business (including geocoding information); the date of purchase; the time of purchase; the method of payment; and details regarding the method of payment such as the debit or credit card used, the bank account associated with card, the name of the bank, the bank account type, and the bank account number; or any combination thereof. In connection with the purchase example provided, the transaction-related information relating to the snack is collectively referred herein as the snack transaction data; the transaction data relating to the gas is collectively referred to herein as the gas transaction data; the transaction data relating to the golf tees is collectively referred to herein as the golf tees transaction data and the transaction data relating to the sunglasses is collectively referred to herein as the sunglasses transaction data.
[00115] At 804, the transaction input module 212 may provide, via the user interface, an input vehicle for receiving transaction data. The input vehicle may be any mechanism by which the user may provide input that contains, at least in part, transaction data. The transaction data may reside alongside non-transaction data, and the transaction data may either be automatically recognized, or the transaction data may be designated as such on-the- fly or at some later time by the user.
[00116] In some embodiments, the transaction input module 212 may include or access a default library of transaction data that it may automatically recognize. Additionally or alternatively, the user may be able to define a library of transaction data that the transaction input module 212 may be able to automatically recognize.
[00117] At 806, the transaction input module 212 may receive the transaction data. At 808, the transaction input module 212 may store the received transaction data. For example, the transaction input module 212 may cause the transaction data to be stored in the storage device 110 or in the memory 204.
[00118] The transaction input module 212 may be configured to enable the designation of bank accounts and tracking of financial information relating to those accounts. In some embodiments, bank/financial institution servers of one or more of the banks servicing bank accounts that the user designated for transaction activity management may be linked to the transaction management module(s) 108 such that transaction information from the respective bank accounts is pushed or otherwise downloaded to the storage device 110, the memory 204, or the transaction input module 212 via the network 104. Transaction information push availability and frequency may vary depending on factors such as bank policy, bank location, and/or user settings. [00119] In some instances, the transaction input module 212 may receive transaction information from a bank in real-time or substantially real-time frequency, i.e., at or near the time each transaction occurs. When the transaction input module 212 receives the transaction information, the transaction input module 206 may provide the transaction information to the user via the user interface.
[00120] Additionally or alternatively, the transaction input module 212 may be configured to receive transaction information from a bank each time the bank issues the user's bank account statement. When the transaction input module 212 receives the transaction information, the transaction input module 212 may provide the transaction information to the user via the user interface.
[00121] In some embodiments, the transaction input module 206 may receive transaction information from a bank when the user manually downloads the information from a bank/financial institution server. When the transaction input module 212 receives the transaction information, the transaction input module 212 may provide the transaction information to the user via the user interface.
[00122] FIG. 9 illustrates an example process 900 to extract transaction information from a user-selected file, in accordance with certain embodiments. The user-selected file may comprise one or more files that include transaction data that the user wants to manage via the transaction management account. For example, the one or more selected files may comprise bank statements. Depending on a particular bank's policies, the bank may issue a bank statement as a password-protected file. The user may also be able to password-protect the bank statement file. If the bank statement is not recognized by the transaction input module 212 as being associated with an existing bank account (i.e., a bank account already added to the transaction management account), then the transaction input module 212 may add the bank account so that the user is able to manage transaction activity related to the bank account via the transaction management account.
[00123] At block 902, the transaction input module 212 may receive a user-selected file; for example, the transaction input module 212 may receive a bank account statement containing bank account transaction data. In certain embodiments, the user may select the file to input bank account transaction data via a drag-and-drop input feature, i.e., by dragging the file from a first location to a second location, and dropping the file at the second location. The first location may be, for example, the operating system's "desktop" or a local file manager window. The second location may be a transaction data input-designated area in the user interface of the transaction management platform. Additionally or alternatively, the user may select the file to input the bank account transaction data by browsing to the file via a dialog box provided by the transaction input module 212 as the vehicle for providing transaction data input.
[00124] In certain embodiments, the user may select a digital representation of one or more transactions to be received by the transaction input module 212. For example, the user may select a digital representation of the bank statement or certain transactions listed in the bank statement to input bank account transaction data by using a photo input feature.
[00125] At 904, the transaction input module 212 may determine whether the format of the selected file is acceptable/supported. In some embodiments, the input file is transmitted to the QC device across the network. The QC device may determine whether the format of the selected file is acceptable along with performing other quality control measures. Acceptable file formats may include any file format in which financial transaction data is electronically communicated to the user, including but not limited to portable document format (PDF).
[00126] If the file format is supported, then data may be extracted from the file, at 906. Then, at 910, the QC device may determine whether the data pattern/format of the file matches the pattern/format of a stored template in a database residing in or accessible to the QC device. For example, if User A inputs a bank statement, the QC device may determine whether the format of the bank statement matches the format of an existing template in a database to allow bank account transaction data to be properly entered and organized. That is, the transaction input module 212 may parse the file for transaction data and organize the transaction data in accordance with predetermined parameters. For example, if the user inputs a bank statement, and the QC device determines the format of the bank statement matches the format of a stored template a database, then the bank account transaction data in the bank statement may be parsed and organized according to organization and other parameters of the stored template.
[00127] In some embodiments, text that is not machine-encoded may be converted to machine-encoded text using optical character recognition (OCR) technology or the like. As discussed above, the transaction input module 212 may include or otherwise access a default library of transaction data that it may automatically recognize. Additionally or alternatively, the user may be able to define a library of transaction data that the transaction input module 212 may be able to automatically recognize.
[00128] Returning to 904, if the file format is determined to be unacceptable/not supported, then the process continues at 908, where the transaction input module 212 may prompt the user that the file is not supported.
[00129] Similarly, if the user inputs a bank statement, and the QC device, at 910, determines that the format of the bank statement does not match the format of a stored template in a database, then the user may be notified that the format of the bank statement is not recognized. User A may either manually input the bank account transaction data or wait until notified the QC device has obtained a matching template. The QC device may obtain a template of the bank statement from the bank as depicted or create a template for organizing the bank account transaction data from the bank statement input.
[00130] At 914, the transaction input module 212 may determine whether the user has selected a new file. If so, then the process 900 reverts to 902, where the transaction input module 212 may receive the new user-selected file. If the user does not try adding another file, then the process may end, at 916.
[00131] In some embodiments, the user may select a plurality of files to be received by the transaction input module 212. For example, the user may use the drag and drop input feature to drag multiple files simultaneously from a first location to a second location, and drop the files simultaneously in the second location. In other words, the user may drag-and-drop the files in parallel. However, the user may also be allowed to select multiple files in series.
[00132] In some embodiments, the user has the option of inputting data by taking a digital photo of the financial transaction data with a device having a digital camera using a "photo input feature." Using the facts of the Example Use Scenario(s) section regarding data input into the transaction input module 212, consider User A employed by Employer X. As an initial matter, User A may input data to create the Laredo Trip thematic repository. In addition to receiving financial data from banks and credit card companies and inputting and configuring the data in the transaction management platform in the various manners disclosed above, User A may also receive receipts such as the gas station receipt and similar proofs of payment while traveling to Laredo. User A may have the option of inputting data by creating a digital image of the receipt using the photo input feature and associating the transaction data with the Laredo trip thematic repository.
[00133] When a receipt is not available, the user may also have the option of using the photo input feature to take a digital photo of the item purchased or of identifying information associated with such item, such as a label or bar code. As a further example, continuing with the facts of the Example Use Scenario(s) section, User A may use the photo input feature to input the parking expense transaction data.
[00134] The user may also have the option of associating various electronic files with a thematic repository, including electronic files not directly including transaction data. For example, a user may want to use a thematic repository to manage documents and/or images that are relevant or otherwise desired to be associated to the theme of the thematic repository. For instance, the user may associate an image of a vehicle title or registration with a thematic repository designated for tracking the user's vehicle-related transactions. Hence, in addition to being able to access transaction information, the user may be able to access electronic files managed under the user's various thematic repositories.
[00135] The transaction configuration module 214 may provide for the configuring of transaction data. For example, the transaction configuration module 214 may receive a request from a user to configure the transaction data. The request may comprise providing any suitable indication that the user wants to configure transaction data, such as, for example, selecting a menu item designated for initiating the configuration of transaction data. In some instances, however, the transaction configuration module 214 may proactive ly present the user with the option to configure transaction data, or may configure transaction data according to default parameters without user request.
[00136] The transaction configuration module 214 may provide, via the user interface, a vehicle for configuring the transaction data. The user may configure transaction data by editing text or graphics displayed to the user. Further, the user may configure transaction data by selecting menu items via the user interface or in any manner suitable for transmitting configuration instructions to the transaction configuration module 214.
[00137] In some embodiments, the configuration of transaction data may generate configuration data, and the transaction configuration module 214 may associate the generated configuration data with the transaction data. The transaction configuration module 214 may store the transaction data and/or the associated configuration data. For example, the transaction data and/or the associated configuration data may be stored in the storage device 110 or in the memory 204.
[00138] In certain implementations, the transaction configuration module 214 may receive a digital representation of one or more transactions via the transaction input module 212. The digital representation may be presented to the user via the user interface displayed on the device 200. For example, the digital representation may comprise a purchase receipt that includes one or more transactions. The transaction configuration module 214 may parse the digital representation to identify one or more transactions comprising configurable transaction data. For example, continuing with the facts of the Example Use Scenario(s) section, the transaction configuration module 214 may parse the digital representation of the purchase receipt for the snack, gas, golf tees and sunglasses. The configurable transaction data may comprise information displayed to the traveler in descriptive terms "Gas," "Snack," "Golf tees," and "Sunglasses;" and corresponding values "$W," "$X," "$Y," and "$Z." It should be understood that displayed configurable transaction data in this example may also include other information such as a time/date stamp, receipt number, and identifying information relating to the vendor. The transaction data may also comprise information that is not displayed to the traveler, such as geocoding information.
[00139] Continuing with the facts of the Example Use Scenario(s) section, User A may also use the photo input feature to input the parking expense transaction data via the transaction input module 212. The transaction configuration module 214 may parse the digital representation of the photo. In this example, the configurable transaction data may comprise displayed configurable transaction data such as the image and may also comprise information that is not displayed to User A such as geocoding information associated with the digital photo.
[00140] The transaction configuration module 214 may provide, via the user interface, a vehicle for configuring the configurable transaction data within the digital representation. In some instances, the user may configure transaction data by editing text or graphics displayed to the user. Further, the user may configure transaction data by selecting menu items via the user interface. When the device 200 provides a touch screen or similar technology, the user may configure transaction data using touch screen gestures to indicate how the user wants to configure the transaction data. However, the user may configure transaction data in any manner suitable for providing configuration instructions to the transaction configuration module 214.
[00141] In some embodiments, the configuration of transaction data may generate configuration data. The transaction configuration module 214 may associate the configuration data with the transaction data.
[00142] FIG. 10 illustrates an example process 1000 to designate transaction information to thematic repositories, in accordance with certain embodiments. At 1002, the transaction management module(s) 108 may receive transaction information. For example, the transaction information may be associated with a financial transaction. Receiving information associated with a financial transaction may include receiving bank statement information. Additionally or alternatively, the receiving information associated with the financial transaction may include receiving purchase receipt information.
[00143] At 1004, the transaction management module(s) 108 may determine, based on the information associated with the financial transaction, that the financial transaction is associated with a first theme and a second theme.
[00144] At 1006, the thematic repository module 210 may designate at least a portion of the information associated with the financial transaction to a first repository. The first repository may be configured to provide an aggregation of information associated with a plurality of financial transactions that are individually determined to be associated with the first theme. At least a portion of the information associated with the financial transaction may be designated to the first repository automatically. For example, at least a portion of the information associated with the financial transaction may be designated to the first repository automatically based at least in part on one or more predetermined rules. Additionally or alternatively, at least a portion of the information associated with the financial transaction may be designated to the first repository manually.
[00145] At 1008, the thematic repository module 210 may designate at least a portion of the information associated with the financial transaction to a second repository. The second repository may be configured to provide an aggregation of information associated with a plurality of financial transactions that are individually determined to be associated with the second theme. At least a portion of the information associated with the financial transaction may be designated to the second repository automatically. For example, at least a portion of the information associated with the financial transaction may be designated to the second repository automatically based at least in part on one or more predetermined rules. Additionally or alternatively, at least a portion of the information associated with the financial transaction may be designated to the second repository manually.
[00146] In some instances, at least a portion of the information associated with the financial transaction may be designated to the first repository automatically and at least a portion of the information associated with the financial transaction may be designated to the second repository manually, or vice-versa.
[00147] At 1010, the thematic repository module 210 may receive a request related to the financial transaction. In response to a request related to the financial transaction, an indication that the financial transaction is associated with the first theme and the second theme may be provided, at 1012.
[00148] The social module 216 may enable the user to manage transaction activity socially. For example, the social module 216 may provide for the integration of one or more social networks. A social network may be provided internally such that a user of the transaction management platform may interact with other users of the transaction management platform. Further, external social networks may be integrated within the transaction management platform via third party applications, thereby allowing the user of the transaction management platform to interact with users of the external social networks.
[00149] FIG. 11 illustrates an example process 1100 to share a thematic repository between multiple entities, in accordance with certain embodiments. At 1102, the social module 216 may receive, from a first entity, a selection of at least a second entity with which to share the selected thematic repository. At 1104, a sharing permission policy may be set. In some instances, the user may set the sharing permission policy. In other instances, a default or a system-defined sharing permission policy may be set. The sharing permission policy may define the proposed sharing relationship between the first entity and the second entity. That is, the sharing permission policy may define rules with respect to what can and what cannot be shared between the first entity and the second entity.
[00150] At 1106, the social module 216 may determine whether the second entity has a transaction management account. If the second entity has a transaction management account, then the social module 216 may notify the second entity of the proposed sharing relationship, at 1108. The social module 216 may also determine whether the second entity accepts the proposed sharing relationship, at 1114. If the second entity accepts the sharing relationship, then the social module 216 may notify the first entity that the second entity accepted the sharing relationship, at 1116. At 1118, the social module 216 may share the thematic repository between the first entity and the second entity.
[00151] If, at 1106, it is determined that the second entity does not have a transaction management account, then the social module 216 may send an invitation to the second entity to create a transaction management account. The social module 216 may do so automatically, or at the request of the first entity. At 1112, the social module 216 may determine whether the second entity creates a transaction management account. If the second entity does not create a transaction management account, then the process 1100 may end. Similarly, if the second entity does not accept the proposed sharing relationship, then the process 1100 may end, at 1120.
[00152] FIG. 12 illustrates an example process 1200 to apportion a monetary value between multiple entities, in accordance with certain embodiments. At 1202, the transaction management module(s) 108 may identify, based on information associated with a financial transaction, at least one monetary value. At 1204, the transaction management module(s) 108 may determine whether the at least one monetary value is associated with an expenditure by a plurality of entities.
[00153] In response to determining that the at least one monetary value is associated with an expenditure by a plurality of entities, the transaction management module(s) 108 may apportion the at least one monetary value, at 1206.
[00154] At 1208, the transaction management module(s) 108 may determine, based at least in part on at least one apportioned monetary value, that a first entity owes an owed monetary value to a second entity.
[00155] At 1210, the transaction management module(s) 108 may provide an indication to at least one of the first entity or the second entity that the first entity owes the owed monetary value to the second entity. In some instances, at least a portion of the owed monetary value may be transferred to the second entity. For example, the first entity may transfer at least a portion of the owed monetary value to the second entity. Additionally or alternatively, a third entity benefactor of the first entity may transfer at least a portion of the owed monetary value to the second entity. In response to a transfer of at least a portion of the owed monetary value to the second entity, the owed monetary value may be updated to an updated owed monetary value. For example, the updated monetary value may be a difference between the owed monetary value and the at least a portion of the owed monetary value transferred to the second entity. An indication may be provided to at least one of the first entity or the second entity that the first entity owes the updated monetary value to the second entity.
EXAMPLE PROCESS(ES) - CREATING BUSINESS PROFILES
[00156] In certain implementations, processes for uploading/sharing a logo for a business profile may include prompting the user to select a logo image. The process may then proceed to upload a temporary file. Once the temporary file is uploaded, the uploaded image may be resized/cropped. The logo may be saved. The process may then proceed to switching the current profile to a new business identification (ID). The new business dashboard may then be displayed.
[00157] In certain implementations, processes for creating employee accounts/profiles to link to an employer/company account may include prompting the user for a first name. The process may proceed to prompting the user for a last name and an email address. The user may be further prompted to select an existing department or enter a new department name. Once the information has been entered by the user, the input may be validated and a request to create a new employee account may be generated. A determination may be made as to whether the department exists. If the department exists, an employee profile may be created. The process may then proceed to sending an activation email to the employee email address. After sending the email, the process may wait for user activation. A determination may then be made as to whether the user's email is linked to a thematic repository. If the user's email is linked to a thematic repository, then the user may be prompted to approve an employee status with an existing account. The process may then link the employee to the company.
[00158] If the user's email is not linked to a thematic repository, then the user may be prompted to determine if the user has an existing account to link. If the user has an existing account to link, then the user may be prompted to sign in to the account that is to be linked. A determination may be made as to whether the account is authenticated. If the account is authenticated, then the user may be prompted to approve an employee status with an existing account. The process may then continue as discussed above.
[00159] If the account is not authenticated, the user may again be prompted to sign in to the account to link. The process may then continue as discussed above.
[00160] If the user does not have an existing account to be linked, an account creation form may be presented. The process may then continue to creating the user profile. After creating the user profile, the process may link the user to the company.
[00161] If the department does not exist, then a new department listing may be created. After adding the new department to the existing departments, the process may proceed to creating an employee profile. The process may then continue as discussed above.
[00162] In certain implementations, a template of employees may be processed. In some instances, all employees may be processed. Employees may also be processed by company department. Upon processing the template of employees, the user can view the employees and departments.
[00163] In certain implementations, processes for the creation of employee accounts from a file may include prompting the user to select an input source. If the input source is a web service, a determination may be made as to whether the source is from a web service file or a direct connection. If the source is a web service file, the user may be prompted to upload the web service file. The process may then proceed to parsing the web service file for data. A list of employees may be created based at least in part on the parsed data.
[00164] If the source from the web service is a direct connection, then the user may be prompted for direct connection credentials (e.g., host, port, username, password, etc.). The process may then proceed to requesting data from a service. The process may then proceed to parsing received data and creating a list of employees.
[00165] If the input source is a file, then the user may be prompted to upload the file. A determination may be made as to whether the file is in an acceptable format. If the file is in an acceptable XLS format, the process may proceed to parsing XLS information and generating a list of employees. If the file is in an acceptable XML format, the process may proceed to parsing the XML structure for matching fields and generating a list of employees. If the file is in an acceptable CSV file, the process may proceed to parsing the rows for headers. The user may be prompted to select which columns correspond to one or more of first name, last name, email address, and department name. The information obtained from the CSV file may be used to generate a list of employees. [00166] If the file selected as the input source is not in an acceptable format, then the user may be informed that the file was unable to be uploaded. The user may be prompted to upload another file. The process may then continue as discussed above.
[00167] Once a list of employees is generated, the process may proceed to adding an employee account, profile, or both, for each employee on the list. A determination may be made as to whether each employee's corresponding department already exists. If the department does not exist, a new department listing may be created. The user may be prompted to customize a company activation email, and the activation email may then be sent to employees.
[00168] In certain implementations, processes for updating employee information may include receiving an employee's identification (ID) to get employee data. The process may also include receiving the employee's department ID to get department data. The user may be presented with information associated with the employee, such as the employee's first name, last name, email address, and department. The user may be presented the option to edit the employee data. If the user opts to edit the employee data, the process may continue to changing the output fields to input fields, and the user may be prompted to edit the employee information (e.g., first name, last name, and, email address, etc.). The process may then make a determination as to whether the changed data is valid.
[00169] The user may also be prompted to edit the department listing. A determination may be made as to whether the department exists. If the department exists, the process may make a determination as to whether the changed data is valid. If the department does not exist, the process may continue to creating a new department listing before proceeding to determine if the changed data is valid.
[00170] If the changed data is valid, then the employee data may be updated, and the user may be notified that the employee data has been updated. If, on the other hand, the changed data is not valid, then the user may be informed of a validation error. The output fields may again be changed to input fields, and the process may then continue as discussed above.
EXAMPLE PROCESS(ES) - TAGGING TRANSACTION DATA WITH GL CODES
[00171] In certain implementations, processes for tagging transaction data with GL codes may prompt the user for a label. The user may also be prompted for a name. A determination may be made as to whether the inputs are valid. If the inputs are valid, then a GL code may be created. The process may then proceed to reloading the GL code listings, and the GL codes may be received. A determination may be made as to whether there are additional GL codes to be added. If there are additional codes to be added, then the user may be prompted for a label. The process may then continue as discussed above.
[00172] If the inputs are not valid, the user may again be prompted for a label. The process may then continue as discussed above.
[00173] In certain implementations, processes for updating the GL code for a category may include showing the user existing codes and categories. The user may be prompted to drag one or more GL codes on top of a category. A determination may be made as to whether the category has a GL code assigned to it. If the category does not have a GL code assigned, the process may proceed to attaching the GL code to the category. The updated category and the associated GL code may be displayed to the user.
[00174] If the category has a GL code assigned to it, the process may include detaching the existing GL code. A new GL code may then be attached to the category. The process may then continue as discussed above.
[00175] In some embodiments, a transaction and/or transaction data may be automatically categorized into one or more categories. In some instances, the category may be a thematic repository. One or more GL codes may be associated with the category. For example, the transaction and/or transaction data may be categorized into a "restaurants" category. GL codes may be filtered automatically to present to a user the GL codes that correspond to the "restaurants" category. For instance, the GL codes that correspond to the "restaurants" category may be "restaurants - business meal" and "restaurants - travel." The user may select one of these GL codes to accurately represent the nature of the transaction, which may have tax implications (e.g., a business meal may be 50% deductible as a business expense whereas a travel meal may be 100% deductible as a business expense). EXAMPLE PROCESS(ES) - CREATING/ADDING FINANCIAL ACCOUNTS
[00176] In certain implementations, processes for adding financial accounts may include causing a message to be displayed that prompts the user to select an account type. A determination may be made as to whether the user selects to add a cash account or a bank account.
[00177] If the user selects to add a cash account, then the process may proceed to receiving account data (e.g., account name, starting balance, default currency, etc.) from the user. The process may proceed to creating the cash account and storing data related to the cash account in a data store.
[00178] If the user selects to add a bank account, then a message may be caused to be displayed that prompts the user to enter the name of a bank. A determination may be made as to whether the bank is an existing bank. If the bank is an existing bank, then a determination may be made as to whether the bank supports a sync application. If the bank supports a sync application, then a message may be caused to be displayed that prompts the user to enter bank login credentials, such as a bank username and password. The bank credentials may be saved in a data store. The process may continue to waiting for the scheduled task to initiate.
[00179] The bank login credentials may then be sent to the bank's sync application. A determination may be made as to whether the bank login credentials are correct. If the bank login credentials are correct, then a determination may be made as to whether there is a requirement to answer a security question. If there is a requirement to answer a security question, then a message may be caused to be displayed that prompts the user to answer the bank security question. Upon receiving an answer to the bank security question, the answer may be sent to the sync application. A determination may be made as to whether the answer to the security question is correct. If the answer to the security question is correct, then financial information may be received from the bank.
[00180] If the bank login credentials are incorrect, then the user may again be prompted to enter bank login credentials and the process may continue as discussed above.
[00181] If either the bank is not an existing bank or the bank does not support a sync application, then a message may be caused to be displayed that prompts the user to select a bank statement file. The user may be presented with the option to drag and drop one or more bank statements, and data from the one or more bank statements may be imported as discussed below. The user may also be presented with the option to request sync support for the user's bank.
EXAMPLE PROCESS(ES) - IMPORTING TRANSACTIONS FROM USER-SELECTED FILE
[00182] In certain implementations, processes for importing transactions may include receiving a user-selected file. A determination may be made as to whether the file is of a supported format. If the file is of a supported format, then a determination may be made as to whether the file is password protected. If the file is password protected, then a determination may be made as to whether the password is stored. If the password is stored, then a determination may be made as to whether the password is correct. If the password is correct, then data may be extracted from the file and an attempt may be made to find a supported template for the file.
[00183] A determination may be made as to whether a template pattern that supports the file can be found. If a template pattern that supports the file is found, then an attempt may be made to extract accounts from the file. A determination may be made as to whether the extracted accounts already exist. If so, then there may be no need to add the accounts as new accounts. The process may proceed to extracting transactions from the file. A determination may be made as to whether the transactions already exist. If the transactions already exist, then the transactions, the accounts, a total number of accounts, a total number of transactions, or any combination thereof, may be caused to be displayed.
[00184] If some or all of the transactions do not already exist, then those transactions that do not already exist may be added as new transactions, then the transactions, the accounts, a total number of accounts, a total number of transactions, or any combination thereof, may be caused to be displayed.
[00185] If some or all of the accounts do not already exist, then those accounts that do not already exist may be added as new accounts, then the process may proceed to extracting transactions from the file and continue as discussed above.
[00186] If a template pattern that supports the file is not found, then the file may be sent to the new template development team so that a new template may be developed to support the file, the file type, the file format, or any combination thereof. Further, a message may be caused to be output to the user indicating that the file is not supported. The message may further include an indication that the user will be notified when the file is supported. A determination may be made as to whether there is an attempt to add another file. If there is an attempt to add another file, then the process may proceed to determining whether the file is of a supported format. If the file is of a supported format, then the process may proceed as discussed above. If the file is not of a supported format, then a message may be caused to be output to the user indicating that the file is of an invalid format. A determination may be made as to whether there is an attempt to add another file. If there is an attempt to add another file, then the process may proceed to receiving the user-selected file, determining if the new file is of a supported format, and so on, as discussed above. Otherwise, if there is no attempt to add another file, then the process may end, or the process may continually monitor to determine whether there is an attempt to add another file.
[00187] If a stored password is incorrect (e.g., it is expired or was previously entered incorrectly), then the user may be prompted to enter a password for the file. Similarly, if the password is not stored, then the user may be prompted to enter a password for the file. The process may proceed by checking if any password entered by the user is correct, and the process may continue to prompt the user for a password if the password is again incorrect. Once a correct password is received, the process may proceed to extracting data from the file and attempting to find a supported template for the file as discussed above. [00188] If the file is not password protected, then the process may proceed to extracting data from the file and attempting to find a supported template for the file as discussed above.
EXAMPLE PROCESS(ES) - PROCESSING A RECEIPT
[00189] In certain implementations, processes for receiving/processing a receipt may include making a determination as to whether a mobile device is being used. If a mobile device is being used, then a window (or other indication) may be provided indicating that the user can take a picture or select a picture from a library (i.e., a data store). A determination may be made as to whether the user opts to select a picture from a library. If the user opts to select a picture from a library, then the process may proceed to receiving a selection of the picture.
[00190] A determination may also be made as to whether the user opts to add another picture (e.g., to add another part of the same receipt or to add a different receipt). If the user opts to add another picture, then a determination may be made as to whether the user opts to select a picture from a library. If the user opts to select a picture from a library, then the process may proceed as discussed above.
[00191] If the user opts not to add another picture, then any receipts digitally represented via received pictures may be processed (e.g., transaction data may be extracted and imported). Alternatively or additionally, received pictures may be processed on an ongoing basis (i.e., as they are received).
[00192] If the user opts not to select a picture from a library, then the user may take a picture using a camera of the mobile device. Upon the user having taken a picture using a camera of the mobile device, the process may proceed to determining whether the picture is acceptable, which may include determining whether the picture satisfies certain conditions regarding quality and format of the picture. If the picture is determined to be acceptable, then a determination may be made as to whether the user opts to add another picture. The process may then continue as discussed above. Otherwise, if the picture is not determined to be acceptable, then the user may opt to take another picture. A determination may be made as to acceptability of each picture taken, selected, received, or any combination thereof.
[00193] In some embodiments, if a device without a camera is being used, or if the transaction management account is being accessed via a web application, then the user may only be provided with the option to select a file from a data store. That is, the user may not be provided the option to take a picture with the device being used if it does not support such functionality. [00194] In certain implementations, processes for importing transactions may include receiving a digital representation of a receipt (e.g., a photo/picture/image of a receipt). A determination may be made as to whether the receipt is computer readable. If the receipt is computer readable, then the receipt may be processed with an optical character recognition (OCR) engine. The process may then proceed to creating/adding transactions from the data extracted/processed by the OCR engine. These transactions may be displayed or otherwise provided to a quality assurance (QA) team or system. A determination may be made as to whether the receipt is QA readable. If the receipt is QA readable, then the process may proceed to setting, with respect to the transactions, description, date, amount, vendor, category, or any combination thereof. In some embodiments, further transaction details may be set. A determination may be made as to whether the transactions, individually or in combination, include valid data. If a transaction includes valid data, then the transaction is saved in a data store, and an indication of the transaction may be caused to be displayed to the user. If the transaction does not include valid data, then the process may proceed to setting, with respect to the transactions, description, date, amount, vendor, category, or any combination thereof. The process may then continue as discussed above.
[00195] In certain embodiments, transactions and/or transaction data may be extracted from documents (e.g., hard copies and/or electronic formats of receipts and/or invoices) on a summary level basis. That is, some details of one or more transactions and/or transaction data may not be extracted. Additionally or alternatively, transactions and/or transaction data may be extracted from documents (e.g., hard copies and/or electronic formats of receipts and/or invoices) on a line item level basis. That is, further details corresponding to one or more line item transactions and/or transaction data may be extracted. Thus, extraction may carried out on varying levels of granularity.
[00196] If the receipt or invoice is not legible, then a notification may be caused to be provided to the user indicating that there was a problem processing the receipt image. In certain instances, if the receipt is not computer readable, then an empty transaction that includes default data may be created and displayed or otherwise provided to QA. EXAMPLE PROCESS(ES) - RECEIVING TRANSACTIONS FROM A FINANCIAL INSTITUTION
[00197] In certain implementations, processes for importing transactions may include receiving, from a bank or other financial institution, a file (e.g., PDF, XML, OFX, QFX, CSV, etc.) that includes bank/financial statement information. For example, the bank may send the file via email to the user at an email address associated with the transaction management module(s). In some embodiments, the email may be transmitted via simple mail transfer protocol (SMTP). Upon receiving the email, a determination may be made as to whether the email address corresponds with a valid user. If the email address corresponds with a valid user, then the file is saved in a user directory (i.e., a data store). A task may be scheduled to run at certain intervals (e.g., every five minutes). For example, the task may determine whether there are any files in the user directory that have yet to be processed. The task may further initiate extraction/importation of transaction data from any files not yet processed using one or more techniques discussed herein.
[00198] If, on the other hand, the email address does not correspond with a valid user, then the file may be deleted, designated not to be processed, or both.
EXAMPLE PROCESS(ES) - MANAGING DISTANCE TRANSACTIONS
[00199] In certain implementations, processes for managing distance transactions (e.g., mileage) may include determining whether a mobile device is being used. If a mobile device is being used, and if the mobile device provides global positioning system (GPS) functionality (or any other feature or system suitable for tracking distance), then a determination may be made as to whether to set the GPS to record distance. If the GPS is set to record distance, then a determination may be made as to whether the GPS is on or otherwise activated. If the GPS is on, then a determination may be made as to whether the GPS has synced. Otherwise, the user may be presented with a message indicating that the GPS is off or otherwise deactivated. If the GPS is on and has synced, then the user may be provided an indication that the GPS is ready for use. If the GPS has not synced, then the GPS may be queried for signal until, for example, it is determined that the GPS has synced.
[00200] The user may also be prompted to provide an input indicating when the GPS is to start tracking distance. Once such "start" input is received from the user, the GPS may track distance until another input is received from the user indicating when the GPS is to stop tracking distance. While the GPS is tracking distance, the user may be presented with a map. If the user attempts to change the screen, the user may be presented with a warning regarding the in-process distance tracking. Once such "stop" input is received from the user, the data may be fetched from the GPS, including, for example, the tracked distance transaction data. The process may proceed to determining a price per unit distance (e.g., price per mile). For example, a determination may be made as to whether the price per unit distance is defined by a company such as the user's employer. If the price per unit distance is defined by a company, then the company-defined price per unit distance may be used. In some embodiments, if the price per unit distance is not defined by a company, then a government- defined price per unit distance may be used. [00201] The user may be allowed to input a description in association with the fetched GPS data. The user may also be allowed to add other data in association with the fetched GPS data. For example, the user may be allowed to tag a location, tag a category, tag a business paybook, tag a personal paybook, post a comment, add a note, split a transaction, change a date, change a currency, attach a photo, tag a connection, or any combination thereof. Splitting a transaction may include changing an item amount (e.g., changing a distance value or a monetary value), tagging an item to a category, tagging an item to a business paybook, tagging an item to a personal paybook, tagging an item to a contact from the user's connections, or any combination thereof. Tagging an item to a category may include the item being automatically categorized in accordance with predefined rules. That is, the user may define rules for categorizing transaction data items, or the transaction management module(s) may be provided with default categorization rules, or both. In some instances, tagging an item to a contact may include choosing a contact, associating the contact with an amount/value, associating at least one of the item or the contact with a paybook, or any combination thereof. Data that is added by the user may be saved in a data store.
[00202] If a mobile device is not being used, or if a mobile device is being used but GPS functionality is not being used, then a determination may be made as to whether the distance data is already known. If the distance is already known, then the distance may be added as distance transaction data. With the price per unit distance known and the distance known, a price value may be calculated and added as transaction data. If the distance is not known, on the other hand, then the distance may be calculated via the differential between an initial point and a final point. An initial point and a final point may be received from the user and a distance may be calculated between the initial point and the final point. In some instances, calculating a distance between the initial point and the final point may include using a map feature or service that is capable of providing distances between two points via established routes (e.g., one or more roads).
EXAMPLE PROCESS(ES) - MANAGING TIME TRANSACTIONS
[00203] In certain implementations, processes for managing time transactions may include determining whether time is manually input. If time is manually input, then the user may be prompted to add time. The user may also be prompted to add a description and a price per hour. A determination may be made as to whether any more data is added. The user may be allowed to add other data in association with the time data similar to the manner discussed above with respect to managing distance transactions. Data that is added by the user may be saved in a data store.
[00204] If time is not manually input, a determination may be made as to whether to start a stopwatch. If a stopwatch should be started, then the process may proceed to setting an initial time on the stopwatch. The initial time on the stopwatch may be stored. The stopwatch panel may be displayed such that the user may later perform a "stop action." Once the user stops the stopwatch, a determination may be made as to whether the time lapse is correct. If the time lapse is correct, then the user may be prompted for a description. The process may then continue as described above.
[00205] If the time lapse is not correct, then the user may be prompted to determine if the stopwatch should have been stopped earlier and adjust the time accordingly. The user may then be prompted for a description. The process may then continue as described above.
[00206] If a stopwatch should not be started, a determination may be made as to whether time is manually input. The process may then continue as described above.
EXAMPLE PROCESS(ES) - SPLITTING/APPORTIONING TRANSACTIONS
[00207] In certain implementations, processes for splitting transactions may include a determination as to whether the transaction is to be split by connection. If the transaction is to be split by connection, then a determination may be made as to whether the transaction is already split. If the transaction is already split, then the user may be presented with a list of connections on the transaction. A determination may be made as to whether the split amount is to be changed. If the split amount is to be changed, then the user may be prompted to add the amount. A determination may then be made as to whether the sum of the connections' amount is less than or equal to the total. If the sum of the connections' amount is less than or equal to the total, then the user may be presented with a list of connections on the transactions.
[00208] If the split amount should not be changed, then the user may be presented with a list of connections on the transactions.
[00209] Once presented with a list of connections on the transactions, the user may be prompted to add a new connection. A determination may then be made as to whether the sum of the connections' amount is less than or equal to the total. The process may then continue as discussed above.
[00210] If the sum of the connections' amount is less than or equal to the total, then the user may be presented with an error message. The user may be prompted to add a new connection. The process mav then continue as discussed above. [00211] If the transaction is not already split, then the user may be prompted to add a new connection. The process may then continue as discussed above.
[00212] If the transaction should not be split by connection, then a determination may be made as to whether the transaction is already itemized. If the transaction is already itemized, then the user may be presented with a list of items. The user may be prompted to add a new item. A determination may be made as to whether the sum of the item amounts is less than the total. If the sum of the item amounts is less than the total, the process may proceed to creating a new sub-transaction equal to the item requested and modifying the last item's amount to be the remaining quantity. A determination may be made as to whether an item should be renamed, the item amount should be changed, the item category should be tagged, the item should be tagged to a personal paybook, the item should be tagged to a business paybook, a connection should be tagged, or any combination thereof. If a connection should be tagged, then a determination may be made as to whether the parent transaction is already split by connection. If the parent transaction is already split by connection, then an error message may be displayed and the user may be presented with a list of items.
[00213] If the parent transaction is not is not already split by connection, then the user may be prompted to choose a connection. The user may be prompted to add a description and/or add an amount. The process may then proceed to creating a collect transaction with the amount defined. A determination may be made as to whether to tag another connection. If another connection should be tagged, then the user may be prompted to choose a connection and the process may continue as discussed above. If another connection should not be tagged, then the user may be presented with a list of items.
[00214] If after adding a new item the sum of the item amounts is not less than the total, then a determination may be made as to whether the total amount is the same as the parent. If the total amount is not the same as the parent, then the user may be presented with a list of items. The process may then continue as discussed above. If the total amount is the same as the parent, then the process may proceed to creating a new sub-transaction equal to the item requested, modifying the last item's amount to zero, and disabling the last item. A determination may be made as to whether: an item should be renamed, the item amount should be changed, the item category should be tagged, the item should be tagged to a personal paybook, the item should be tagged to a business paybook, a connection should be tagged, or any combination thereof. The process may then continue as discussed above.
[00215] If the transaction is not already itemized, then the user may be prompted to add a new item. A determination may then be made as to whether the amount is less than the total. If the amount is less than the total, then the process may continue to modifying the transaction to be a virtual container (parent transaction). A new sub-transaction (child) may be created equal to the item requested, and a second sub-transaction may be created with the remaining amount, inheriting all attributes from the parent. A determination may be made as to whether: an item should be renamed, the item amount should be changed, the item category should be tagged, the item should be tagged to a personal paybook, the item should be tagged to a business paybook, a connection should be tagged, or any combination thereof. The process may then continue as discussed above.
[00216] After adding a new item, if the amount is not less than the total, an error message may be displayed.
EXAMPLE PROCESS(ES) - GENERATING EXPENSE REPORTS
[00217] In certain implementations, processes for generating expense reports may include identifying a thematic repository designated as a master of a group of thematic repositories. The user of a particular transaction management account may designate the thematic repository as a master of the group of thematic repositories. However, a user of a different transaction management account may, in some embodiments, designate the thematic repository as a master of the group of thematic repositories. The transaction management module(s) may link the master thematic repository to one or more member thematic repositories. In some embodiments, one or more of the linked thematic repositories may be capable of communicating, i.e., sharing data, with one or more of the other linked thematic repositories.
[00218] The transaction management module(s) may receive transaction data and/or associated configuration data from a particular member thematic repository. The member thematic repository's transaction data and/or associated configuration data may be routed to the master thematic repository. The member thematic repository may push data to the master thematic repository, or the master thematic repository may pull data from the member thematic repository. It should be understood that data may also be routed from the master thematic repository to the member thematic repository in a similar manner.
[00219] The transaction management module(s) may determine whether any rule(s) and/or policy(ies) have been established. If the transaction management module(s) determine that a rule and/or policy has been established, then the transaction management module(s) and/or the TDC unit may check each data item received against the rule and/or policy.
[00220] The transaction management module(s) and/or the TDC unit may determine whether each data item violate the rule and/or policy. If it is determined that a particular data item does not violate any rule and/or policy, then the particular data item may be flagged as "compliant" (or the like) and stored. If, on the other hand, it is determined that a particular data item does not violates at least one rule and/or policy, then the particular data item may be flagged as "non-compliant" (or the like) and stored. The process may continue to checking whether there are data items that remain to be checked against the rule and/or policy. If there are data items that remain to be checked against the rule and/or policy, then the process may continue as discussed above until no data remains to be checked.
[00221] If no data remains to be checked, then the transaction management module(s) may determine whether any reports have been requested. If so, the transaction management module may generate a report comprising one or more received data items.
[00222] In certain embodiments, the report may be generated automatically based at least in part on tags associated with the data items. For example, a business entity may manage business transactions via one or more thematic repositories that are shared with employees. Employees may associate business expenses/transactions with the thematic repositories. The transaction management module(s) may pull the transaction data from the various business transactions to build an expense report.
[00223] In some embodiments, a user may incur an expense on a personal account that is reimbursable by the user's employer. The user may associate this transaction with the employer (e.g., by associating the transaction with a thematic repository shared between the employer and the user). A reimbursable monetary value of the transaction may be indicated as a "Collect" transaction. Once the employer reimburses the user, the transaction management module may automatically cancel the "Collect" transaction and apply the monetary value to an "Expense" transaction. This may allow the user to more accurately track personal budgets, as the reimbursable amount, once reimbursed, may no longer be indicated as a personal expense.
[00224] In certain embodiments, methods disclosed herein include, receiving, under control of one or more processors, information associated with a financial transaction. For example, the receiving information associated with the financial transaction may include receiving bank statement information. Additionally or alternatively, the receiving information associated with the financial transaction may include receiving purchase receipt information.
[00225] The methods may include determining, based on the information associated with the financial transaction, that the financial transaction is associated with a first theme and a second theme. [00226] At least a portion of the information associated with the financial transaction may be designated to a first repository. The first repository may be configured to provide an aggregation of information associated with a plurality of financial transactions that are individually determined to be associated with the first theme. At least a portion of the information associated with the financial transaction may be designated to the first repository automatically. For example, at least a portion of the information associated with the financial transaction may be designated to the first repository automatically based at least in part on one or more predetermined rules. Additionally or alternatively, at least a portion of the information associated with the financial transaction may be designated to the first repository manually.
[00227] At least a portion of the information associated with the financial transaction may be designated to a second repository. The second repository may be configured to provide an aggregation of information associated with a plurality of financial transactions that are individually determined to be associated with the second theme. At least a portion of the information associated with the financial transaction may be designated to the second repository automatically. For example, at least a portion of the information associated with the financial transaction may be designated to the second repository automatically based at least in part on one or more predetermined rules. Additionally or alternatively, at least a portion of the information associated with the financial transaction may be designated to the second repository manually.
[00228] In some instances, at least a portion of the information associated with the financial transaction may be designated to the first repository automatically and at least a portion of the information associated with the financial transaction may be designated to the second repository manually, or vice-versa.
[00229] In response to a request related to the financial transaction, an indication that the financial transaction is associated with the first theme and the second theme may be provided.
[00230] In some implementations, the methods may include determining, based on the information associated with the financial transaction, that the financial transaction is associated with a financial account, and, in response to a request related to the financial transaction, providing at least an indication that the financial transaction is associated with the first repository, the second repository, and the financial account. The financial account may be a bank account. Additionally or alternatively, the financial account may be a cash account. [00231] The methods may include, in response to receiving a request from an entity to share the first repository with one or more other entities, allowing the one or more other entities access to at least a portion of the information associated with the first repository.
[00232] In certain embodiments, methods disclosed herein include identifying, based on the information associated with the financial transaction, at least one monetary value. The methods may include determining whether the at least one monetary value is associated with an expenditure by a plurality of entities. In response to determining that the at least one monetary value is associated with an expenditure by a plurality of entities, the at least one monetary value may be apportioned such that individual ones of the plurality of entities are associated with an apportioned monetary value.
[00233] The methods may include determining, based at least in part on at least one apportioned monetary value, that a first entity owes an owed monetary value to a second entity. An indication may be provided to at least one of the first entity or the second entity that the first entity owes the owed monetary value to the second entity.
[00234] At least a portion of the owed monetary value may be transferred to the second entity. For example, the first entity may transfer at least a portion of the owed monetary value to the second entity. Additionally or alternatively, a third entity benefactor of the first entity may transfer at least a portion of the owed monetary value to the second entity. In response to a transfer of at least a portion of the owed monetary value to the second entity, the owed monetary value may be updated to an updated owed monetary value. For example, the updated monetary value may be a difference between the owed monetary value and the at least a portion of the owed monetary value transferred to the second entity. An indication may be provided to at least one of the first entity or the second entity that the first entity owes the updated monetary value to the second entity.
[00235] In some embodiments, the first repository may be configured to provide an aggregation of information associated with a plurality of personal financial transactions that are individually determined to be associated with the first theme. The second repository may be configured to provide an aggregation of information associated with a plurality of business financial transactions that are individually determined to be associated with the second theme.
[00236] At least one of the first repository or the second repository may be shared between an individual user account and a business entity account such that information designated to the respective at least one of the first repository or the second repository by a user of the individual user account is provided to the business entity account. For example, the business entity account may be associated with a business entity and the individual user account may be associated with an employee of the business entity.
[00237] In certain implementations, the present disclosure includes one or more computer- readable media having computer-readable instructions therein that, when executed by one or more processors, cause the one or more processors to perform acts. The acts may include receiving data associated with at least one financial transaction.
[00238] For example, receiving the data associated with the at least one financial transaction may include receiving an input of one or more electronic files associated with at least one bank statement, and extracting data from the one or more electronic files associated with the at least one bank statement. As another example, receiving the data associated with the at least one financial transaction may include receiving an input of one or more electronic files associated with at least one purchase receipt, and extracting data from the one or more electronic files associated with the at least one bank statement. In some embodiments, for individual electronic files of the one or more electronic files, a determination may be made as to whether the individual electronic file matches one or more predefined templates. In response to determining that the individual electronic file matches one or more predefined templates, data may be extracted from the individual electronic file in accordance with a matching predefined template.
[00239] At least a subset of the data may be associated with at least one thematic repository of a plurality of thematic repositories. An individual thematic repository of the plurality of thematic repositories may, for example, be configured to aggregate data from a plurality of financial transactions that are individually determined to be associated with a theme of the individual thematic repository. A user interface may be generated. The user interface may provide at least an indication that the at least a subset of the data is associated with the at least one thematic repository of the plurality of thematic repositories.
[00240] In some embodiments, associating the at least a subset of the data with the at least one thematic repository of the plurality of thematic repositories may include automatically categorizing, based at least in part on a comparison of the extracted data to one or more predefined categorization rules, at least a subset of the extracted data into at least a first thematic repository of the plurality of thematic repositories. In certain instances, associating the at least a subset of the data with the at least one thematic repository of the plurality of thematic repositories may include receiving a manual categorization of the at least a subset of the extracted data into at least a second thematic repository of the plurality of thematic repositories. [00241] At least one thematic repository of the plurality of thematic repositories may be published such that at least a subset of data aggregated by the at least one thematic repository is accessible to multiple entities via one or more user accounts, the one or more user accounts being configured to provide thematic repository functionality.
[00242] Certain implementations disclosed herein include systems having one or more processors, memory, and a thematic repository module maintained in the memory and executed on the one or more processors to perform acts. The acts may include receiving information associated with a transaction. Based on the information associated with the transaction, it may be determined that the transaction is associated with at least one thematic repository. The at least one thematic repository of the plurality of thematic repositories may, for example, be configured to aggregate information from a plurality of financial transactions that are individually determined to be associated with a theme of the at least one thematic repository. In response to a request related to the transaction, at least an indication that the transaction is associated with the at least one thematic repository may be provided.
[00243] In some embodiments, the at least one thematic repository of the plurality of thematic repositories may include a first thematic repository configured to aggregate information from a plurality of financial transactions that are individually determined to be associated with a same financial institution account (e.g., a debit card account, a credit card account, a checking account, a savings account, an investment account, etc.). Additionally or alternatively, the at least one thematic repository of the plurality of thematic repositories may include a second thematic repository configured to aggregate information from a plurality of transactions that are individually determined to be associated with a same user-defined theme.
[00244] In certain embodiments, the at least one thematic repository may include a first thematic repository configured to aggregate data from a plurality of financial transacations that are individually determined to be associated with a first theme. The first thematic repository may be associated with a second thematic repository. The second thematic repository may be configured to aggregate data from a plurality of financial transactions that are individually determined to be associated with a second theme.
[00245] The systems may further include a user interface module maintained in the memory and executed on the one or more processors to perform acts. The acts may include receiving a request related to the at least one thematic repository of the plurality of thematic repositories, and, in response to receiving the request related to the at least one thematic repository of the plurality of thematic repositories, causing to be displayed an aggregation of information from a plurality of transactions that are individually determined to be associated with the at least one thematic repository of the plurality of thematic repositories. Additionally or alternatively, the acts may include generating a user interface that allows a user to view, manipulate, or both view and manipulate, at least a portion of the aggregation of information at varying levels of granularity.
[00246] In some embodiments, allowing a user to manipulate the at least a portion of the aggregation of information includes allowing a first user to associate a monetary value with a second user. The second user may be an employer of the first user, and the monetary value may be designated a business expense such that the employer is capable of generating an expense report based at least in part on the monetary value.
[00247] In some embodiments, allowing a user to manipulate the at least a portion of the aggregation of information includes allowing a first user to split a monetary value such that at least a portion of the monetary value is associated with a second user.
[00248] In some embodiments, allowing a user to manipulate the at least a portion of the aggregation of information includes allowing the user to add electronic documents that are determined to be associated with the aggregation of information.
[00249] In certain embodiments, the at least one thematic repository of the plurality of thematic repositories may include: a first thematic repository configured to aggregate information from a plurality of financial transactions that are individually determined to be associated with a same bank account, a second thematic repository configured to aggregate information from a plurality of transactions that are individually determined to be associated with a same system-defined theme, and a third thematic repository configured to aggregate information from a plurality of transactions that are individually determined to be associated with a same user-defined theme. CONCLUSION
[00250] Although embodiments have been described in language specific to structural features and/or methodological acts, it is to be understood that the disclosure is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed herein as illustrative forms of implementing the embodiments.

Claims

CLAIMS WHAT IS CLAIMED IS :
1. A method comprising:
under control of one or more processors,
receiving information associated with a financial transaction;
determining, based on the information associated with the financial transaction, that the financial transaction is associated with a first theme and a second theme;
designating at least a portion of the information associated with the financial transaction to a first thematic repository, the first thematic repository configured to provide an aggregation of information associated with a plurality of financial transactions that are individually determined to be associated with the first theme;
designating at least a portion of the information associated with the financial transaction to a second thematic repository, the second thematic repository configured to provide an aggregation of information associated with a plurality of financial transactions that are individually determined to be associated with the second theme; and
in response to a request related to the financial transaction, providing at least an indication that the financial transaction is associated with the first theme and the second theme.
2. The method of claim 1, wherein:
the first thematic repository is configured to provide an aggregation of information associated with a plurality of personal financial transactions that are individually determined to be associated with the first theme; and
the second thematic repository is configured to provide an aggregation of information associated with a plurality of business financial transactions that are individually determined to be associated with the second theme.
3. The method of claim 2, wherein the second thematic repository is shared between an individual user account and a business entity account such that information designated to the second thematic repository by a user of the individual user account is provided to the business entity account.
4. The method of claim 3, wherein the business entity account is associated with a business entity and the individual user account is associated with an employee of the business entity.
5. The method of claim 1, further comprising:
determining, based on the information associated with the financial transaction, that the financial transaction is associated with a financial account; and
in response to a request related to the financial transaction, providing at least an indication that the financial transaction is associated with the first repository, the second repository, and the financial account.
6. The method of claim 5, wherein the financial account is an account from a financial institution.
7. The method of claim 5, wherein the financial account is a cash account.
8. The method of claim 1, wherein the at least a portion of the information associated with the financial transaction is designated to the first thematic repository automatically based at least in part on one or more predetermined rules.
9. The method of claim 8, wherein at least a portion of the information associated with the financial transaction is designated to the second thematic repository manually.
10. The method of claim 1, wherein the receiving information associated with the financial transaction comprises receiving one or more of bank statement information or purchase receipt information.
1 1. The method of claim 1, further comprising:
in response to receiving a request from an entity to share the first thematic repository with one or more other entities, allowing the one or more other entities access to at least a portion of the information associated with the first thematic repository.
12. The method of claim 1, further comprising:
identifying, based on the information associated with the financial transaction, at least one monetary value;
determining whether the at least one monetary value is associated with an expenditure by a plurality of entities; in response to determining that the at least one monetary value is associated with an expenditure by a plurality of entities, apportioning the at least one monetary value such that individual ones of the plurality of entities are associated with an apportioned monetary value; determining, based at least in part on at least one apportioned monetary value, that a first entity owes an owed monetary value to a second entity; and
providing an indication to at least one of the first entity or the second entity that the first entity owes the owed monetary value to the second entity.
13. The method of claim 12, further comprising;
in response to a transfer of at least a portion of the owed monetary value to the second entity, updating the owed monetary value to an updated monetary value, wherein the updated monetary value is a difference between the owed monetary value and the at least a portion of the owed monetary value transferred to the second entity; andproviding an indication to at least one of the first entity or the second entity that the first entity owes the updated monetary value to the second entity.
14. One or more computer-readable media having computer-readable instructions therein that, when executed by one or more processors, cause the one or more processors to perform acts comprising:
receiving data associated with at least one financial transaction;
associating at least a subset of the data with at least one thematic repository, the at least one thematic repository being configured to aggregate data from a plurality of financial transactions that are individually determined to be associated with a theme of the at least one thematic repository; and
generating a user interface that provides at least an indication that the at least a subset of the data is associated with the at least one thematic repository.
15. The computer-readable media of claim 14, wherein the receiving the data associated with the at least one financial transaction comprises:
receiving an input of one or more electronic files associated with at least one of a bank statement or a purchase receipt; and
for individual electronic files of the one or more electronic files:
determining whether the individual electronic file matches one or more predefined templates; and in response to determining that the individual electronic file matches one more predefined templates, extracting data from the individual electronic file accordance with a matching predefined template.
16. The computer-readable media of claim 14, wherein the receiving the data associated with the at least one financial transaction comprises extracting data from one or more electronic files associated with one or more of a bank statement or a purchase receipt, and wherein the associating the at least a subset of the data with the at least one thematic repository of the plurality of thematic repositories comprises:
automatically categorizing, based at least in part on a comparison of the
extracted data to one or more predefined categorization rules, at least a subset of the extracted data into at least a first thematic repository of the plurality of thematic repositories; and
receiving a manual categorization of the at least a subset of the extracted data into at least a second thematic repository of the plurality of thematic repositories.
17. The computer-readable media of claim 16, further comprising publishing at least one thematic repository of the plurality of thematic repositories such that at least a subset of data aggregated by the at least one thematic repository is accessible to multiple entities via one or more user accounts, the one or more user accounts being configured to provide thematic repository functionality.
18. The computer-readable media of claim 14, wherein the at least one thematic repository includes a first thematic repository configured to aggregate data from a plurality of financial transactions that are individually determined to be associated with a first theme, the acts further comprising:
associating the first thematic repository with a second thematic repository, the second thematic repository being configured to aggregate data from a plurality of financial transactions that are individually determined to be associated with a second theme.
19. A system comprising:
one or more processors;
memory; and
a thematic repository module maintained in the memory and executed on the one or more processors to:
receive information associated with a transaction; determine, based on the information associated with the transaction, that the transaction is associated with a plurality of thematic repositories, including:
a first thematic repository configured to aggregate information from a plurality of financial transactions that are individually determined to be associated with a same financial institution account;
a second thematic repository configured to aggregate information from a plurality of transactions that are individually determined to be associated with a same system-defined theme; and
a third thematic repository configured to aggregate information from a plurality of transactions that are individually determined to be associated with a same user-defined theme; and
in response to a request related to the transaction, provide at least an indication that the transaction is associated with the first thematic repository, the second thematic repository, and the third thematic repository.
20. The system of claim 19, further comprising a user-interface module maintained in the memory and executed on the one or more processors to:
receive a request related to at least one of the plurality of thematic repositories; and in response to receiving the request related to the at least one of the plurality of thematic repositories, cause to be displayed an aggregation of information from a plurality of transactions that are individually determined to be associated with the at least one of the plurality of thematic repositories.
21. The system of claim 20, wherein the user- interface module is further configured to cause to generate a user-interface that allows a user to view, manipulate, or both view and manipulate, at least a portion of the aggregation of information at varying levels of granularity, and wherein allowing a user to manipulate the at least a portion of the aggregation information includes allowing the user to add electronic documents that are determined to be associated with the aggregation of information.
PCT/US2014/022215 2013-03-09 2014-03-09 Thematic repositories for transaction management WO2014164382A1 (en)

Priority Applications (8)

Application Number Priority Date Filing Date Title
US14/774,047 US10121208B2 (en) 2013-03-09 2014-03-09 Thematic repositories for transaction management
BR112015022133A BR112015022133A8 (en) 2013-03-09 2014-03-09 method, computer readable media and system related thematic repositories for transaction management
CA2941355A CA2941355A1 (en) 2013-03-09 2014-03-09 Thematic repositories for transaction management
EP14780012.2A EP2965293A4 (en) 2013-03-09 2014-03-09 Thematic repositories for transaction management
MX2015012116A MX361879B (en) 2013-03-09 2014-03-09 Thematic repositories for transaction management.
HK16108255.5A HK1220281A1 (en) 2013-03-09 2016-07-13 Thematic repositories for transaction management
US15/433,966 US10366457B2 (en) 2013-03-09 2017-02-15 Thematic repositories for transaction management
US16/526,567 US20190355067A1 (en) 2013-03-09 2019-07-30 Thematic repositories for transaction management

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201361775485P 2013-03-09 2013-03-09
US61/775,485 2013-03-09
US201361775869P 2013-03-11 2013-03-11
US61/775,869 2013-03-11

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US14/774,047 A-371-Of-International US10121208B2 (en) 2013-03-09 2014-03-09 Thematic repositories for transaction management
US15/433,966 Continuation-In-Part US10366457B2 (en) 2013-03-09 2017-02-15 Thematic repositories for transaction management

Publications (1)

Publication Number Publication Date
WO2014164382A1 true WO2014164382A1 (en) 2014-10-09

Family

ID=51658862

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2014/022215 WO2014164382A1 (en) 2013-03-09 2014-03-09 Thematic repositories for transaction management

Country Status (8)

Country Link
US (1) US10121208B2 (en)
EP (1) EP2965293A4 (en)
BR (1) BR112015022133A8 (en)
CA (1) CA2941355A1 (en)
CL (1) CL2015002536A1 (en)
HK (1) HK1220281A1 (en)
MX (1) MX361879B (en)
WO (1) WO2014164382A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018152377A1 (en) * 2017-02-15 2018-08-23 Paybook, Inc. Thematic repositories for transaction management
US10121208B2 (en) 2013-03-09 2018-11-06 Paybook, Inc. Thematic repositories for transaction management
US10366457B2 (en) 2013-03-09 2019-07-30 Paybook, Inc. Thematic repositories for transaction management
US20220277321A1 (en) * 2019-08-14 2022-09-01 Paybook, Inc. Systems and processes that augment transparency of transaction data

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10510113B2 (en) * 2013-09-09 2019-12-17 Mx Technologies, Inc. Providing financial transaction data to a user
US10528838B1 (en) 2014-09-23 2020-01-07 Wells Fargo Bank, N.A. Augmented reality confidential view
US9767585B1 (en) * 2014-09-23 2017-09-19 Wells Fargo Bank, N.A. Augmented reality confidential view
US9524172B2 (en) * 2014-09-29 2016-12-20 Bank Of America Corporation Fast start
US20180143975A1 (en) * 2016-11-18 2018-05-24 Lionbridge Technologies, Inc. Collection strategies that facilitate arranging portions of documents into content collections
USD843402S1 (en) * 2017-04-10 2019-03-19 Fisher & Paykel Healthcare Limited Display screen or portion thereof with graphical user interface
US10740965B2 (en) * 2018-06-01 2020-08-11 Trx Systems, Inc. Mapping complex building models
WO2020039957A1 (en) * 2018-08-22 2020-02-27 ソニー株式会社 Information processing device, information processing method, and program
US11810140B2 (en) * 2019-01-07 2023-11-07 Gcow Llc Systems and methods to facilitate providing a software development kit (SDK) for rewards for making gift card purchases to multiple application publishers
US11176582B2 (en) 2019-04-12 2021-11-16 Mastercard International Incorporated Systems and methods for multi-track processing of incoming data events
US20240012988A1 (en) * 2022-07-11 2024-01-11 Truist Bank Automatically configuring an insight carousel of a graphical user interface based on templates

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110208663A1 (en) * 2004-03-19 2011-08-25 Kennis Peter H Extraction of transaction data for compliance monitoring

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997014108A1 (en) * 1995-10-11 1997-04-17 Block Financial Corporation Financial information access system
MXPA03001652A (en) * 2000-08-25 2004-04-02 American Express Travel Relate System and method for account reconciliation.
GB0029229D0 (en) * 2000-11-30 2001-01-17 Unisys Corp Counter measures for irregularities in financial transactions
EP1359523A1 (en) * 2002-05-02 2003-11-05 Accenture Global Services GmbH A tax transaction system
US20100004981A1 (en) * 2002-07-12 2010-01-07 Elazar Katz Dynamic anti-money laundering system and methodology for providing situational-specific risk assessment determinations
US7412418B2 (en) * 2002-12-06 2008-08-12 Ocwen Financial Corporation Expense tracking, electronic ordering, invoice presentment, and payment system and method
US8458067B2 (en) * 2003-05-06 2013-06-04 American Express Travel Related Services Company, Inc. System and method for emergency tracking
EP1792284A1 (en) * 2004-09-24 2007-06-06 France Télécom System for paying vendor goods and services by means of prepaid buying tickets
US20120185373A1 (en) * 2005-10-14 2012-07-19 Financial Intergroup Holdings Ltd. Registry of u3 identifiers
US8055575B2 (en) * 2005-10-14 2011-11-08 Financial Intergroup Holdings, Ltd. Central counterparty for data management
US20070282726A1 (en) * 2006-06-05 2007-12-06 Rim Tec, Inc. Method and system for identifying and managing currency exposure
US7752107B1 (en) * 2007-02-28 2010-07-06 Island Intellectual Property Llc System and method for managing aggregated accounts
US8099345B2 (en) * 2007-04-02 2012-01-17 Bank Of America Corporation Financial account information management and auditing
US20090037332A1 (en) * 2007-07-31 2009-02-05 Janice Cheung Systems and Methods for Processing Banking Transactions
US8712888B2 (en) * 2007-12-28 2014-04-29 Mastercard International Incorporated Methods and systems for assessing sales activity of a merchant
CA2706151A1 (en) * 2009-11-16 2011-05-16 Mundip S. Bhinder Seamlessly capturing transactional data at the merchant's point of sale environment and creating electronic receipts, all in real-time
US8768802B2 (en) * 2009-12-03 2014-07-01 Visa U.S.A. Inc. System and method of matching financial transaction records to merchant records of a merchant profile database
US20110208586A1 (en) * 2010-02-25 2011-08-25 Bank Of America Corporation Leveraging Demographic Data for Advertising Purposes
US20130024274A1 (en) * 2011-07-19 2013-01-24 Mastercard International Incorporated Method and system for measuring advertising effectiveness using microsegments
US20130304555A1 (en) * 2012-05-14 2013-11-14 Mastercard International Incorporated Method and system for applying coupon rules to a financial transaction
US20140006282A1 (en) * 2012-06-27 2014-01-02 Mastercard International Incorporated Methods and systems for connecting multiple merchants to an interactive element in a web page
US20140025444A1 (en) * 2012-07-23 2014-01-23 Payurtoll LLC Universal Toll Tag Device and Systems and Methods to Automate Toll Payments
US8554647B1 (en) * 2012-11-30 2013-10-08 Bank Of America Corporation Location-based categorization prompting of transactions
US20140180767A1 (en) * 2012-12-20 2014-06-26 Mastercard International Incorporated Method and system for assigning spending behaviors to geographic areas
WO2014121151A1 (en) * 2013-02-01 2014-08-07 Freshstart Systems Inc. Distributed sales efficiency management system
US20140249917A1 (en) * 2013-03-01 2014-09-04 Mastercard International Incorporated Method and system for a hosted merchant and cardholder transaction cache
EP2965293A4 (en) 2013-03-09 2016-11-09 Paybook Inc Thematic repositories for transaction management
US10366457B2 (en) 2013-03-09 2019-07-30 Paybook, Inc. Thematic repositories for transaction management
US9563920B2 (en) 2013-03-14 2017-02-07 Operartis, Llc Method, system and program product for matching of transaction records
US20150052035A1 (en) * 2013-08-15 2015-02-19 Bank Of America Corporation Shared account filtering of e-receipt data based on email address or other indicia
US9542710B1 (en) * 2013-09-19 2017-01-10 Intuit Inc. Categorizing financial transactions based on business preferences
US20150100467A1 (en) * 2013-10-09 2015-04-09 Bank Of America Corporation Analyzing transaction item-identifying data to determine which items in the transaction to assign to individuals of a group associated with the transaction
US20150161606A1 (en) * 2013-12-11 2015-06-11 Mastercard International Incorporated Method and system for assessing financial condition of a merchant
US20150302406A1 (en) * 2014-04-18 2015-10-22 Mastercard International Incorporated Methods and systems for improving accurancy of merchant aggregation
US20150302405A1 (en) * 2014-04-18 2015-10-22 Mastercard International Incorporated Method and system for validation of merchant aggregation
US20150356545A1 (en) * 2014-06-09 2015-12-10 Ralph Edward Marcuccilli Machine Implemented Method of Processing a Transaction Document

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110208663A1 (en) * 2004-03-19 2011-08-25 Kennis Peter H Extraction of transaction data for compliance monitoring

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
QUICKEN(R: "Getting Started with Quicken Home & Business", MANUAL [ ONLINE ] INTUIT, 2006, XP055290595, Retrieved from the Internet <URL:http://http-download.intuit.com/http.intuit/CMO/quicken/support/Getting_Started_with_Quicken_Home_and_Business.pdf> [retrieved on 20140527] *
See also references of EP2965293A4 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10121208B2 (en) 2013-03-09 2018-11-06 Paybook, Inc. Thematic repositories for transaction management
US10366457B2 (en) 2013-03-09 2019-07-30 Paybook, Inc. Thematic repositories for transaction management
WO2018152377A1 (en) * 2017-02-15 2018-08-23 Paybook, Inc. Thematic repositories for transaction management
US20220277321A1 (en) * 2019-08-14 2022-09-01 Paybook, Inc. Systems and processes that augment transparency of transaction data

Also Published As

Publication number Publication date
MX2015012116A (en) 2016-04-06
US10121208B2 (en) 2018-11-06
EP2965293A1 (en) 2016-01-13
CA2941355A1 (en) 2014-10-09
MX361879B (en) 2018-12-18
BR112015022133A2 (en) 2017-07-18
EP2965293A4 (en) 2016-11-09
US20160027124A1 (en) 2016-01-28
HK1220281A1 (en) 2017-04-28
CL2015002536A1 (en) 2016-08-26
BR112015022133A8 (en) 2019-11-26

Similar Documents

Publication Publication Date Title
US10121208B2 (en) Thematic repositories for transaction management
US10366457B2 (en) Thematic repositories for transaction management
AU2018201228B2 (en) Employee Payroll Information Management
RU2451337C2 (en) Card-based rule enforcement in program
US7181420B2 (en) Methods and systems for online self-service receivables management and automated online receivables dispute resolution
US8626617B1 (en) Method and system for identifying fixed asset transactions from multiple financial transactions
US20140244490A1 (en) Bill paying systems and associated methods
US20130268440A1 (en) Gift Transaction Processing System and Method
US8744962B1 (en) Systems and methods for automatic payment plan
US10956989B2 (en) Accounting platform functionalities
US20130060692A1 (en) Access Control for a Financial Account
JP2003504701A (en) Portfolio investment guidelines / compliance and financial fund management system
US20230252467A1 (en) Predicting and making payments via preferred payment methods
US20210166330A1 (en) Accounting Platform Functionalities
US8458095B2 (en) Location-based rules for a financial account
US20160034895A1 (en) Personalized budgets for financial services
WO2017212339A1 (en) System and method of communicating requests and responses using a communications network
US11928671B2 (en) Systems and methods for dynamic allocation of resources using an encrypted communication channel and tokenization
US8914306B1 (en) Systems, methods, and devices for printing debit cards and checks
US10453040B1 (en) System and method for making and tracking government-related payments in a cross-jurisdiction payment environment
EP3583523A1 (en) Thematic repositories for transaction management
US11829975B1 (en) User categorization of transactions at moment-of-sale using mobile payments
US20230368200A1 (en) Systems and methods for generating virtual payment objects for preapproved expenses
US20130173328A1 (en) Computerized system and method for managing injection of resources into a flow of multiple resource utilization events
US20140058925A1 (en) Apparatus, method and article to automate and manage formula or asset-based lending in a networked environment

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14780012

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: MX/A/2015/012116

Country of ref document: MX

Ref document number: 14774047

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2014780012

Country of ref document: EP

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112015022133

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2941355

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 112015022133

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20150909