Patent Application
20130024331
This application relates to managing accounts payable data. More specifically, the application relates to management of accounts payable data that includes anomalous data.
An entities that procures goods and services from different vendors often receives invoices and descriptive documentation from the vendors. The invoices identify the goods and services, provide information about the vendors, the entity, the goods and services, and amounts that are due in connection with the goods and services. The descriptive information may include descriptions of the goods and services. The entity may procure goods and services from more than one vendor in a market sector. The vendors in the market sector may provide to the entity goods and services that are similar. In the invoices and the descriptive documentation, the vendors may identify the similar goods and services, and describe them, using disparate formats, nomenclature or otherwise disparate presentation. The invoices may present goods and services using information that is not described in the descriptive documentation or is inadequately described in the descriptive documentation. The entity may seek to categorize the goods and services to support cost management measures. Because of the disparate or deficient presentation of the similar goods and services, it may be difficult for the entity to process the invoices in a manner that supports cost management.
It would be desirable, therefore, to provide apparatus, methods and media for processing invoice data.
Apparatus, methods and computer readable media for processing invoice data are provided. The apparatus may include, and the methods and media may involve a processor module and a machine memory module. The processor module may extract from an invoice a billing event identifier that identifies a billing event. The processor module may query an index in the machine memory module for a billing event descriptor that is designated for the billing event. The processor module may identify in the machine memory index a provisional billing event descriptor that corresponds to a derivative of the billing event identifier. The processor module may join the provisional billing event descriptor to a record corresponding to the billing event identifier. The processor module may flag the record to indicate the presence of the provisional billing event descriptor.
The objects and advantages of the invention will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:
Apparatus, methods and media are provided for processing invoice data. The one or more of the methods may be performed using the some or all of the apparatus. One or more of the media my include instructions for machine performance of some or all of the methods.
The invoice data may be present in one or more invoices that are provided by one or more vendors to a procuring entity. Table 1 shows illustrative procuring entity industries and illustrative corresponding vendor services sectors. A procuring entity may procure services from one or more vendors in a sector. It will be understood that “services” may include both goods and services.
The apparatus may include, and the methods and media may involve, a processor module and a machine memory module. The processor module may include hardware. The processor module may extract from an invoice a billing event identifier that identifies a billing event. The billing event may correspond to a service that a vendor provided to the procuring entity. The processor module may query an index in the machine memory module for a billing event descriptor that is designated for the billing event. The billing event descriptor may describe a service to which the billing event identifier corresponds.
Table 2 shows illustrative billing event descriptors for billing events that may arise in the financial services industry in connection with vendors of financial network services.
The processor module may identify in the machine memory index a provisional billing event descriptor that corresponds to a derivative of the billing event identifier. The processor module may join the provisional billing event descriptor to a record corresponding to the billing event identifier. The processor module may flag the record to indicate the presence of the provisional billing event descriptor.
The invoice may be a first invoice. The processor module may extract a plurality of second billing identifiers from a second invoice.
The apparatus may include, and the methods and media may involve, a receiver module that includes hardware. The receiver module may receive the first invoice from a first vendor; and receive the second invoice from a second vendor.
The processor module may formulate the billing event identifier derivative by removing a character from the billing event identifier. The processor module may query the machine memory index for a billing event descriptor that corresponds to the billing event identifier derivative.
If a result of the querying is null, the processor module may iteratively: (1) reformulate the derivative, by removing successive characters from the billing event identifier, and (2) query the machine memory index for a billing event descriptor that corresponds to the billing event identifier derivative.
The processor module may join a default billing event descriptor to the record corresponding to the billing event identifier.
The processor module may terminate the reformulating after a critical number of characters are removed from the billing event identifier.
The processor module hardware may extract from the invoice a billing event information item that corresponds to the billing event identifier. The processor module hardware may calculate an objective closeness metric for each of the billing event descriptors in the machine memory index, each metric corresponding to a closeness between the respective billing event descriptor the billing event information item.
The processor module hardware may define as the provisional billing event descriptor the billing event descriptor that, based on the closeness metric, is closest to the billing event information item.
The objective closeness metric may be based on a statistical prediction, such as an expected value, a maximum number of occurrences, or any other suitable predictor, that a billing event descriptor is more likely to correspond to the billing event identifier than is a different billing event descriptor.
The receiver module may receive a confirmed billing event descriptor that corresponds to the provisional billing event descriptor.
The processor module may adjust, based on a difference between the confirmed billing event descriptor and the provisional billing event descriptor, a constant upon which the objective closeness metric is based.
The methods may include extracting from an invoice a billing event identifier that identifies a billing event. The methods may include querying a machine memory index for a billing event descriptor that is designated for the billing event. The methods may include, if the machine memory index does not include the billing event: identifying, in the machine memory index, a provisional billing event descriptor that corresponds to a derivative of the billing event identifier; joining the provisional billing event descriptor to a record corresponding to the billing event identifer; and flagging the record to indicate the presence of the provisional billing event descriptor.
The methods may include, when the billing event identifier is a first billing event identifier and the record is a first record: extracting a plurality of second billing event identifiers; joining each second billing identifier to a corresponding second record; performing an analytical operation on each of the second records; and performing the analytical operation on the first record.
The extracting a plurality of second billing identifiers may include, when the invoice is a first invoice, extracting the plurality of second billing identifiers from a second invoice.
The methods may include receiving the first invoice from a first vendor; and receiving the second invoice from a second vendor.
The identifying may include formulating the billing event identifier derivative by removing a character from the billing event identifier; and querying the machine memory index for a billing event descriptor that corresponds to the billing event identifier derivative.
The methods may include, when a result of the querying is null, iteratively: reformulating the derivative, by removing successive characters from the billing event identifier, and querying the machine memory index for a billing event descriptor that corresponds to the billing event identifier derivative.
The methods may include, after the iteratively reformulating and querying, joining a default billing event descriptor to the record corresponding to the billing event identifier if the querying does not generate a non-null result.
The methods may include terminating the reformulating after a critical number of characters are removed from the billing event identifier.
The methods may include, after the terminating, joining a default billing event descriptor to the record corresponding to the billing event identifier.
The identifying may include culling the machine memory index for candidate billing event descriptors that correspond to a billing event identifier derivative; and selecting as the provisional billing event descriptor a closest one of the candidate billing event descriptors.
The selecting may include defining as the provisional billing event descriptor the candidate billing event descriptor that is most numerous among the candidate billing event descriptors.
The identifying may include extracting from the invoice a billing event information item that corresponds to the billing event identifier; calculating an objective closeness metric for each of the billing event descriptors in the machine memory index, each metric corresponding to a closeness between the respective billing event descriptor and the billing event information item; and defining as the provisional billing event descriptor the billing event descriptor that, based on the closeness metric, is closest to the billing event information item.
The methods may include outputting to an output device a first cost index and a second cost index. The first cost index may be based on the provisional billing event descriptor. The second cost index may be based on a confirmed billing event descriptor. The first cost index may be based on a plurality of billing events. The second cost index may be based on the plurality of billing events. The methods may include drawing the plurality of billing events from a plurality of invoices.
The methods may include extracting from an invoice a procuring entity consitutent identifier. The constituent may be one of a plurality of constituents. The constituent may be the procuring entity, an individual, a department, a division, a subsidiary, a corporation, a group, an organization, an affinity group or any other constituent. The constituent may be defined by a corporate structure, an organizational chart, a function, an operation, a cost-center, a profit-center, or any suitable characteristic.
The method may include querying the machine memory index for a procuring entity constituent descriptor that is designated for the billing procuring entity constituent. The method may include joining the procuring entity constituent descriptor to the record.
Table 3 shows illustrative procuring entity constituent identifiers and procuring entity constituent descriptors for a hypothetical procuring entity in the manufacturing industry.
Illustrative embodiments of apparatus and methods in accordance with the principles of the invention will now be described with reference to the accompanying drawings, which form a part hereof. It is to be understood that other embodiments may be utilized and structural, functional and procedural modifications may be made without departing from the scope and spirit of the present invention.
As will be appreciated by one of skill in the art, the invention described herein may be embodied in whole or in part as a method, a data processing system, or a computer program product. Accordingly, the invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software, hardware and any other suitable approach or apparatus.
Furthermore, such aspects may take the form of a computer program product stored by one or more computer-readable storage media having computer-readable program code, or instructions, embodied in or on the storage media. Any suitable computer readable storage media may be utilized, including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and/or any combination thereof. In addition, various signals representing data or events as described herein may be transferred between a source and a destination in the form of electromagnetic waves traveling through signal-conducting media such as metal wires, optical fibers, and/or wireless transmission media (e.g., air and/or space).
Billing event record 100 may include invoice data 102. Invoice data 102 may include a billing event identifier, billing event information items, vendor information, procurement entity constituent information, and any other invoice information. The apparatus, methods and media may extract invoice data 102 from a vendor invoice.
Billing event record 100 may include billing event descriptor data 104. Billing event descriptor data 104 may include one or more billing event descriptors. The apparatus, methods and media may extract billing event descriptor data 104 from one or more vendor billing reference guides that explain billing events.
Billing event record 100 may include billing event attribute data 106. The procuring entity may develop event attribute data 106 to characterize the billing event in a manner that supports procurement entity cost management objectives. For purposes associated with identifying a billing event descriptor that most likely corresponds to a derivative billing event identifier, billing event attribute data 106 may be referred to as “billing event descriptors.”
Billing event record 100 may include procuring entity descriptor data 108. Procuring entity data descriptor 108 may include one or more procuring entity constituent descriptors. The procuring entity may develop procuring entity data descriptor 108 to characterize the billing event in a manner that supports procurement entity cost management objectives.
A billing event identifier may logically link invoice data 102 and billing event descriptor data 104. Procuring entity information, such as a procurement entity constituent identifier, may link invoice data 102 and procuring entity descriptor data 108.
Billing event descriptor data 104 may be provided by a vendor and may describe a billing event. A vendor may provide the billing event descriptor to the procuring entity. The billing event descriptor may explain or partially explain the nature of a billing event that is identified on an invoice by a billing event identifier. The vendor may provide one or more billing event descriptors to the procuring entity in the form of a billing reference manual.
A first vendor may provide a first billing event descriptor for a first billing event. A second vendor may provide second billing event descriptor for a second billing event. The procuring entity may view the first and second billing events as being identical, similar, similar in part, or entirely different. The procuring entity may thus join billing event attributes data 106 to each billing event record to characterize the billing event in a way that is meaningful to the procuring entity and is based on vendor-provided billing event descriptors for the billing event.
Billing event records such as 100 may thus have a uniform structure and include differently structured data from different sources. A plurality of such billing events may be assembled into a data set that may be used to analyze procuring entity expenses.
Input/output (“I/O”) module 209 may include a microphone, keypad, touch screen, and/or stylus through which a user of device 201 may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output. Software may be stored within memory 225 and/or storage to provide instructions to processor 203 for enabling server 201 to perform various functions. For example, memory 225 may store software used by server 201, such as an operating system 217, application programs 219, and an associated database 221. Alternatively, some or all of server 201 computer executable instructions may be embodied in hardware or firmware (not shown).
Server 201 may operate in a networked environment supporting connections to one or more remote computers, such as terminals 241 and 251. Terminals 241 and 251 may be personal computers or servers that include many or all of the elements described above relative to server 201. The network connections depicted in
Additionally, application program 219, which may be used by server 201, may include computer executable instructions for invoking user functionality related to communication, such as email, short message service (SMS), and voice input and speech recognition applications.
Computing device 201 and/or terminals 241 or 251 may also be mobile terminals including various other components, such as a battery, speaker, and antennas (not shown).
Terminal 251 and/or terminal 241 may be portable devices such as a laptop, cell phone, Blackberry™, or any other suitable device for storing, transmitting and/or transporting relevant information.
Any information described above in connection with database 221, and any other suitable information, may be stored in memory 225.
One or more of applications 219 may include one or more algorithms that may be used to process invoice data, assemble billing event record data sets, correlate billing events and billing event descriptors, analyze billing events, report billing event analysis, and/or perform any other suitable tasks related to processing invoice data.
The invention may be operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, mobile phones and/or other personal digital assistants (“PDAs”), multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
Apparatus 300 may include invoice normalization engine 302. Invoice normalization engine 302 may receive an invoice. Invoice normalization engine 302 may map the invoice data into data structures in a billing event record such as 100 (shown in
The invoice may be an electronic invoice. The invoice may be a paper invoice. Invoice normalization engine 302 may scan the paper invoice and generate an electronic invoice from the paper invoice. The electronic invoice may include one or more invoice data fields that may include invoice data.
The electronic invoice may have a format. The format may govern the arrangement of the invoice data fields in the invoice. The format may govern the type of data structure that holds the data from an invoice data field. The format may govern the labels that are applied to the different invoice data fields. The format may be a commercial invoice format. For example, the format may be a vendor proprietary format, a commercially available invoice format or any other suitable format. The invoice may identify services that the vendor provided to the procurement entity. The invoice may include tens, thousands, or hundreds of thousands of services.
Each vendor may use one or more different formats. Invoice normalization engine 202 may receive invoices from 1, 2, 5, 10, 50, 100, 1,000 or more vendors. The vendors may provide the invoices to the procurement entity daily, weekly, monthly, quarterly, semi-annually, annually or on any other suitable schedule or on no schedule at all.
Apparatus 300 may include billing event descriptor normalization engine 304. Billing event descriptor normalization engine 304 may receive billing reference information from a vendor billing reference guide. Billing event descriptor normalization engine 304 may map the billing reference information into data structures in a billing event record such as 100 (shown in
Billing event descriptor normalization engine 304 may receive billing reference information from a vendor billing reference guide. Billing event descriptor normalization engine 304 may map the billing reference information into data structures in a billing event record such as 100 (shown in
Billing event descriptor normalization engine 304 may join to the billing event record billing event attribute data. For example, billing event descriptor normalization engine 304 may map billing event attribute data to billing event attribute data 106.
The procuring entity may use billing event attribute data 106 to categorize the event record. This may be helpful if the billing event identifier or the billing event descriptor do not lend themselves to a desired categorization.
Apparatus 300 may include procurement entity data server 306. Procurement entity data server 306 may identify one or more procuring entity constituent descriptors that correspond to a procurement entity constituent identifier. The procurement entity constituent identifier may be extracted from invoice data 102. Procurement entity data server 306 may join to the billing event record one or more procuring entity constituent descriptors that correspond to the procurement entity constituent identifier.
Apparatus 300 may include anomalous billing event correlation engine 308. Anomalous billing event correlation engine 308 may populate all or some of a billing event record such as 100 (shown in
The anomalous billing event identifier may be a billing identifier for which billing event descriptor normalization engine 304 does not have, or cannot identify, or cannot adequately identify a billing event descriptor.
Anomalous billing event correlation engine 308 may identify a provisional billing event descriptor corresponding to the anomalous billing event identifier. Invoice normalization engine 302 may join the anomalous billing event identifier to a billing event record such as billing event record 100 (shown in
Apparatus 300 may include accounting general ledger interface 310. Accounting general ledger interface 310 may perform accounting operations on a set of billing event records such as 100 (shown in
Accounting general ledger interface 310 may provide any general ledger tools. The tools may include any suitable cost management tools. The tools may operate on each billing event record as an individual record. The tools may operate on each group of billing event records as an individual “record.” Table 4 lists illustrative cost management tools and illustrative reports.
Apparatus 300 may include reporting engine 312. Reporting engine 312 may provide output based on the cost management tools. When reporting engine 312 provides a report based on billing event groups, reporting engine 312 may provide a user with the ability to view (or “drill-down” to) the billing event records that are in the group.
Processes in accordance with the principles of the invention may include one or more features of the processes illustrated in
At step 404, the system may formulate a billing event descriptor normal template. The billing event descriptor normal template may define fields in segments 112 and 114 of billing event record 100 (shown in
At step 405, the system may store, for each vendor billing reference guide, a normalized billing reference guide that is defined by the mapping of step 404.
At step 406, the system may receive vendor invoice data from one or more vendor invoices.
At step 408, the system may create and populate a billing event record such as record 100 (shown in
At step 410, the system may store the billing event records. The records may be stored for use with general ledger interface 310, reporting engine 312 or any other suitable data processing tool.
Table 5 lists illustrative explanations of fields 504.
The system may populate some fields of segment 110 based on other fields. For example, an invoice may include an invoice date, but not an invoice year-month. The system may calculate the year-month based on the date. The system may populate some fields of segment 110 based on information in the system's memory or based on user input. For example, the system may populate the invoice tracking number field based on the system's knowledge of tracking numbers for historically received invoices.
For the sake of illustration, some principles of the invention will be described using a hypothetical procuring entity that procures transportation services from different transportation services vendors.
Invoice 600 may thus be mapped into a billing event record such as 100 (shown in
Invoice 700 may thus be mapped into a billing event record such as 100 (shown in
Billing event descriptors normal template 800 may include valid values 806.
Table 8 lists illustrative explanations of fields 804 and illustrative origins of information that may be used to populate fields 804.
The system may populate some fields of segment 112 based on other fields. For example, a vendor billing reference guide may include a detailed description (Descriptor No. 5). The system may identify a procuring entity category (Descriptor No. 6) based on the detailed description. The system may populate some fields of segment 112 based on information in the system's memory or based on user input.
The system may populate fields of a billing event record segment 116 with procuring entity constituent information such as that shown in Table 3.
Vendor billing reference guide 900 may thus be mapped into a billing event record such as 100 (shown in
Table 10 shows a portion of a normalized billing reference guide for Vendor 1 based on the application of billing event descriptors normal template 800 to Vendor 1 billing reference guide 900.
Vendor billing reference guide 1000 may thus be mapped into a billing event record such as 100 (shown in
Process 1100 may begin at step 1102. At step 1102, the system may read vendor invoice data from a vendor invoice. The system may map some or all of the invoice data into a billing event record such as billing event record 100 (shown in
The system may map billing event attribute data into the billing event record.
At step 1106, the system may retrieve, from a table of procuring entity constituents, procuring entity descriptor data that correspond to the procuring entity constituent identifier. The system may map some or all of the procuring entity descriptor data into the billing event record.
The system may recursively repeat steps 1102-1106 to read lines of data from one or more invoices from one or more vendors. The system may create a new billing record such as 100 (shown in
Process 1200 may begin at step 1202. At step 1202, the system may seek in a vendor billing reference guide, a normalized billing reference guide (such as a normalized billing reference guide stored in step 405, shown in
At step 1204, the system may retrieve from a normalized billing reference guide billing event descriptors (such as those in fields 804, shown in
At step 1206, the system may return control to process 1100 (shown in
If at step 1202, the billing event identifier is not found, process 1200 may continue at step 1208. At step 1208, the system may designate the billing event as an “ANOMALOUS BILLING EVENT.” The system may do so by setting a flag in billing event attribute data 106 (shown in
At step 1210, the system may seek in a vendor billing reference guide, a normalized billing reference guide (such as a normalized billing reference guide stored in step 405, shown in
If the provisional billing event descriptor is found, process 1200 may continue at step 1212. At step 1212, the system may retrieve the provisional billing event descriptor or descriptors and insert them into the billing event record. Process 1200 may continue at step 1206. At step 1206, the system may return control to process 1100 (shown in
If at step 1210 the provisional billing event descriptor is not found, process 1200 may continue at step 1214. At step 1214, the system may insert one or more default billing event descriptors into the billing record. Process 1200 may continue at step 1206.
Process 1300 may begin at step 1302. At step 1302, the system may be used to designate a key field of a normalized billing reference guide. The key field may be a field of the normalized billing reference guide that is to be approximately matched to the anomalous billing event. For example, the key field may be the billing event identifier field. (See, e.g., descriptor number 1 (field 802) in template 800 (shown in
(In another illustrative example, the system may be used to designate as a key field the vendor summary description field. (See, e.g., descriptor number 3 (field 802) in template 800 (shown in
Any invoice data may be selected for matching to any key field data.
At step 1304, the system may formulate an approximation of the anomalous billing event. The approximation may be a derivative that is derived from a field in the invoice data. For example, the derivative may be a truncation of the anomalous billing event identifier, a text selection from a different field, such as “description,” that corresponds to the anomalous billing event identifier, or any other suitable sample or index from the invoice data that corresponds to the anomalous billing event identifier.
At step 1306, the system may determine if there is a “most likely” descriptor in the normalized billing reference guide based on a selected invoice data field and the selected normalized billing reference guide key field.
The system may find candidate key fields in the normalized billing reference guide that correspond to the derivative. The correspondence may be determined by similarity of characters, closeness of multivariate clusters or any other suitable index of closeness.
If at step 1306 a most likely candidate is found, the system may at step 1308 return control to process 1200 (shown in
If at step 1306 a most likely candidate is not found, process 1300 may continue at step 1310. At step 1310, the system may decide if further approximation should be made. The further approximation may involve broadening the derivative billing event identifier so that the derivative will correspond to a greater variety of candidate key field values. The further approximation may involve relaxing an objective criteria for designating key field values as candidates. If at step 1310, the system decides to perform further approximation, process 1300 may return to step 1304.
If at step 1310, the system decides not to perform further approximation, process 1300 may at step 1308 return control to process 1200 (shown in
Records in the billing event record database may be based on the structure of, invoice data from invoices such as 600 (shown in
Field 1402 may include a procuring entity system record ID. The procuring entity system may assign to each of the billing event records a system record ID. The system record ID may be a unique identification number.
Field 1404 may identify the vendor from which came the billing event upon which each record is based. All of the records shown in database 1400 are from Vendor 1, but a different portion of database 1400 may include records based on billing events from one or more different vendors.
Field 1406 shows a billing event identifier that corresponds to descriptor number 1 in field 802 of billing event descriptors normal template 800 (shown in
Field 1408 shows a vendor summary description that corresponds to descriptor number 3 in field 802 of billing event descriptors normal template 800 (shown in
Field 1410 shows a detailed description that corresponds to descriptor number 5 in field 802 of billing event descriptors normal template 800 (shown in
Field 1412 shows a procuring entity category that corresponds to descriptor number 6 in field 802 of billing event descriptors normal template 800 (shown in
Field 1416 shows an anomalous billing event flag that may be set in step 1208 of process 1200 (shown in
The system may formulate a derivative billing event identifier by truncating the anomalous billing event identifier (“EEE13X”). The derivative billing event identifier would be “EEE13.”
Field 1504 shows detailed descriptions that correspond to the derivative billing event identifier.
Field 1506 shows procuring entity categories that correspond to the derivative billing event identifier.
The system may identify “Foreign House Brand Wholesale” as the most likely descriptor for derivative billing event identifier “EEE13” and, thus, for anomalous billing event identifier “EEE13X”.
Values of Vendor Summary Description field 1808 and Detailed Description field 1810 remain unknown. Vendor Summary Description field 1808 and Detailed Description field 1810 are based on information provided by a vendor billing reference guide such as 900 (shown in
One of ordinary skill in the art will appreciate that the elements shown and described herein may be performed in other than the recited order and that one or more elements illustrated may be optional. The methods of the above-referenced embodiments may involve the use of any suitable elements, elements, computer-executable instructions, or computer-readable data structures. In this regard, other embodiments are disclosed herein as well that can be partially or wholly implemented on a computer-readable medium, for example, by storing computer-executable instructions or modules or by utilizing computer-readable data structures.
Thus, apparatus and methods for processing invoice data have been provided. Persons skilled in the art will appreciate that the present invention can be practiced by other than the described embodiments, which are presented for purposes of illustration rather than of limitation. The present invention is limited only by the claims that follow.
