JP7466638B2 - Code generation and tracking for automatic data synchronization in data management systems. - Google Patents

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. Patent Application Publication No. 16/664,592, filed October 25, 2019, and U.S. Patent Application Publication No. 16,664,694, filed October 25, 2019, which are incorporated by reference in their entireties.

Technical field
[0002] This application relates generally to data tracking through networked control systems, and more particularly to the generation of alphanumeric codes and image processing for automatic allocation of receipt data to stored data in a transaction database.

background
[0003] Organizations such as businesses and corporations require various types of data to be tracked, such as by users of expense management software, hardware, and other infrastructure to manage expenses and regulate user transactions. This includes issues related to establishing and issuing payment instruments, tracking expenses and other accounting requirements, enforcing expense policies, and collecting audit information, including receipts and other transaction history data. However, current networked systems and available corporate infrastructures only provide for a few specific administrators who are required to manually review and approve payments, as well as collect audit information and allocate expenses to specific categories, clients, and other classifications. These accounting teams or corporate officers are then required to personally review expenses and assign audit data, expenses to category classifications. This is burdensome for small companies that may have limited employees and offices, and large companies whose expenses may be brought by a wide range of employees that make it difficult to track and receive data appropriately. However, without receiving audit data and expense allocation information, companies may be at risk for fraud or legal issues.

[0004] Current systems used to track and manage transactions within a company may require the submission of reimbursements or the use of company payment instruments. Reimbursements require significant manpower and may present issues with employee abuse of the system and non-conforming expense category classification by employees. However, the use of company payment instruments may expose the company to fraud risks if proper audit and expense category classification procedures are not implemented. However, the collection of this data, such as receipts, employee activities and tasks, and other information, is difficult and requires active participation from employees. Thus, these current systems are unable to identify user and company attributes during transaction processing, allocate expenses to specific expense categories, and collect audit data without requiring employee input, thereby presenting difficulties and a potential lack of needed accounting data.

[0005] Thus, there is a need to address the deficiencies in traditional systems used by companies to better assign incoming data to specific data category classifications and classifiers for processing.

BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 is a block diagram of a networked system suitable for implementing the processes described herein, according to one embodiment. 1 is an exemplary receipt including an authorization code and a transaction identifier used for receipt capture and data tracking with an expense management system, according to one embodiment. [0008] FIG. 1 is an exemplary system environment for matching receipt data to expense data in a transaction database, according to one embodiment. [0009] FIG. 1 is an exemplary system environment for synchronizing application scheduling data with expense data in a transaction database, according to one embodiment. [00010] FIG. 2 is an exemplary flow chart for receipt code generation and image processing tracking for receipt data synchronization in an expense management system, according to an embodiment. [00011] FIG. 2 illustrates an exemplary flow chart for application data synchronization based on application integration for automatically categorizing expense data, according to an embodiment. [00012] FIG. 2 is a block diagram of a computer system suitable for implementing one or more components of FIG. 1, according to one embodiment.

[00013] The embodiments of the present disclosure and their advantages are best understood by reference to the following detailed description. It is to be understood that like reference numerals are used to identify like elements shown in one or more of the figures, which are illustrated in the figures for purposes of illustrating, and not for purposes of limiting, the embodiments of the present disclosure.

Detailed Description
[00014] A method is provided for code generation and tracking for automatic data synchronization in a data management system. A system suitable for implementing the method of the present disclosure is also provided.

[00015] The online expense management system may provide a data aggregator that monitors the bank accounts and other financial accounts of the organization to perform data aggregation and categorization of expense data. This expense data may be required for auditing and expense management services such as receipt data tracking and allocation of expenses to organization, company or employee clients, expense categories, etc. The financial accounts may include one or more credit accounts, debit cards, Automated Clearing House (ACH) direct debits/credit card debits, wire transfers, gift certificates, and other types of funding sources that may be issued to the organization by the online expense management system and/or other financial service providers. Thus, the networked expense management system and provider may include a framework and architecture for providing payment gateways, billing platforms, e-commerce platforms, invoicing, and further services. For example, the service provider may provide services, software, online resources, and portals, and infrastructure used to manage expenses, purchases, and other financial transactions of the organization (e.g., a business or company). The system may provide an electronic framework that is integrated into the payment network and the company's computing infrastructure at the time to enable automatic categorization and matching of data for auditing and expense management services. For example, integration of the framework at the time between the issuing bank and the acquiring bank can enable transaction data to be received in real time, so that the framework can perform the real-time process of data matching and category classification. This allows for real-time data processing necessary for receipt accounting audits. Additionally, the system's framework can be integrated with one or more client devices (e.g., personal computers, mobile devices, etc.), online scheduling resources, personnel management systems, and/or enterprise business software to receive scheduling, calendars, and/or other time allocation systems for use with expense data category classifications.

[00016] For example, the expense management system may provide expense policies that include variable user settings, class designations, and expense category classifications for organizational expense categories (e.g., travel, business activity expenses (including payroll, office supplies, and technology, etc.), client expenses (including travel, food, beverages, gifts, meetings, etc.), information technology, and other expenses). A user class may correspond to one or more users within an organization's group, such as sales, management, corporate executives, information technology, etc. There may be sub-designations within a class, such as by title, team, role, location, or another attribute. An organization may further generate expense policies, which may include expense attributes such as overall restrictions, approval restrictions, restricted/prohibited merchants or types of purchases, time-specific restrictions, types of transactions approved, and other restrictions, permissions, or rules. Expense policies may correspond to broader categories of the above-mentioned expense categories and may be organization-wide or by user class. Expense policies may also include subcategories of the above-mentioned expenses, such as by expense type, by client, etc. Finally, the organization may be asked to select a payment network to be utilized for issuing and processing the payment instruments, which may include payment cards, direct debits, wire payments, or other types of funding sources. The payment network may correspond to a resolution network for processing payments for expenses purchased using account identifiers, payment cards, and the like during electronic and in-person transaction processing. Some embodiments of the payment network and expense management are described in further detail in U.S. Patent Application Publication No. 16/238,498, filed January 2, 2019, entitled "Electronic Framework and Networked System for Variable Class Designations and Policies," and U.S. Patent Application Publication No. 16/238,503, filed January 2, 2019, entitled "Intelligent Recommendations for Dynamic Policies Used in Real-Time Transactions," both of which are incorporated herein by reference.

[00017] One or more payment instruments may be issued to users or employees of an organization, including sales, management, information technology, or other employees. The payment instruments may correspond to various types of payment cards and/or account identifiers that may be issued by the expense management system or associated affiliates (e.g., an issuing bank that provides credit cards or another financial instrument). In the course of business, employees may engage in commercial transactions with one or more merchants using the payment instruments, such as by making in-person (e.g., at a merchant's location or store) or online purchases from the merchant. Thus, a user may request electronic transaction processing by an account number or one or more payment instrument identifiers provided to the user. A merchant (e.g., a seller or payment recipient, such as a business, a fundraiser, a medical service provider, a landlord, etc.) may correspond to a person or entity that sells goods and/or services (referred to herein as one or more "goods") to employees of the company. Through integration with the organization's enterprise resource planning (ERP) software and infrastructure, the banks used by the organization, the organization's individual cardholders, and issuers (e.g., sources of offered payment instruments on a payment network), the expense management system framework can receive real-time data of transactions, for example, before the transactions are authorized and resolved through such entities. Thus, the expense management system can approve or deny transactions in real-time based on expense policies and categorizations.

[00018] Additionally, the expense management system can generate, receive, and/or request audit data in real time with the transaction. The audit data can include alphanumeric or other code generation, enter the data into a receipt or other transaction history or record, and match the receipt data with the transaction or expense management data. Receipt matching can be done by code matching between a code stored with the transaction data determined at the time the transaction processing request was made and data later received from the organization and/or user that requested the transaction, such as an image of the physical receipt or a copy of the electronic receipt. This can allow the system to quickly receive data over the network, perform data matching, and store audit data regarding expenses to the merchant as payments are requested and processed.

[00019] To process payments, the expense management system may receive transaction data for a payment request from a payment network, for example, when an acquirer (e.g., a merchant's acquiring bank that processes a payment instrument provided by a user) requests processing from an issuer (e.g., the organization's issuing bank and the expense management system that issues the payment instrument). This occurs when a user originates a transaction, the merchant generates a total for the transaction request, and the user can pay for that total by providing the payment instrument to the merchant. After receiving the payment instrument, the merchant can originate a payment request for payment of the transaction. In various embodiments, the user may be prompted to enter additional checkout information, such as name, shipping location, or other personal or financial information that may be included in the transaction data for the transaction. In some embodiments, the payment instrument may be pre-tokenized by the expense management system to further protect against fraud, with the digital token enabling back-end identification of the payment instrument to the issuer and/or expense management system without exposing the payment credentials.

[00020] The expense management system may receive or detect transaction data for electronic transactions. In response to receiving or detecting the transaction data, the system may generate one or more codes, such as an alphanumeric code, a bar code, a quick response (QR) code, etc. In some embodiments, the code may correspond to, for example, a first authorization code for the transaction when the transaction is approved and a transaction identifier code that uniquely identifies the transaction itself. The code may correspond to a six-digit or letter code, or may be shorter, longer, or different. In some embodiments, the length and/or type of code may be generated to prevent collisions within an organization's expenses and/or with other organizations (e.g., code matching of two or more different transactions, especially transactions with similar transaction data), which later facilitates code matching for auditing purposes. The codes may be stored with the transaction data detected and/or received by the system. These codes may then be transmitted to a merchant's device or server that processes the transaction data. Additionally, the system can use a transaction history or record of the transaction, such as a physical receipt or a digital receipt sent electronically to the device or account (e.g., a user's email, text message, etc.), to cause the merchant's device or server to output a code. The code can be placed in a specific area of the receipt, which can aid in image processing for identification of the code on the receipt. For example, the authorization code and/or transaction identifier can be aligned with a "total" line, a "signature" line, a transaction time line, a merchant identifier or address, or other lines on the receipt so that the expense management system can more easily identify the code on the receipt.

[00021] Once the receipt is provided to the user, the user may image the receipt and submit the receipt to the expense management system or may submit a digital receipt through another communication channel or data submission portal. In some embodiments, the expense management system may send an electronic message (e.g., an email, a Short Message Service (SMS) or Multimedia Messaging Service (MMS) text message, an instant message, etc.) to the user's device associated with the payment card identifier for the transaction requesting that the user image the receipt and send it back or otherwise submit a digital receipt. However, in other embodiments, the user may do so after the fact, such as when submitting expenses to the system, and the organization may not require immediate receipt imaging and submission. Thus, the expense management system may receive a digital form of the receipt that may be processed to identify one or more codes on the receipt.

[00022] Using optical character recognition (OCR) and/or other data parsing and image processing, the system can determine the codes and data on the receipt and match them with the transaction data received on the payment network. For example, if one or more codes are used, OCR or other image processing can be used to identify and locate one or more codes on the receipt. The OCR process can segment the receipt data to identify one or more codes in the data, which can be identified by character recognition and matching against stored codes by the system. In some embodiments, during data segmentation, lines can be traced at a particular angle (such as parallel or perpendicular to the axis of the receipt) from the receipt data to identify one or more codes. For example, if one or more codes are output on a line containing the "total" of a transaction, lines can be traced to the right or left from the identified "total" line or amount to identify the code data on the receipt. OCR or other image processing may also be used to extract further receipt data such as merchant name/identifier, transaction time, total or other receipt data. Once code data is identified on the receipt, the code data can be used to search the expense management system's transaction database to identify matching transaction data. Matching the receipt code to the transaction code using the transaction data in the database can be used to save a receipt image or digital copy and further extract further receipt data for storage with previously received/detected transaction data. This provides a more robust audit, expense data collection and management system.

[00023] In some embodiments, a scoring system may also be implemented to score matching characteristics, codes and/or transaction data between the receipt, the stored transaction data and the stored code to perform receipt matching against transaction data that provides audit data based on receipt storage and parsing and input of additional transaction data. The scoring system may utilize the code, the time associated with the transaction data and on the receipt, and additional extracted transaction data to determine the most likely match based on the highest score or value between matching characteristics of the receipt and the stored transaction data with the transaction code. In some embodiments, one or more of the codes may be missing from the receipt, for example, if the merchant's hardware and/or software infrastructure does not allow one or more codes to be added to the receipt. In such embodiments, the identified codes may be further processed to identify matching transaction characteristics, codes and data in the expense management transaction database using other data extracted from the receipt, such as the merchant identifier, address, item, total amount, tax, tip, user identifier, card number, etc. Once matching characteristics are found, each matching transaction can be scored, for example, by similar characteristics between the stored transaction data, the code, and the extracted receipt data to identify the most likely match. The most likely match can then be used to store the receipt along with the previously obtained transaction data.

[00024] In some embodiments, a fingerprint database of merchant receipts may be generated and utilized to determine where code data may be printed or added to a physical or digital receipt. For example, during merchant integration and/or when merchants and organizations utilize expense management systems, merchant receipts may be received for the same or similar merchants or for merchants that utilize the same or similar POS devices, online marketplaces, or other processes for providing receipts to users. These receipts may be processed by a learning algorithm to identify similarities between receipts and receipt formats. Additionally, the placement and usage of codes on the same or similar receipts may be used to "fingerprint" merchants and identify their receipt types and formats. Thus, when a merchant presents a receipt, the system may utilize the fingerprints of previous receipts to identify the placement of data on the receipt, which simplifies OCR or other image processing operations. This allows for faster extraction of data from merchant receipts.

[00025] The receipt data may also be used to extract transaction features used to categorize the transaction with the organization's expense policy. For example, the user presenting the receipt, the receipt item, the receipt time, the merchant, and/or the location may each be used to further categorize the transaction within the expense policy. Such categorization may occur automatically without user selection of an expense category or identification. The expense management system may also provide one or more application or platform integrations with scheduling systems to obtain further transaction data utilized in categorizing the transaction. For example, the expense management system may integrate with one or more mobile device or personal computer scheduling, calendar, or other personal management applications that include the organization's user appointment, meeting, travel, and other engagement schedules. The expense management system may also integrate at a higher level than one or more specific applications, such as online platforms that track user and/or organization scheduling and provide scheduling for resident device applications and/or web applications. Such integrations may include integration with Outlook®, Google Calendar®, and the like.

[00026] In this regard, once transaction data for a transaction is detected, received and/or stored/processed by the expense management system, the expense management system can pull data corresponding to the transaction data for that transaction from the application, platform and/or database. In other embodiments, this data can be forwarded to the system at the time of the transaction or periodically and/or otherwise accessed by the system. The system can utilize scheduling and calendar data at the time of the transaction for the user submitting the transaction for processing and/or expense reporting to determine further transaction data and automatically categorize the transaction. The data can include the user's current activity or behavior, client name, phone number, email, user/client identifier, email address, one or more locations, activity/meeting theme or name or other information necessary to define the user's activity at the time of the transaction. The scheduling data can be matched based on the time of the activity and transaction and further information in the scheduling data. For example, the user's location at the time of the transaction can be further determined using a GPS or other location detection component of the user device of the user making and submitting the transaction, which can be further used to determine the user's schedule. Other data integrations can be used to gather additional data to categorize transactions, such as email/messaging data between users and/or clients, meeting room reservations using a separate scheduling component, travel planning using a travel booking system, etc.

[00027] Further data regarding the transaction determined using the scheduling data may be stored with the previously obtained transaction data. In addition, the expense management system may provide automatic categorization and subcategorization of transactions and expenses into expense policies and subparameters within the expense policies. For example, using the subject of the meeting and the name of the client, the transaction may be assigned to the client and added to the client's expense policy (e.g., sales expenses) associated with the user class to which the user belongs. Other scheduling information may be used to select a subcategory for the client and/or user class, such as "food" if the client was taken out to lunch or dinner, or "meeting preparation," or a "travel" expense category. Calendar information may be used to assign the transaction as an internal expense or an external expense that may be used by the organization to bill clients and/or users. For example, expenses incurred during business trips are typically billed to the organization as necessary expenses, but if location or other scheduling and/or transaction data indicates that it is not acceptable under the user's expense policy, the expense may be billed to the user instead. Expense classification and categorization can be done automatically using application, platform and other data integrations, which does not require active user input to select expense categories.

[00028] In various embodiments, other types of card data, transaction data, messages/communications, or other context data may be used to assign expenses to specific categories, clients, and/or system users. Further context data may be any data associated with a transaction that may be detected and/or determined by the expense management system. For example, types of card data may include level 2 (L2 or Level II) and/or level 3 (L3 or Level III) card or transaction data that involves a credit or debit card transaction when the transaction is processed. L2 and/or L3 card data may include purchase order number, shipping address or zip code, billing address or zip code, destination location, tax label and/or amount, consumer and/or merchant name, item identifier (including SKU, bar code, QR code, etc.), item description or name, price, number or amount of item, discount or applied gain, merchant information including merchant name and/or code, address or location, and similar data that may be used to further define the transaction and provide more detailed transaction information. For example, billing dispatch codes can be used to determine transaction information and assign the transaction to a category. Similarly, this card data can be used to determine where an employee is transacting, purchasing, traveling, or otherwise performing transactions on behalf of the company that should be expensed to a particular category. For example, a purchase of airplane tickets may include the destination city as part of the card data, which may inform the system of the client or other expense category for the ticket purchased. Similarly, multiple purchases with consumer/client/employee identification information can be used to assign each purchase to a particular category (e.g., two tickets purchased with a client/employee name on one ticket may specify that both tickets should be expensed to that particular entity).

[00029] L2 or L3 card data may be provided and processed during a transaction to provide more detailed information about the transaction, to enable better authentication and security, to lower card processing fees, and/or for analysis and protection against fraud. Thus, the L2 or L3 data may provide more granular transaction data that may be matched to expense category classifications including client, employee, and/or expense purpose. Thus, the L2 or L3 card data may be used in conjunction with data for an organization's expense management system to assign transactions to specific categories. The L2 or L3 card data may be intercepted by the expense management system during transaction processing and/or authorization so that transactions may be assigned to specific expense categories. For example, when a corporate credit card tied to or provided by the expense management system is used, the L2 or L3 card data may be obtained during transaction processing.

[00030] Communications may be accessed and analyzed (e.g., by keyword analysis or text extraction and processing) to identify expense category classifications and assign expenses to categories. For example, members or employees of an organization may send messages stating the intent of the expense (e.g., "Would you like to attend lunch during the conference?" sent to a client). Messages may also be exchanged between members when transactions are processed using a corporate credit card or account. These message exchanges (including within the same geofenced area or within close proximity) may indicate a categorization of expenses, such as for a conference or within a particular employee class or group. An employee or member of an organization may send a message to another member or client of the organization at an event, which may also be used to determine that expenses at the event should be assigned to a particular categorization, such as a particular expense account associated with the client. For example, messages shared between a client and an employee at an event may indicate that a transaction at the event using the corporate card/account should be charged as a necessary expense to or on behalf of the client (e.g., email exchanges mentioning the event and including the purpose of the expense).

[00031] In some embodiments, other applications on the mobile device associated with the user processing the transaction may be queried for data or data may be pulled from these applications. These other applications may include location detection and/or mapping, voice communication (e.g., telecommunications or VoIP), text or instant messaging, social networking, microblogging, media sharing, ticketing, travel, food and other mobile applications. Data from the applications may be used to infer expenses for the transaction based on similar past data or may be used to further determine transaction data (e.g., transaction location, messages between employees and clients, etc.). For example, a ticket purchase to an airport associated with or located near the client and/or associated with a person associated with the client may be used to categorize the purchase as a business trip to that particular client. Other examples include reservations made at a client's favorite restaurant, reservations made in the client's immediate vicinity, ticket purchases for events (such as sporting events, shows or concerts) that may be associated with the client (such as the client's past interests or previous similar purchases), lodging reservations made near the client, and/or purchases of gifts known to be of interest to the client, for example related to a hobby or goal. Using the application data, the expense management system may be able to determine more granular data about the transaction for automated expense management and allocation for the transaction. Note that the data does not have to be from an application on the user device, but may be obtained by harvesting public sites for content, such as on a travel forum, chat boards where users/employees mention upcoming scheduled business trips for clients.

[00032] Historical data may also be utilized along with current contextual data to assign expenses to categories. For example, if two or more members of an organization have previously purchased airplane tickets or event tickets together and are purchasing the same or similar tickets again, the previous expense category for the previous purchase may be determined and the current expense may be assigned to the same or similar category. Additionally, travel or event tickets for the same member of the organization (e.g., in the same department) may be used to infer expense category classifications based on expense data entered by one of the users or previous expense category classifications for similar expenses. Similarly, if an employee purchases tickets or attends an event with a client (including purchasing tickets or paying for expenses at the event for the client), the expense category classifications used for the event and/or client for the previous expenses may be used for the current expense as well.

[00033] Thus, a system and method are provided to enable companies to better manage electronic transaction data, including reimbursement or pre-approval requests, from employees and contractors in real time to reduce fraud and the computing resources typically required by conventional systems. Furthermore, the system provides real-time data aggregation used for auditing purposes so that organizations can better collect and monitor data. In addition, the expense management system can utilize application integration to assign transaction data to specific category classifications without requiring input from a user and in real time.

[00034] FIG. 1 is a block diagram of a networked system 100 suitable for implementing the processes described herein, according to an embodiment. As shown, the system 100 may include or implement a number of devices, servers and/or software components operable to perform various techniques according to the described embodiments. Exemplary devices and servers may include devices, standalone and enterprise-wide servers operating an OS such as MICROSOFT® OS, UNIX® OS, LINUX® OS or another suitable device and/or server-based OS. It may be understood that the devices and/or servers shown in FIG. 1 may be arranged in other ways and that operations performed and/or services provided by such devices and/or servers may be combined or separated for an embodiment and performed by a greater or lesser number of devices and/or servers. One or more devices and/or servers may be operated and/or maintained by the same or different entities.

[00035] The system 100 includes a user device 110, a card identifier 130, an expense management system 140, a payment resolution network 160, and a merchant device 170 communicating over a network 180. A user (not shown) may correspond to an employee, contractor, shareholder, or other suitable person (not shown, generally referred to herein as an "employee") of a company associated with the user device 110 who may utilize the card identifier 130 to submit a purchase requisition for an item to be paid for using company funds. The card identifier 130 may correspond to a payment instrument that allows for the purchase of items using company funds, which may be provided and managed by the expense management system 140. The expense management system 140 may process payments using the payment resolution network 160. Additionally, the expense management system 140 may receive receipts and scheduling data from the user device 110 for use in collecting audit data and expense categorization.

[00036] User device 110, expense management system 140, payment resolution network 160, and merchant device 170 may each include one or more processors, memory, and other suitable components for executing instructions, such as program code and/or data stored on one or more computer-readable media to implement the various applications, data, and steps described herein. For example, such instructions may be stored on one or more computer-readable media, such as memory or data storage devices, that are internal and/or external to the various components of system 100 and/or accessible over network 180.

[00037] The user device 110 may be utilized by employees of an organization or company that employs one or more users, for example, to provide receipts and scheduling data to the expense management system 140. For example, in some embodiments, the user device 110 may be implemented as a personal computer (PC), a telephone device, a smartphone, a laptop/tablet computer, a watch with appropriate computer hardware resources, glasses with appropriate computer hardware (e.g., GOOGLE GLASS®), other types of wearable computing devices, implantable communication devices, and/or other types of computing devices capable of transmitting and/or receiving data. In this regard, the user device 110 includes one or more processing applications that may be configured to interact with the expense management system 140 to manage payment instruments provided by the expense management system 140 and to further provide data utilized by the expense management system 140. Although only one communication device is shown, multiple communication devices may function similarly.

[00038] The user device 110 of FIG. 1 includes a receipt capture component 120, a scheduling application 112, other applications 114, a database 116, and a network interface component 118. The receipt capture component 120, the scheduling application 112, and the other applications 114 may correspond to executable processes, procedures, and/or applications having associated hardware. In other embodiments, the user device 110 may include additional or different modules having dedicated hardware and/or software as necessary.

[00039] The receipt capture component 120 may be implemented as dedicated hardware and/or software utilized by the user device 110 to capture a user's receipt and transmit the receipt to the expense management system 140 for processing. For example, the receipt capture component 120 may correspond to a software application having a corresponding camera 122 that allows the user device 110 to capture an image of a physical or digital receipt, which may include camera functions such as still/video image capture, zoom, image adjustments, and other image rendering processes. In other embodiments, a digital receipt may be received by the user device 110 using a text message, email, or other communication channel, etc. In response to receiving or capturing a digital copy of the receipt, the receipt capture component 120 may transmit the receipt to the expense management system 140. The receipt may then be processed by the expense management system 140 based on one or more codes entered on the receipt as described herein. In various embodiments, the receipt capture component 120 may include a general browser application configured to retrieve, present, and communicate information over the Internet (e.g., utilizing resources on the World Wide Web) or a private network. For example, the receipt capture component 120 may provide a web browser that may transmit and receive information over the network 180, including retrieving website information, presenting website information to a user, and/or communicating information to a website (including payment information). However, in other embodiments, the receipt capture component 120 may include specialized applications of the expense management system 140 or other entities that may be configured to assist in establishing and maintaining user classes, expense policies, and payment networks.

[00040] The scheduling application 112 may be implemented as dedicated hardware and/or software utilized by the user device 110 to provide scheduling information to the expense management system 140 for use in allocating expenses to particular category classifications. In this regard, the scheduling application 112 may correspond to personal management software, hardware, and data utilized by a user associated with the user device 110 to input, store, and process data associated with a schedule, calendar, or other personal management information. The scheduling application 112 may include appointment, trip, meeting, reservation, and other types of calendar information for the user. The scheduling application 112 may be integrated with the expense management system 140, for example, by providing the user's scheduling data at the time of the transaction such that data may be shared with the expense management system 140 in connection with the transaction. In some embodiments, the scheduling application 112 may store and process scheduling data stored directly on the user device 110. However, in other embodiments, the scheduling application 112 may access online platforms and databases that provide scheduling operations and data.

[00041] In various embodiments, user device 110 includes other applications 114 as may be desired in a particular embodiment to provide functionality to user device 110. For example, other applications 114 may include security applications for implementing device-side security features, program client applications for interfacing with appropriate application programming interfaces (APIs) over network 180, or other types of applications and processes. Other applications 114 may include software programs executable by a processor, including a graphical user interface (GUI), configured to provide an interface to a user in accessing one or more processes or in receiving and displaying data associated with user device 110 and/or expense management system 140.

[00042] The user device 110 may further include a database 116 stored in temporary and/or non-transient memory of the user device 110 in which various applications and data may be stored and utilized during execution of various modules of the user device 110. Thus, the database 116 may include, for example, identifiers such as operating system registry entries, cookies associated with the receipt capture component 120, the scheduling application 112 and/or other applications 114, identifiers associated with the hardware of the user device 110, or other suitable identifiers such as identifiers used for payment/user/device authentication or identification. The database 116 may include data received from the expense management system 140, such as payment request data, cardholder statements, authorization requests, and data transmitted to the expense management system 140 (e.g., data from the receipt capture component 120 and/or the scheduling application 112).

[00043] The user device 110 includes at least one network interface component 118 adapted for communication with the expense management system 140, the payment resolution network 160, and/or the merchant device 170. In various embodiments, the network interface component 118 may include a DSL (e.g., digital subscriber line) modem, a PSTN (public switched telephone network) modem, an Ethernet device, a broadband device, a satellite device, and/or various other types of wired and/or wireless network communication devices.

[00044] The expense management system 140 may be maintained, for example, by an online service provider that may provide payment instruments and expense management services to businesses and other organizations. In this regard, the expense management system 140 includes one or more processing applications that may be configured to interact with the user devices 110, the payment settlement network 160, and the merchant devices 170 to facilitate the processing of payments and the enforcement of expense policies with respect to payment instruments, such as the payment instruments associated with the card identifiers 130. In one example, the expense management system 140 may be provided by BREX®, Inc. of San Francisco, California, USA. However, in other embodiments, the expense management system 140 may be maintained by or include other types of credit providers, financial service providers, and/or other service providers that may provide expense management services to businesses.

[00045] Expense management system 140 of FIG. 1 includes expense management application 150, other applications 142, database 144, and network interface component 146. Expense management application 150 and other applications 142 may correspond to executable processes, procedures, and/or applications having associated hardware. In other embodiments, expense management system 140 may include additional or different modules having dedicated hardware and/or software as needed.

[00046] The expense management application 150 may correspond to specialized hardware and/or software for enabling a company to receive payment instruments associated with the company's bank accounts and funds, such as one or more company credit cards, and provide expense management regarding these issued payment instruments and further funds/accounts of the company. In this regard, a company may first open an account with the expense management system by providing company data and on-boarding by the expense management application 150. Such information may include bank account and fund information, such as confirmed funds from investors, funds directly available in the account, and burn rate of company funds over a period of time. Upon meeting eligibility requirements, the expense management system 140 and/or another issuer may provide a payment instrument to be managed by the expense management application 150. For example, the expense management system 140 may issue a card identifier 130 of an actual or virtual credit card, or other type of payment instrument and instrument identifier that may be used for payments of the company.

[00047] The expense management application 150 may provide one or more processes accessible by an administrator of an organization to define settings and preferences necessary for enforcement of expense policies and approval/denial of payment requests using issued payment instruments such as card identifiers 130. In this regard, the administrator may define a user class and select an expense policy, which corresponds to attributes related to payment amounts acceptable under that policy, such as maximum purchase amount, maximum payment amount over a period of time, merchant/item type, location, time of purchase, etc. The expense management application 150 may further provide additional processes for use with the expense management policies of the organization, such as receipt matching operations 152 and schedule allocation operations 154. Further functionality and processes provided by the expense management application 150 are described in more detail with respect to further views of the application, such as FIGS. 2A, 2B, 3, 4, and 5.

[00048] The receipt matching operation 152 may correspond to a process by which a code that can later be used for receipt matching may be generated for output on a receipt for a transaction. The receipt matching operation 152 may detect a transaction occurring using the card identifier 130 for the merchant device 170, for example, by the expense management application 150 receiving transaction data for processing based on the organization's expense policy. The one or more codes may include an authorization code based on authorization of the transaction for processing and a transaction identifier that identifies the transaction. The receipt matching operation 152 may cause the one or more codes to be output or displayed on a receipt, for example, by communicating the one or more codes to the merchant device 170 for printing on the receipt and/or input on a digital receipt. A digital copy of the receipt may then be received by the expense management system 140, and the receipt matching operation 152 may be used to determine the code on the receipt. The code may be identified by OCR or other image processing, text processing of text data on the digital receipt, or other processes. Once a code is identified, it can be used to match the digital copy of the receipt with stored transaction data from the transaction process. The receipt matching operation 152 can further provide a process for scoring a match between the code, the transaction data, and additional data extracted from the digital copy of the receipt (which may occur if one or more codes are not identified on the received receipt data).

[00049] The schedule allocation operation 154 may further provide a process by which the expense management application 150 automatically categorizes expenses based on data about the user at the time of the transaction. The schedule allocation operation 154 may provide application data integration with the scheduling application 112 or other scheduling platforms so that the schedule allocation operation 154 may receive schedule data about the user and the time at which the transaction associated with the schedule occurs. In other embodiments, the schedule allocation operation 154 may be integrated with different applications, processes, or devices to detect additional contextual data. The contextual data may include card data or other transaction data, such as L2 or L3 card data, detected during the transaction based on input by the merchant. The additional contextual data may include communications between parties, such as employees and/or clients of the organization. In some embodiments, content from an application on the mobile device or a public site may be used to further determine the transaction data used for the expense categorization. Additionally, current transaction data may be matched to past transaction data and categorizations so that expense allocations may be made without the user having to select or enter expense categorization options again.

[00050] The schedule allocation operation 154 can retrieve schedule and/or contextual information about the transaction and can process that information to categorize the transaction into an expense type or category. For example, a location, a client's name, a user identifier, or other information can be used to determine the type of expense, the client associated with the expense, or other information about the expense. Communications between the parties can be used to determine the expense based on the content of the message or the identity of the parties exchanging messages. Also, other types of card data, application data, and/or other contextual data can be further used to assign expenses to specific categories. The schedule allocation operation 154 can further be used to assign transactions to organizational expense policies for the user, such as amounts allowed under the policy and whether the transaction is authorized under the expense policy.

[00051] In various embodiments, expense management system 140 includes other applications 142 as may be desired in a particular embodiment to provide functionality to expense management system 140. For example, other applications 142 may include security applications for implementing server-side security features, program client applications for interfacing with appropriate application programming interfaces (APIs) over network 180, or other types of applications. Other applications 142 may include software programs executable by a processor including a graphical user interface (GUI) configured to provide an interface to a user when accessing expense management system 140.

[00052] Additionally, the expense management system 140 includes a database 144. As previously mentioned, a user, entity, and/or organization corresponding to the user device 110 may establish one or more accounts with the expense management system 140, which may be used to issue the card identifier 130. The payment accounts in the database 144 may include entity information such as name, address, payment/fund information, further user financial information, and/or other desired user data. The entity may establish expense regulations and policies for its company, which may be stored in the database 144. The database 144 may also be used to store transaction data and information regarding payment instruments issued to the company and transactions processed using those instruments, including receipts that are categorized or matched to the transactions based on scheduling information.

[00053] In various embodiments, the expense management system 140 includes at least one network interface component 146 adapted for communication with the user devices 110, the payment resolution network 160, and/or the merchant devices 170 over the network 180. In various embodiments, the network interface component 146 may include a DSL (e.g., digital subscriber line) modem, a PSTN (public switched telephone network) modem, an Ethernet device, a broadband device, a satellite device, and/or various other types of wired and/or wireless network communication devices.

[00054] The payment resolution network 160 may correspond to a network utilized for payment request resolution and electronic transaction processing, which may be governed by the authorization (e.g., acceptance and rejection) of a payment request for transaction processing by the expense management system 140. In this regard, the payment resolution network 160 may correspond to a credit card or debit card network where an acquiring bank or acquiring entity may interact with an issuing bank or issuer for resolution of a payment using the card identifier 130. However, in other embodiments, the payment resolution network may correspond to other types of payment networks and types of payments, such as direct debit payments (ACH payments), wire transfers or payments, prepaid card payments, or local/company specific payments. The payment resolution network 160 may be implemented by the expense management system 140 in response to requests by the user device 110 to allow authorized users (e.g., users and classes of users) to interact with the network to submit payments and process transactions, to allow third parties (e.g., banks or other financial services intermediaries) to interact on the network on behalf of users, and/or to access or use data provided to or from the payment network, such as transaction notification and details enabling approval or denial of transactions. Thus, the expense management system 140 may utilize the payment resolution network 160 in managing, approving, denying, and collecting data associated with payment requests using company-issued payment instruments associated with the payment resolution network 160, such as the card identifier 130, which may include transaction data that is examined by the expense management system 140 and added to expense category classifications. In some embodiments, the payment resolution network 160 may include or be connected to the online banking resources of a bank that is utilized by the expense management system 140 to resolve fees and payments processed by the expense management system.

[00055] The merchant device 170 may be maintained, for example, by a merchant or other entity that sells one or more items to users (which may include a single user or a group of independent users) as well as small and large merchants. The merchant device 170 may offer the items for sale, such as through the use of various software, infrastructure, websites, applications, and/or other platforms for advertising, sales, and payment processing. In this regard, the merchant device 170 may include a device having a processing application that may be configured to interact with the user device 110, the expense management system 140, and/or the payment resolution network 160 to conduct transactions using the card identifier 130. In some embodiments, the merchant device 170 may be implemented as a single or networked personal computer (PC), a smartphone, a laptop computer, a wearable computing device, and/or other type of computing device. Although only one merchant device is shown, multiple merchant devices may function similarly.

[00056] The merchant device 170 may be implemented with an application that provides items for sale that may be accessed by a computing device to present the items for sale to a user associated with the card identifier. In certain embodiments, the application may provide a website available on the Internet, and/or online content, and/or database information accessible by a dedicated application. Thus, the application may provide item sales in an online marketplace using the merchant's website. The application may also correspond to a checkout application at a physical merchant location, such as one or more applications of a point of sale (POS) device used to provide sales at the physical location. Once a user/employee associated with the user device 110 selects one or more items for purchase, a transaction may be established using the merchant device 170. Once a payment amount for one or more items purchased by the user is determined, the merchant device 170 may request payment using the card identifier 130. Once entered, the merchant device 170 may then process a payment to the merchant associated with the merchant device 170 using the card identifier 130 and the payment resolution network 160. The expense management system 140 may utilize network integration with the payment resolution network 160 to manage the expense policies of the organization associated with the card identifier 130. Thus, the expense management system 140 may approve or deny the payment request based on the company policy associated with the user device 110. Transaction data may also be provided to the expense management system for automatic expense categorization using the user's calendar. The payment request may then be processed, payment provided to the merchant account, and a notice of payment (or default, for example, if the payment request does not comply with company policy) may be sent to the merchant device 170. The merchant device 170 may then receive the results of the transaction processing and generate a receipt with one or more codes entered into the receipt for expense tracking and auditing purposes.

[00057] Network 180 may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, network 180 may include the Internet or one or more intranets, fixed telephone lines, wireless networks, and/or other suitable types of networks. Thus, network 180 may correspond to a small communications network, such as a private or local area network, accessible by various components of system 100, or a larger network, such as a wide area network or the Internet.

[00058] FIG. 2A is an example receipt including an authorization code and transaction identifier used for receipt capture and data tracking with an expense management system, according to one embodiment. FIG. 2A includes receipt 200a including data used for receipt and transaction data tracking with an expense management system.

[00059] In this regard, the receipt 200a includes one or more codes that may be used for receipt matching by expense management systems and organizational policies. The receipt 200a also includes transaction data, which may be used for receipt matching and/or extraction of further transaction data. For example, the receipt 200a includes a merchant identifier 1000 for a merchant A that caused the transaction based on a transaction request by a user. The receipt 2000a further includes a cashier identifier 1002, a store identifier 1004 and a merchant address 1006 that may be included on the receipt 200a for further information regarding the transaction and the merchant that caused the transaction. Additionally, transaction data including purchased items 1008, tax 1010, tip 1012, total 1014 and signature line 1020 may be added to the receipt 200a. A transaction identifier 1016 and an authorization code 1018 may be added to the receipt 200a to provide receipt tracking.

[00060] When an image or other digital copy of receipt 200a is provided to the expense management system, the system may utilize image processing to identify the transaction identifier 1016 and authorization code 1018. The transaction identifier 1016 and authorization code 1018 may be identified by OCR or other image processing processes and may be identified based on the receipt 200a fingerprint and/or the receipt fingerprint of the merchant identifier 1000. The transaction identifier 1016 and authorization code 1018 may additionally or alternatively be identified by utilizing lines on receipt 200a for specific data and segmentation of receipt 200a by those lines. For example, if the code "A12345" is on the same line as total 1014, it may be known that the transaction identifier 1016 is present on the line with total 1014 so that the code may be read as the transaction identifier 1016. The fingerprint associated with the receipt 200a and/or the merchant identifier 1000 may also be used to extract the code "B67890" as the authorization code 1018.

[00061] Once the codes are extracted for the transaction identifier 1016 and authorization code 1018, the codes may be matched with stored transaction data for the transaction associated with the receipt 200a. Once matched, the receipt 200a may be stored with the transaction data. However, if the transaction data cannot be matched and/or the code is not extracted and determined from the receipt 200a, further receipt data may be extracted from the receipt 200a, such as the merchant identifier 1000, the total 1014 and/or other data on the receipt 200a. A scoring process may be used to determine the most likely transaction for the receipt 200a within the expense management system's database. If the receipt 200a shows a card identifier or was received from a user associated with a particular card identifier, the scoring system may look for similar transactions that occurred with the card identifier. Thus, other data from the receipt 200a may also be used to associate the receipt with transaction data and store the receipt for auditing or other administrative purposes.

[00062] FIG. 2B is an exemplary system environment for matching receipt data to expense data in a transaction database, according to one embodiment. Environment 200b includes a receipt 1100 that is matched with data in a receipt database 1110, such as a transaction database of an expense management system. The receipt database 1110 may include data generated from transaction processing that is used to match the data to a digital copy of the receipt for receipt tracking and auditing purposes.

[00063] For example, receipt 1100 includes at least transaction data 1102, transaction identifier 1104, and authorization code 1106. Transaction data 1102 may be generated by a merchant device when a transaction is requested to be processed, which may include providing a card identifier associated with an expense management system that performs receipt matching. Transaction data 1102 may include a merchant identifier, item and price, total, and other information. When receipt 1100 is generated, transaction identifier 1104 may be added to the receipt by the expense management system along with authorization code 1106 so that receipt 1100 may be matched with transaction data in receipt database 1110. Receipt database 1110 includes receipt image 1112, processed transaction data 1114, transaction identifier 1118, and authorization code 1120. Receipt image 1112 may include a digital copy of a receipt, such as receipt 1100. Thus, a user may capture an image of receipt 1100 and provide the image to an expense management system that can save the receipt and associates the receipt with a particular transaction in processed transaction data 1114.

[00064] The transaction identifier 1104 and authorization code 1106 may be extracted from the digital copy of the receipt 1100 using OCR or other image processing (including based on a receipt fingerprint of the merchant or receipt 1100). Once extracted, the expense management system may perform a data match using the transaction identifier 1118 and authorization code 1120 from the processed transaction data 1114 previously generated based on electronic transaction processing for a transaction requested by a user using a card identifier serviced by the expense management system. Once matched, the digital copy of the receipt 1100 may be stored with that particular transaction from the processed transaction data 1114. Also, the transaction data 1102 may be extracted from the receipt 1100 and added to the processed transaction data 1114. For example, merchant information, tax, tip, or other data may be added to the transaction data for the receipt 1100. This may allow for further auditing and expense management or categorization by the expense management system. In another embodiment, the pre- or post-capture receipt 1100 may allow the user to enter data such as a code or notes that can provide further information for managing or categorizing amounts. The receipt may have a specific location, such as the upper right corner, where data can be entered, which allows for more efficient capture of data by eliminating the need for the system to scan the entire receipt. This specific location may vary between different types or formats of receipts, such as based on where the least used space is. The data may identify the purpose of the expense, the name of the individual and one or more associated companies, and other data that may be required or useful to a particular expense management system.

[00065] FIG. 3 is an exemplary system environment for synchronizing application scheduling data with expense data in a transaction database, according to an embodiment. The system environment 300 of FIG. 3 includes the user device 110 and expense management system 140 described with reference to the system 100 of FIG. 1. In this regard, integration of the user device 110 and expense management system 140 may be used to exchange data over a data exchange channel 2100 such that calendar or schedule information may be added to the transaction data and used to classify or categorize the data in the expense management system and according to expense policies.

[00066] In the system environment 300, the user device 110 includes a scheduling application interface 2000 that includes a schedule A 2002 for a user, such as a calendar having appointments, meetings, business trips, and other obligations or time allocations of the user. The schedule A 2002 includes calendar or scheduling information for weekdays, such as the calendar shown Monday, Tuesday, Wednesday. As shown in the schedule A 2002, the user has a staff office meeting 2004 at 10:00 a.m. on Monday, a lunch appointment 2006 with Alice at 12:00 p.m. on Tuesday, and a business trip 2008 to City A from 9:00 a.m. to 6:00 p.m. on Wednesday. Each of these appointments may include a time, a location, a client or other user (e.g., a company employee, a colleague, or other acquaintance, including a friend or family member), a subject or type of the appointment, or other information related to the user's particular appointment. The calendar information of the schedule A 2002 may be transmitted to the expense management system 140 through the data exchange channel 2100. For example, Schedule A 2002 may be requested by expense management system 140, which may request all of Schedule A 2002 based on received transaction data, or may request only certain portions of Schedule A 2002 that match the time or other transaction data related to the transaction. In other embodiments, Schedule A 2002 may be forwarded or otherwise transmitted to expense management system 140 based on processed transactions.

[00067] The expense management system 140 includes an expense management database 2200, which may be stored in one or more data structures of the expense management system 140 (e.g., database 144 of system 100). The expense management database 2200 may correspond to a transaction database relating to transaction data generated from processed transactions of the organization (e.g., using a payment instrument, account, or card identifier issued to the organization). The expense management database 2200 may store the transaction data, and the expense management system 140 may request or provide assignments to expense category classifications and expense policies for accounting and auditing purposes to bill business expenses as necessary expenses. Thus, the expense management database 2200 includes company A expenses 2202, which relates to transaction data and corresponding expenses of company A purchasing goods and services. For example, company A expenses 2202 may be organized by one or more payment accounts 2204, including payment account A 2206. Payment account A 2206 may correspond to a card or account identifier of a payment instrument provided to the user associated with the user device 110 and, therefore, schedule A 2002. Thus, the expense management system 140 may use transaction data for Company A Expenses 2202 related to Payment Account A 2206 and data from Schedule A 2002 to categorize the user's expenses.

[00068] For example, Expense A 2208 may include a time 2210 of 10:00 AM on Monday. Using Schedule A 2002 received through the data exchange channel 2100, the expense management system 2002 may determine that the user was attending a staff office meeting 2004. The transaction details 2212 may include transaction details such as the item purchased, the price, the location, etc. Expense A 2208 may also be associated with a receipt 2214 that is matched to the transaction details using, for example, receipt data tracking and matching by displayable code as described herein. However, without the expense category selection, Expense A 2208 may not be assigned to Company A's expense policies and/or categories. Instead, by determining, through the scheduling application and/or platform integration, that the user was attending a staff office meeting 2004, Expense A 2208 may be assigned to an expense category A 2216, such as a category or policy associated with purchases made specifically for staff office meetings and/or business meetings.

[00069] Similarly, Expense B 2218 includes a time 2220 of 12:00 PM on Tuesday, transaction details 2222, receipt 2224, and expense category B 2226. As shown in Schedule A 2002, the user attended a lunch appointment 2006 with Alice, who is a client of the user and the organization. Because Alice is a client, and based on the scheduling data in the user's Schedule A 2002, Expense B 2218 may be assigned to expense category B 2226 to charge the cost of the lunch appointment 2006 or client A 2228 (e.g., to Alice's organization or directly to Alice) as a necessary expense. Expense C 2230 is shown with a time 2232 of 1:00 PM on Wednesday, transaction details 2234, receipt 2236, and expense category C 2238. The user is shown in Schedule A 2002 to have a business trip 2008 to City A on Wednesday from 9:00 AM to 6:00 PM. Therefore, the user claims all expenses during this period against expense category C2238 for the business trip as necessary expenses, and expense C2230 is assigned to expense category C2238 due to the time 2232 that occurred during the business trip 2008.

[00070] FIG. 4 is an exemplary flowchart 400 for receipt code generation and image processing tracking for receipt data synchronization in an expense management system, according to one embodiment. It should be noted that one or more steps, processes, and methods of flowchart 400 described herein may be omitted, performed in a different order, or combined as needed or appropriate.

[00071] In step 402 of flowchart 400, transaction data with a merchant is detected, such as receiving or detecting a transaction processing request to a payment resolution network and for a transaction using a payment instrument issued to a company managed by the expense management system. The transaction data may be stored by the expense management system for resolution under expense policies and for later expense categorization of the transaction. The expense management system then generates a receipt matching code for the transaction data in step 404, which may correspond to at least one alphanumeric code, bar code, or QR code for the particular transaction data. For example, an authorization code and a transaction identifier may be generated. These codes are then output on a receipt from the merchant in step 406. These codes may be printed on a physical receipt or added to a digital receipt that is sent to the device of the user or the user's organization requesting transaction processing.

[00072] In step 408, a receipt image or other digital copy of a receipt is received from a user having an entity or organization that utilizes the expense management system for expense policy enforcement. The receipt may correspond to an image captured using a camera of a device such as a mobile device, or may correspond to a digital receipt forwarded to the expense management system over a communication channel. The digital copy of the receipt may be sent in response to the expense management system requesting a receipt after detecting transaction processing, or may be sent by the user at a later time when the user completes claiming the transaction as an expense and reporting the transaction to the organization or expense management system. Next, in step 410, image processing is performed on the receipt image or other digital copy to identify codes on the receipt image or other digital copy. For example, codes may be identified using OCR or other image processing and knowledge of the code length or code content. Codes may also be read from printed code images such as bar codes or QR codes. Specific image segmentation or comparison against a receipt fingerprint or model may be used to identify where the code is located on the receipt and then extract the code using OCR or other image processing. The code fingerprint can be used to determine that the code is printed aligned with other data on the receipt or in a specific location on the receipt.

[00073] If a code is not extracted from the receipt or if the receipt appears to lack a code, then in step 412, receipt data is determined from the receipt image, such as merchant information and identifiers, transaction data (e.g., item, price, tax, tip, etc.), and other information that can be extracted from the receipt. In step 414, the receipt data is matched to transaction data stored using the expense management system, which may limit matching and queries of database information to transactions processed or managed on behalf of the organization. In step 414, the receipt data matching against the stored transaction data is also scored, which may determine the best or most likely match between the data. Once the most likely match is determined, in step 416, the extracted data and/or receipt data, including the receipt image or digital copy, are added to the stored transaction data. In some embodiments, data is stored only if the best or most likely match exceeds a predetermined threshold.

[00074] Conversely, if a code is detected in the image in step 410, the receipt is matched to the stored transaction data using the code in step 418. Additionally, the match of the code against the stored transaction data is scored to determine the most likely match between the code (and further receipt data extracted using image processing). The most likely match between the receipt and the stored transaction data is determined and the receipt data (e.g., the extracted receipt data and receipt image or digital copy) is added to the stored transaction data in step 420. As above, data is only stored if the best or most likely match exceeds a predetermined threshold, which prevents untrusted data from being stored and/or used.

[00075] FIG. 5 is an exemplary flowchart for application data synchronization based on application integration for automatically categorizing expense data, according to an embodiment. It should be noted that one or more steps, processes, and methods of flowchart 500 described herein may be omitted, performed in a different order, or combined as needed or appropriate.

[00076] At step 502 of flowchart 500, transaction data is received and/or detected for a transaction with a merchant. For example, a transaction processing request to a payment settlement network and for a transaction using a payment instrument issued to a company managed by the expense management system may be detected. The transaction data may be stored by the expense management system for categorization of expenses for the transaction using calendar or scheduling information of the user causing the transaction. Thus, at step 504, the user submitting the transaction is determined. For example, a card identifier used to process the transaction may be tied to a particular user so that the user is identified. A user may also be identified by the co-location of a mobile device of an organization's user relative to the location of a merchant using a GPS unit or other location detection component of the mobile device. Other data matching, such as mobile communications at the time of the transaction or indicative of transaction processing, may also be used.

[00077] In step 506, the user's scheduling data at the time of the transaction is accessed. The scheduling data may be accessed by an application or online platform integration with the user's scheduling application and process, such as the user's digital calendar. Then, in step 508, further expense details are determined based on the scheduling data. Further expense details may be determined based on the information and details of the scheduling data at the time, such as the name of the meeting, the name of the client, the user identifier for the meeting or appointment, the travel details, the location of the appointment or travel, the identification of the content or reason for the appointment, or other information. For example, the scheduling data may indicate the name, phone number or email of the user who attended the meeting, the name of the client for the meeting, or the location of the appointment, which may be used to add the expense details to the transaction and to further categorize the transaction under an expense policy so that the expense may be added to expense limits, client refunds, or other expense management. In some embodiments, step 508 may include sub-step 508a, which may further determine whether the expense management system will process the transaction based on the calendar data. For example, during a business trip, the expense may be charged as a necessary expense to the organization for refund to the user. However, certain expenses, such as personal gifts for friends or family, may not be covered under expense policies for business trips according to the user class. Thus, if the calendar information indicates that the user is not currently working or purchasing items related to an organizational business trip, the expense may be denied processing or may be categorized as an unauthorized purchase for which the user is responsible.

[00078] In step 510, based on the transaction processing, further expense details are added to the transaction data stored by the system. The further expense details may define the transaction under the expense policy by matching the transaction to a particular category of the expense policy. This may allow the expense management system to better define the transaction and automate the categorization of expenses without requiring user input. Then, in step 512, the transaction is categorized based on the transaction data and the further expense details such that the transaction is billed as a necessary expense under the particular expense policy and category.

[00079] Thus, using the various embodiments described herein, a company may better (e.g., more efficiently and more accurately) track and manage expenses incurred by users associated with the company's funding sources or accounts by using data contained in receipts or transaction records that match data in a database to track, approve, and otherwise manage financial transactions made by such users.

[00080] FIG. 6 is a block diagram of a computer system suitable for implementing one or more components of FIG. 1, according to an embodiment. In various embodiments, the communication device may include a personal computing device capable of communicating with a network (e.g., a smart phone, a computing tablet, a personal computer, a laptop, a wearable computing device such as glasses or a watch, a Bluetooth device, a key fob, an ID card, etc.). The service provider may utilize a network computing device capable of communicating with the network (e.g., a network server). It is to be understood that each device utilized by the user and the service provider may be implemented as a computer system 600 in the following manner:

[00081] Computer system 600 includes a bus 602 or other communication mechanism for communicating information data, signals, and information between various components of computer system 600. The components include an input/output (I/O) component 604 that processes user actions, such as selecting a key from a keypad/keyboard, selecting one or more buttons, images or links, and/or moving one or more images, and sends corresponding signals to bus 602. I/O component 604 may also include output components, such as a display 611 and a cursor control device 613 (keyboard, keypad, mouse, etc.). An optional audio input/output component 605 may also be included to allow a user to use their voice to input information by converting audio signals. Audio I/O component 605 may allow a user to hear audio. Transceiver or network interface 606 transmits and receives signals over network 180 between computer system 600 and other devices, such as another communication device, a service device, or a service provider server. In some embodiments, the transmission is wireless, although other transmission media and methods may be suitable. One or more processors 612, which may be a microcontroller, digital signal processor (DSP), or other processing component, process these various signals, such as for display on the computer system 600 or for transmission to other devices via a communications link 618. The one or more processors 612 may also control the transmission of information, such as cookies or IP addresses, to other devices.

[00082] Components of computer system 600 also include a system memory component 614 (e.g., RAM), a static storage component 616 (e.g., ROM), and/or a disk drive 617. Computer system 600 performs certain operations through one or more processors 612 and other components by executing one or more sequences of instructions contained in system memory component 614. Logic may be encoded in a computer readable medium, which may refer to a medium that participates in providing instructions to one or more processors 612 for execution. Such media may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. In various embodiments, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such as system memory component 614, and transmission media includes coaxial cables, copper wire, and fiber optics, including the wires that comprise bus 602. In an embodiment, logic is encoded in a non-transitory computer readable medium. In some examples, transmission media can take the form of acoustic or light waves, such as those generated during radio, optical and infrared data communications.

[00083] Some common forms of computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape, other magnetic media, CD-ROMs, other optical media, punch cards, paper tape, other physical media with patterns of holes, RAM, PROM, EEPROM, flash EEPROM, other memory chips or cartridges, or other media adapted for reading by a computer.

[00084] In various embodiments of the present disclosure, execution of the instruction sequences for carrying out the present disclosure may be performed by computer system 600. In various other embodiments of the present disclosure, multiple computer systems 600 coupled to a network (e.g., a LAN, a WLAN, a PTSN, and/or various other wired or wireless networks, including telecommunications networks, mobile networks, and cellular networks) by communications links 618 may cooperate with each other to carry out the instruction sequences for carrying out the present disclosure.

[00085] Various embodiments of the present disclosure can be described in terms of the following clauses. However, further or other embodiments of the present disclosure may be described herein.

[00086] 1. A system including: a non-transitory memory that stores instructions; and one or more hardware processors coupled to the non-transitory memory that are configured to read instructions from the non-transitory memory to cause the system to perform operations including: detecting, upon use of a payment card associated with the system, an electronic transaction between a user and a merchant, the electronic transaction including transaction data generated during processing of the electronic transaction by the system; determining calendar information for the user at the time from a calendar application, the calendar application being accessible using the user's device; determining further transaction data for the electronic transaction using the calendar information; and storing the further transaction data with the system-generated transaction data for the electronic transaction.

[00087] 2. The system of claim 1, wherein the calendar information includes an appointment or meeting at the time of using the payment card, the calendar information further includes at least one of a location, a client name, a name of the meeting, or a length of the meeting, and the further transaction data includes an expense category classification for the electronic transaction.

[00088] 3. The system of claim 1, wherein the calendar application includes details of the user's travel trips, the calendar information includes current travel data for the user, and the further transaction data includes travel expense category classifications for electronic transactions.

[00089] 4. The system of clause 3, wherein the operations further include assigning the electronic transaction to at least one of a client account or a travel account associated with the business entity that provides the payment card to the user.

[00090] 5. The system of clause 1, wherein the operations further include allocating expense reimbursement payments related to the electronic transaction to the user's clients based on the further transaction data.

[00091] 6. The system of clause 5, wherein allocating expense reimbursement payments to clients occurs without user input to identify the client.

[00092] 7. The system of clause 1, wherein the operations further include determining, using a location detection component of the user's mobile device, a location of the user at the time of use of the payment card, and the further transaction data is further determined based on the location of the payment card at the time of use.

[00093] 8. The system of clause 1, wherein the operations further include determining user activity of the user when using the payment card based on the calendar information, and further transaction data is further determined based on the user activity when using the payment card.

[00094] 9. The system of clause 1, wherein the operations further include determining contextual data about the electronic transaction based on at least one of the level 2 card data, the level 3 card data, the messaging data, the mobile application data, or the historical expense categorization data, and assigning the electronic transaction to an expense management category based on the transaction data, the further transaction data, and the contextual data.

[00095] 10. The system of clause 1, wherein the operations further include determining at least one of a merchant identifier, a date, or an amount of the electronic transaction based on the transaction data, and assigning the electronic transaction to an expense policy category based on the further transaction data and at least one of the merchant identifier, the date, or the amount.

[00096] 11. The system of clause 1, further comprising, prior to determining the calendar information, processing an electronic transaction with the merchant based on an expense management policy associated with the payment card, the calendar information being determined in response to processing the electronic transaction.

[00097] 12. A method, comprising: receiving transaction data for a transaction with a merchant requested for processing by a service provider on behalf of a user, the user being associated with an entity that provides the user with an account identifier for the entity's expense management system; and processing the transaction with the merchant based on the account identifier, the processing of the transaction including: generating transaction data with the service provider; determining contextual data for either the user or the transaction at the time of the transaction based on the transaction data from a digital application utilized by the user; and assigning the transaction to an expense management category based on the contextual data and the transaction data.

[00098] 13. The method of claim 12, wherein the context data includes one of an appointment, a meeting, or a business trip during the transaction.

[00099] 14. The method of clause 12, further comprising determining further transaction data related to the transaction based on the context data, the context data including one of expense card data, merchant entered data, communication data, or historical expense data, and allocating the transaction further based on the further transaction data.

[000100] 15. The method of clause 12, wherein allocating the transaction to an expense control category includes identifying a plurality of expense control categories of the entity, each of the plurality of expense control categories providing an expense category classification for the purchase using an account identifier for the expense management system; and determining an expense control category for the transaction based on the context data, the transaction data, and the plurality of expense control categories.

[000101] 16. The method of claim 12, further comprising allocating the transaction to a particular client of the entity based on the contextual data and the expense management category.

[000102] 17. The method of claim 12, further comprising receiving a receipt for the transaction from a user device of the user, determining receipt data on the receipt using an image recognition process, and further allocating the transaction to a subcategory of the expense management category based on the receipt data.

[000103] 18. The method of claim 17, wherein the subcategories include one or more of food, drinks, business trips, or gifts, and the subcategories are further assigned to clients based on one of phone numbers, email addresses, messenger names, or client names.

[000104] 19. A non-transitory machine-readable medium having executable machine-readable instructions stored thereon to cause a machine to perform operations including receiving a transaction request for a transaction between a user and a merchant using a payment instrument associated with the user's company, the payment instrument being associated with an expense management system provided to the company by a service provider; processing the transaction with the merchant based on the payment instrument and the expense management system in response to the transaction request; determining from the user's personal information management application a current activity of the user at the time of the transaction; determining expense management information for the transaction based on the current activity; and storing the expense management information with transaction data for the transaction.

[000105] 20. The non-transitory machine-readable medium of clause 19, wherein determining the user's current activity further includes receiving an image of a receipt for the transaction and determining transaction data from the receipt, and the expense management information is further determined based on the transaction data.

[000106] Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or a combination of hardware and software. Also, where applicable, various hardware and/or software components described herein may be integrated into composite components including software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, various hardware and/or software components described herein may be separated into subcomponents including software, hardware, or both without departing from the scope of the present disclosure. Further, where applicable, it is contemplated that software components may be implemented as hardware components (and vice versa).

[000107] Software according to the present disclosure, such as program code and/or data, may be stored on one or more computer-readable media. It is also contemplated that the software identified herein may be implemented using one or more general-purpose or special-purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of the various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide the features described herein.

[000108] The above disclosure is not intended to limit the disclosure to the precise form or particular field of use disclosed. As such, various alternative embodiments and/or modifications to the disclosure, whether expressly described or implied herein, are contemplated in light of the present disclosure. Having the above described embodiments of the disclosure, one skilled in the art will recognize that changes in form and detail may be made without departing from the scope of the disclosure. Accordingly, the disclosure is limited only by the scope of the claims.

Claims (6)

1. A system comprising:
a non-transitory memory for storing instructions;
one or more hardware processors coupled to the non-transitory memory,
detecting an electronic transaction with a merchant conducted using a funding source associated with the system;
generating at least one alphanumeric code associated with the electronic transaction;
causing said at least one alphanumeric code to be submitted on a transaction record from said merchant;
receiving a digital representation of said transaction record;
analyzing the digital representation using image processing operations;
determining the at least one alphanumeric code based on the analysis; and
matching said transaction record with stored transaction data relating to said electronic transaction;
one or more hardware processors configured to read the instructions from the non-transitory memory to cause the system to perform operations that include:
Including,
The at least one alphanumeric code includes an authorization code associated with processing the electronic transaction and a transaction identifier that identifies the electronic transaction in the system. 1. A system comprising:
a non-transitory memory for storing instructions;
one or more hardware processors coupled to the non-transitory memory,
detecting an electronic transaction with a merchant conducted using a funding source associated with the system;
generating at least one alphanumeric code associated with the electronic transaction;
causing said at least one alphanumeric code to be submitted on a transaction record from said merchant;
receiving a digital representation of said transaction record;
analyzing the digital representation using image processing operations;
determining the at least one alphanumeric code based on the analysis; and
matching said transaction record with stored transaction data relating to said electronic transaction;
one or more hardware processors configured to read the instructions from the non-transitory memory to cause the system to perform operations that include:
Including,
The system, wherein the digital representation includes an image of a physical receipt containing a transaction history , and the image processing operations include an optical character recognition process. 1. A system comprising:
a non-transitory memory for storing instructions;
one or more hardware processors coupled to the non-transitory memory,
detecting an electronic transaction with a merchant conducted using a funding source associated with the system;
generating at least one alphanumeric code associated with the electronic transaction;
causing said at least one alphanumeric code to be submitted on a transaction record from said merchant;
receiving a digital representation of said transaction record;
analyzing the digital representation using image processing operations;
determining the at least one alphanumeric code based on the analysis; and
matching said transaction record with stored transaction data relating to said electronic transaction;
one or more hardware processors configured to read the instructions from the non-transitory memory to cause the system to perform operations that include:
Including,
The system, wherein the digital representation includes an electronic message of a transaction history and the image processing operations include a text recognition process. 1. A system comprising:
a non-transitory memory for storing instructions;
one or more hardware processors coupled to the non-transitory memory,
detecting an electronic transaction with a merchant conducted using a funding source associated with the system;
generating at least one alphanumeric code associated with the electronic transaction;
causing said at least one alphanumeric code to be submitted on a transaction record from said merchant;
receiving a digital representation of said transaction record;
analyzing the digital representation using image processing operations;
determining the at least one alphanumeric code based on the analysis; and
matching said transaction record with stored transaction data relating to said electronic transaction;
one or more hardware processors configured to read the instructions from the non-transitory memory to cause the system to perform operations that include:
Including,
The operations further include storing the digital representation associated with a transaction history along with the stored transaction data in an expense management system of a business entity associated with the funding source. 1. A system comprising:
a non-transitory memory for storing instructions;
one or more hardware processors coupled to the non-transitory memory,
detecting an electronic transaction with a merchant conducted using a funding source associated with the system;
generating at least one alphanumeric code associated with the electronic transaction;
causing said at least one alphanumeric code to be submitted on a transaction record from said merchant;
receiving a digital representation of said transaction record;
analyzing the digital representation using image processing operations;
determining the at least one alphanumeric code based on the analysis; and
matching said transaction record with stored transaction data relating to said electronic transaction;
one or more hardware processors configured to read the instructions from the non-transitory memory to cause the system to perform operations that include:
Including,
the at least one alphanumeric code includes one code of a plurality of codes intended to be printed on a receipt having a transaction history , the operations further including determining at least one of a merchant identifier, a date, or an amount on the receipt;
The system, wherein the matching is further performed based on the at least one of the merchant identifier, the date, or the amount. 1. A system comprising:
a non-transitory memory for storing instructions;
one or more hardware processors coupled to the non-transitory memory,
detecting an electronic transaction with a merchant conducted using a funding source associated with the system;
generating at least one alphanumeric code associated with the electronic transaction;
causing said at least one alphanumeric code to be submitted on a transaction record from said merchant;
receiving a digital representation of said transaction record;
analyzing the digital representation using image processing operations;
determining the at least one alphanumeric code based on the analysis; and
matching said transaction record with stored transaction data relating to said electronic transaction;
one or more hardware processors configured to read the instructions from the non-transitory memory to cause the system to perform operations that include:
Including,
Prior to said receiving said digital representation, said operations include:
processing the electronic transaction with the merchant; and
sending an electronic message to a mobile device of a user associated with the funding source, the electronic message including a request for the digital representation;
The digital representation is received based on the electronic message.

Images