Category Matching

At step 206, past post-approved transaction records are matched to a plurality of categories which include possible pre-approved categories and non-possible pre-approved categories. For example, a plurality of categories may be defined as outputs in training data for a machine learning system. Examples of categories include procurement, office supplies, internet, phone, dues/membership/subscriptions, employee training, entertainment, meals, gifts, rental car, airfare, and lodging. In an embodiment, the plurality of categories to which the records are matched may differ from the entity defined categories. For example, an entity may define its own categories for identifying transactions that overlap, partially overlap, or do not overlap with the matching categories. Thus, while matching the records to categories may incorporate entity-defined category data, the transaction record's initial category may not be dispositive in matching the transaction record to one of the plurality of categories.

Some of the categories may be defined as possible pre-approved categories. For example, procurement, office supplies, internet, dues/membership/subscription, and employee training may be defined as possibly procurable expenses while entertainment, meals, gifts, rental car, airfare, and lodging may be defined as non-possible pre-approved categories.

Server 102 may use a machine learning system trained to normalize transactions into the plurality of predefined categories. For example, the machine learning system may be trained using expense lines as inputs with the normalized categories as outputs. As a practical example, the server 102 may train a TF-IDF model using logistic regression where the training datasets comprise expense records that have been previously matched to normalized categories, the inputs comprise one or more fields of the transaction records, and the outputs comprise each normalized category.

By normalizing transactions to a plurality of pre-defined categories, the methods increase the efficiency at which the server 102 is able to process large amounts of data to determine which previous post-approved transactions could be identified as possible pre-approved transactions. Specifically, the normalizing techniques described herein allow the server 102 to prune transaction records from future matching steps if the transaction records are not normalized to one of the categories defined as possible pre-approved categories. Thus, the server 102 is able to perform the methods described herein with a large number of transaction records at faster speeds and using less processing power as particular records are removed prior to the matching steps based on the normalization.

Pre-Approved Transaction Matching

At step 208, past post-approved transaction records in the possible pre-approved categories are matched with past pre-approved records from the first entity. For example, the server 102 may compare past post-approved transaction records that have been normalized to one of the possible pre-approved categories with past pre-approved transaction records based on one or more fields of the transaction records.

In an embodiment, the server 102 converts one or more fields of each past post-approved transaction and one or more fields of the past pre-approved transaction records into one or more vectors using one or more machine learning systems. For example, the Word2vec machine learning algorithm may be used to convert words in a description field and/or a reason field of the transaction records into one or more vectors.

Given possible differences in nature of post-approved transaction records from pre-approved transaction records, the selected fields for conversion into vectors may differ. For example, the server 102 may convert a description field and a reason field from the past post-approved transaction records into a vector but only the description field from the past pre-approved transaction records. Other example embodiments may include merchant fields, category fields, or item identifier fields that additionally or alternatively are used to generate a vector for one or more of the past post-approved transaction records or past pre-approved transaction records.

In an embodiment, the server 102 uses a machine learning system to compare vectors generated from the past post-approved transaction records of the first entity with vectors generated from the past pre-approved transaction records of the first entity. For instance, for each past post-approved transaction record, the server 102 may compute a cosine similarity between the vector corresponding to the past post-approved transaction record and the vectors corresponding to each past pre-approved transaction record until a match is identified and/or all past vectors corresponding to past pre-approved transaction records have been compared to the vector of the past post-approved transaction record. In an embodiment, the server 102 identifies a match if the cosine similarity between two vectors is greater than a threshold value, such as 70%.

By initially comparing past post-approved transaction records with past pre-approved transaction records of the same entity, the system is able to reduce the number of comparisons that need to be made to match records. For example, each past post-approved transaction record that has been matched with a past pre-approved transaction record may be set aside as matched records. Step 210 may then proceed with the remaining unmatched records. Given that the number of records for past pre-approved transactions for other users often far exceeds the number of records for past pre-approved transactions for a single user, this initial step reduces the amount of processing that needs to be performed substantially by removing post-approved transaction records which can be matched to pre-approved transaction records of the first entity.

At step 210, past post-approved transaction records in the possible pre-approved categories are matched with past pre-approved transaction records from one or more entities other than the first entity. For example, the server 102 may use the Word2vec machine learning algorithm to generate vectors for past pre-approved transaction records of other users of a procurement system provided by server 102, thereby allowing for records to be compared across a plurality of entities. The server 102 may compare vectors corresponding to post-approved transaction records of the first entity that were not matched in step 208 with vectors corresponding to past pre-approved transactions of the other users of the procurement system, such as by computing a cosine similarity between the vectors and determining that the vectors match if the cosine similarity is greater than a threshold value, such as 70%.

In an embodiment, the server 102 further reduces the processing power and time required to match past post-approved transaction records of a first entity with past pre-approved transaction records of a plurality of other entities by intelligently reducing the number of past pre-approved transaction records of the plurality of other entities while keeping high information fidelity. For example, server 102 may utilize a clustering algorithm, such as the K Means clustering algorithm, to cluster the pre-approved transaction records of the plurality of other entities into a plurality of clusters. The server 102 may then select, randomly or pseudo-randomly, a subset of the past pre-approved transaction records in each cluster to compare to the past post-approved transaction records. For example, the server 102 may select 10% of the records in each cluster for comparison. The number of clusters may be predetermined, such as fifty clusters, and/or determined based on the number of pre-approved transaction records for comparison, such as one cluster per thousand records.

By clustering the vectorized past pre-approved transaction records of the plurality of other entities, the server 102 is able to compute the comparison between past post-approved transaction records of the first entity and the past pre-approved transaction records of a plurality of second entities much faster. For example, computation time may be reduced by as much as 90% while producing an equivalent number of matches for the post-approved transaction records by clustering the past pre-approved transaction records and selecting a subset of each cluster for comparison.

At step 212, transactions corresponding to records matched in steps 208 and 210 are identified as possible pre-approved transactions. For example, the server 102 may identify expense transaction records that were matched to invoices in step 208 as procurable based on the first entity's information and expense transaction records that were matched to invoices of others in step 210 as procurable based on entity information other than the first entity's.

While FIG. 2 depicts both steps 208 and 210 being performed, in an embodiment either step 208 or step 210 can be performed without the other. For example, server 102 may only compare past post-approved transaction records with pre-approved transaction records of the first entity or may broadly compare post-approved transaction records of the first entity to pre-approved transaction records of a plurality of other entities, including or excluding the first entity, without first comparing the post-approved transaction records to pre-approved transaction records of the first entity.

In an embodiment, the server 102 causes display of a graphical user interface which identifies past post-approved transaction records as possible pre-approved transactions. For instance, the server 102 may display a percentage of previous post-approved transactions that are potential pre-approved transactions based on the first entities data, that are potential pre-approved transactions based on the other entities' data, and/or that are not potential pre-approved transactions. Example graphical user interfaces for identifying past post-approved transaction records as possible pre-approved transactions are described further herein.

In addition to displaying information relating to past post-approved transaction records that have been identified as possible pre-approved transaction records, the systems and methods may utilize the systems and methods described herein to perform one or more of optional steps 212, 214, and/or 216.

Identifying Entities

In an embodiment, at step 212, entities are identified for performing possible pre-approved transactions based on past pre-approved transaction data for the first entity. For example, the server 102 may identify a provider entity for each past pre-approved transaction that has been matched to a post-approved transaction. Identifying the entity may comprise determining the entity from a “merchant” field in the record and/or from stored data regarding the transaction between two entities.

The server 102 may determine, for each of the possible pre-approved transactions that are based on past pre-approved transaction data for the first entity, one or more entities capable of performing the pre-approved transactions. The server 102 may further aggregate identifications of the one or more entities. For example, the server 102 may determine a number of possible pre-approved transactions that could be performed through each of the one or more entities and/or a total dollar amount corresponding to transactions that could be performed through each of the one or more entities. Server 102 may aggregate dollar amounts from the “amount” fields in the past post-approved transaction records corresponding to the possible pre-approved transactions.

In an embodiment, the server 102 calculates an amount of savings of switching to the possible pre-approved transactions from the post-approved transaction records. For instance, for each record matched past post-approved transaction record of the first entity, the server 102 may identify a merchant for the corresponding past pre-approved transaction record, a total amount for a particular item, and the total amount for the particular item in the matching past pre-approved transaction record. The server 102 may compute a difference between the total amount in the past post-approved transaction record and the total amount in the past pre-approved transaction record. The server 102 may then increment a savings value for the merchant by the computed difference. In an embodiment, the server 102 causes display of the savings value for the merchant and/or an overall savings value for utilizing the merchant for possible pre-approved transaction records instead of post-approved transaction records.

Generating Recommendations

In an embodiment, at step 214, the server 102 generates recommendations for actions to take based on categories of possible pre-approved transactions. For example, the server 102 may store one or more recommendations for each of the plurality of pre-defined categories identified as possible pre-approved transaction records. The server 102 may be programmed or configured to provide recommendations for a particular category when past post-approved transactions that have been normalized to the particular category are matched with past pre-approved transactions. Thus, the server 102 is able to provide recommendations based on the normalized categories in addition to the matching data.

In an embodiment, the server 102 displays recommendations in a graphical user interface which displays data for first entity-defined categories. The server 102 may identify transactions within the first entity-defined categories that have been matched to past pre-approved transaction records. For the matched transactions, the server 102 may identify a normalized category for the transaction and display a recommendation based on the normalized category. Thus, the first entity-defined categories may include recommendations from a plurality of normalized categories.

In an embodiment, the server 102 ranks recommendations by a number of transactions that were normalized to a category corresponding to the recommendation and/or a total amount in transactions that were normalized to a category corresponding to the recommendation. For example, if a customer-defined category of “overhead” includes ten transactions that were normalized to the “Office Supplies” category and three transactions that were normalized to the “Internet” category, the recommendations for the “Office Supplies” category may be displayed ahead of and/or in place of the recommendations for the “Internet” category. Additionally and/or alternatively, if the three transactions normalized to the “Internet” category corresponded to a total of $5,000 while the ten transactions normalized to the “Office Supplies” category corresponded to $500, then the recommendations for the “Internet” category may be displayed ahead of and/or in place of the recommendations for the “Office Supplies” category.

Query Optimization

In an embodiment, at step 216, previous queries are optimized based on possible pre-approved transactions and previous queries. For example, the server 102 may identify, for a particular post-approved transaction record that was matched to a pre-approved transaction records, one or more queries through the procurement system that correspond to the particular post-approved transaction. For example, the server 102 may store queries made by the first entity through a procurement system with data identifying the date and/or time of the queries. The server 102 may identify a date of the particular post-approved transaction record and select a subset of queries made by the first entity that are within a specific time period prior to the post-approved transaction. The server 102 may then compute a similarity value between the vectorized description for the particular post-approved transaction record and vectorized versions of the subset of the queries. If the cosine similarity between a query and the post-approved transaction record is greater than a threshold value, such as 70%, the server 102 may determine that the query corresponds to the post-approved transaction record.

With a query matched to a past post-approved transaction record, the server 102 may identify one or more optimized queries. For example, the server 102 may identify a merchant and/or item in the past pre-approved transaction record that corresponds to the past post-approved transaction record and determine whether the initial query would result in the merchant and/or item. If the initial query would not result in the merchant and/or item, the server 102 may modify the query such that the merchant and/or item would be a result of the query, such as modifying one or more words in the query to match one or more words in the description of the merchant and/or item. The server 102 may then store the optimized query with data corresponding the optimized query to the one or more initial queries.

In an embodiment, in response to receiving a query that matched the one or more initial queries, the server 102 may display a recommendation to replace the query with the stored optimized query. For example, the server 102 may compare future queries received by the first entity with the one or more initial queries using any known linguistic comparison techniques. If a future query matches the initial query, the server 102 may display a notification identifying the optimized query as a possible alternative to the future query.

Contract Matching

In an embodiment, the server 102 matches past post-approved transaction records to relationship data stored in server 102 defining relationships between the first entity and one or more other entities. For example, the server 102 may store contract data identifying an agreement between a particular provider entity and the first entity for the particular provider entity to provide one or more goods and/or services to the first entity.

In an embodiment, the server 102 matches any post approved-transaction records that have been normalized into one of the possible pre-approved transaction records categories to one or items and/or services provided by the one or more other entities. For example, the server 102 may first identify the one or more other entities with which the first entity has a relationship based on the stored relationship data. The server 102 may then compare vectorized past post-approved transaction records to vectorized descriptions of items and/or services of the one or more other entities from stored catalog data for the one or more other entities.

Additionally or alternatively, the server 102 may compare the vectorized past post-approved transaction records to past pre-approved transaction records corresponding to the one or more other entities. For example, after categorizing the post-approved transaction records into the possible pre-approved transaction records categories, the server 102 may initially perform the comparisons described herein with respect to records corresponding to the one or more other entities.

As a practical example, if the first entity has a relationship with a particular second entity, the server 102 may first compare the past post-approved transaction records with past pre-approved transaction records between the first entity and the particular second entity, followed by comparing them with all other past pre-approved transaction records of the first entity, followed by comparing them with past pre-approved transaction records between any other entities and the particular second entity, followed by comparing them with past pre-approved transaction records of entities other than the first entity and the particular second entity.

If the server 102 matches the past post-approved transaction records to a transaction record corresponding to a particular second entity with which the first entity has a relationship defined by stored entity relationship data, the server 102 may additionally recommend utilizing the particular second entity for future transactions. Additionally or alternatively, the server 102 may aggregate records that are matched to the particular second entity to identify a number of past post-approved transactions and/or a total cost of past post-approved transactions that could have been performed as past pre-approved transactions through the particular second entity.

Example Graphical User Interface

In an embodiment, the server 102 provides a graphical user interface for depicting past post-approved transaction records that have been matched to past pre-approved transaction records. The graphical user interface may identify aggregated values, such as a total cost of past post-approved transactions over a particular period of time that have been categorized as possible pre-approved transactions based on records of the first entity and/or based on records of a plurality of second entities.

FIG. 3 depicts an example graphical user interface for displaying information relating to past post-approved transaction records that have been identified as possible pre-approved transactions. Interface 300 comprises total expense 302 and total procurable 304. Total expense comprises a total cost of past post-approved transaction records. Total procurable 304 comprises a total cost of the subset of past post-approved transaction records that have been matched to past pre-approved transaction records.

FIG. 3 further comprises expense category graph 306. Expense category graph 306 comprises a breakdown of past post-approved transaction records by expense categories 308. The expense categories 308 comprise a breakdown of past post-approved transaction records by user defined categories. For example, each past post-approved transaction record may comprise data identifying a user defined category to which the record corresponds. Expense category graph 306 thus provides data indicating, for each user defined category, a total cost of the past post-approved transaction records for the category over a specific period of time, wherein a first portion of the graph identifies a total cost of past post-approved transaction records which have been matched to past pre-approved transaction records of the same entity, a second portion of the graph identifies a total cost of past post-approved transaction records which have been matched to past pre-approved transactions records of one or more other entities, and a third portion identifies a total cost of past post-approved transaction records that were not matched to past pre-approved transaction records.

The expense category graph 306 provides a unique graphical user interface wherein procurement opportunities are depicted in a streamlined and convenient manner. In an embodiment, the expense category 306 is configured to provide additional precise information in response to one or more user controls. For example, in response to detecting that a user's cursor has been moved to a portion of the graph, the server 102 may be configured to cause displaying of an exact cost amount corresponding to the portion of the graph. For example, if you user moves a cursor over the “Procurable by You” section of the “Office Supplies” category in FIG. 3, the server 102 may cause display of a window with text identifying the category as “Office Supplies”, the portion as “Procurable by You”, and the total amount for the portion of the graph as “36,538”.

In an embodiment, the graphical user interface is configured to display additional transaction information in response to receiving a selection of a particular category. FIG. 4 depicts an example graphical user interface for displaying more detailed information regarding transaction records in a particular category. Interface 400 comprises individual record data 402 for a particular category 404. In an embodiment, the particular category 404 option can be selected to cause the graphical user interface to display data for a different category. The period 406 comprises controls for selecting a time period for viewing transaction records, such as reviewing records from the past 12 months, 6 months, 1 month, etc. Procurable opportunity 408 comprises controls for selecting a view of based on whether they were matched to past pre-approved transactions of the same entity and/or other entities.

Interface 400 identifies, for each past post-approved transaction record, a date of the record, a submitter of the record, a category of the record, a cost of the record, a merchant for the record, and a description of the record. In an embodiment, the interface 400 additionally identifies whether the record was identified as procurable based on records from the viewing entity or based on records from one or more other entities.

Similarly, an interface may display past post-approved transaction records that have not been narrowed to a particular category. FIG. 5 depicts an example graphical user interface for displaying more detailed information regarding transaction records for all categories. Thus, interface 500 may comprise similar information for each transaction as interface 400, such as expense category, expense cost, expense date, description, etc.

Server 102 may additionally or alternatively cause display of one or more recommendations based on normalized categories. FIG. 6 depicts an example graphical user interface for displaying recommendations based on normalized categories of past post-approved transactions. The interface 600 may be displayed as part of a graphical user interface depicting transactions for a particular user defined category, such as FIG. 4, and may include recommendations based on the normalized categories for transactions within the particular user defined categories. Recommendations may be displayed with priority given to the normalized category which appears most frequently and/or corresponds to a highest cost in the user defined category. For example, if the user defined category of “Travel” includes 400 procurable expense transactions from a normalized category of “Hotel” and 700 procurable expense transactions from a normalized category of “Flight”, the server 102 may display the recommendations for the “Flight” category above recommendations for the “Hotel” category.

In an embodiment, interface 600 comprises recommendations 602, task creation option 604, and action option 606. Recommendations 602 comprise recommendations that correspond to normalize categories and are displayed when greater than a threshold number of transactions and/or transaction cost of a normalized category are identified as procurable transactions that were expensed. Task creation option 604 comprises an option which, if selected, causes the server 102 to create a task object which identifies the recommendation and can be assigned to one or more users. Action option 606 comprises an option which, if selected, causes the server 102 to navigate to a particular page for completing a recommendation, such as navigating to a policy editing page for completing a recommendation of “Update policies”. In an embodiment, when a task is completed through the interface, the recommendation is replaced with a recommendation for the category of a lower priority.

In an embodiment, the server 102 additionally provides a cost comparison in a graphical user interface between the past post-approved transaction records and matched past pre-approved transaction records, thereby displaying a difference in cost for performing the transactions as pre-approved transactions instead of post-approved transactions.

In an embodiment, the graphical user interface further depicts expense filtered by submitter. For example, an interface may display a total cost of expense submitted by a particular submitter, a percentage of expenses and/or expense cost from a particular submitter, individual expense transactions submitted that were identified as procurable for an individual submitter, a total cost of expenses that were identified as procurable submitted by the submitter, and/or a percentage of expenses and/or expense cost of expenses identified as procurable submitted by the particular submitter. The graphical user interface may display the expense information for a single submitter and/or for a plurality of submitters. For example, an interface for a plurality of submitters may show the overall costs and/or percentages while an interface for a particular submitter may display individual transactions submitted by the submitter with corresponding information.

In an embodiment, pre-approved transactions may be matched to post-approved transactions at different times during an expensing process. For example, when a past post-approved transaction record is first placed input into an expensing system, the server 102 may determine whether the past post-approved transaction record could have been a pre-approved transaction. If so, the server 102 may cause display of a notification that the input expense transaction was a procurable opportunity. In an embodiment, the server 102 further causes display of an option for confirming that the expense transaction was procurable or indicating that the server 102 incorrectly identified the transaction as procurable, thereby allowing the system to identify past post-approved transactions on an individual basis such that the system can respond faster to future queries. Additionally, the system is able to notify users as an expense transaction is processed, thereby providing a faster correction.

Benefits of Certain Embodiments

The systems and methods described herein provide a technical solution to a difficult technical problem of comparing matching post-approved transaction records with a large number of pre-approved transaction records in a manner that saves on processing power and memory by applied machine learning algorithms. Techniques described herein allow records to matched efficiently while reducing a number of comparisons that must be performed and reducing the processing power for performing said comparisons. Examples of technical improvements of the systems and methods described herein include the saving on memory and processing power by utilizing normalization techniques to reduce the number of records for comparison and utilizing clustering algorithms to remove similar records from comparison.