System and method for management and verification of invoices
Embodiments of the present invention include architectures and methods for automated management of invoices. Embodiments of the present invention may include techniques for receiving and unifying invoice data, retrieving information about each invoice, verifying each invoice and resolving invoice exceptions. The present invention includes software components for efficiently processing invoices. In other embodiments, the present invention includes methods of processing an invoice.
Latest SAP AG Patents:
- Systems and methods for augmenting physical media from multiple locations
- Compressed representation of a transaction token
- Accessing information content in a database platform using metadata
- Slave side transaction ID buffering for efficient distributed transaction management
- Graph traversal operator and extensible framework inside a column store
This invention is a continuation of and claims the benefit of priority from U.S. patent application Ser. No. 10/980,114, filed Nov. 1, 2004, entitled “System and Method for Management and Verification of Invoices.”
BACKGROUNDThe present invention relates to data processing and data management, and in particular, to a system and method for automated management and verification of invoices and data associated with invoices.
When two entities engage in a business transaction, an invoice is typically generated to capture and memorialize important information about the transaction. For example, an invoice commonly includes a list of goods delivered or services performed, with corresponding prices, quantities, descriptions and charges. As a company grows, keeping track of invoices from suppliers of goods or services (i.e., vendors) can quickly become a difficult task. Different departments within a company may use hundreds or even thousands of different vendors. Furthermore, vendors may send their invoices to different people across the company. Many companies typically have internal or external departments for receiving and processing invoices, but the employees in such departments may have very little information about the nature of the transaction leading to the invoice. Thus, tracking and promptly paying valid invoices, and detecting and correcting erroneous or fraudulent invoices, is a major problem facing today's business community.
To manage and track the flow of invoices, companies often require vendors to associate additional information with each invoice such as a purchase order number, information about which business unit in the company ordered the goods or services, and various tracking and/or reference numbers. Additionally, vendors typically include their name, address and various reference and tracking numbers of their own on their invoices. However, one problem that arises is that the information provided on different invoices can vary drastically from vendor to vendor. Moreover, even if the same information is provided across all vendors, the “format” of the information may be different. For example, the format of the invoice document itself may “look” different because different information is presented in different physical portions of each invoice. As another example, a vendor based in the United States may bill in U.S. Dollars while a vendor based in Germany may bill in Euros. Other problems commonly associated with invoice processing include processing multiple invoices sent by the same vendor for the same job or processing invoices with missing or invalid information, to name just a few. As the size of an organization grows, processing invoices with these and other problems can become economically burdensome because of the increased difficulty for accurate and efficient human processing of invoices.
However, existing user-centric invoice management systems are expensive and highly susceptible to errors. As the number of invoices processed by a company grows, the necessary human interaction may require hundreds or even thousands of employees to manually enter paper invoices and handle exceptions and further processing. Additionally, because human invoice processors are often far removed from direct interaction with the vendor, such individuals are more likely to make a number of different mistakes including overlooking invalid or erroneous invoice data, paying out the same invoice two or more times (i.e., paying on duplicates) or paying out the wrong amount, to name just a few. These and other mistakes and inefficiencies in processing invoices can become very expensive as a company grows.
Thus, there is a need for a system that can process invoices in a way that will improve the efficiency, speed and accuracy of invoice processing over existing techniques. The present invention solves these and other problems by providing an invoice processing system and method for automated management and verification of invoices and the data associated with the invoices.
SUMMARYEmbodiments of the present invention include architectures and methods for automated management of invoices. Embodiments of the present invention may include techniques for receiving and unifying invoice data, retrieving context information about each invoice, verifying each invoice and resolving invoice exceptions. The present invention includes software components for efficiently processing invoices. In other embodiments, the present invention includes methods of processing an invoice.
In one embodiment, the present invention includes an invoice management system comprising a unification software component for receiving invoice data from a plurality of different sources in a plurality of different formats and transforming the invoice data into a common format, an invoice data repository for storing the transformed invoice data, a context builder for automatically retrieving additional information corresponding to the invoice data, an invoice processor for verifying each invoice according to a plurality of rules, and an exception manager for processing each unsuccessfully verified invoice. The invoice management system may further include a index database for performing searches.
In one embodiment, the present invention includes a method of processing invoices comprising storing invoice data corresponding to a plurality of invoices in a repository, automatically searching a plurality of systems for information corresponding to each invoice, and automatically performing a plurality of verification checks on each invoice.
In one embodiment, the present invention includes a method of processing invoices comprising storing invoice data corresponding to a plurality of invoices in a repository, automatically performing a plurality of verification checks on each invoice, creating an exception when at least one of the invoices fails at least one of the verification checks, and processing the exception in accordance with one of a plurality of exception handling procedures.
In one embodiment, the present invention includes a method of processing invoices comprising receiving invoice data from a plurality of different sources in a plurality of different formats, transforming the invoice data into a common format, storing the transformed invoice data in a repository as an invoice, automatically retrieving additional information corresponding to the invoice, and automatically verifying the invoice using a plurality of rules, wherein if the invoice is verified the invoice is automatically posted, and if the invoice data is not verified an electronic exception case is created.
The following detailed description and accompanying drawings provide a better understanding of the nature and advantages of the present invention.
BRIEF DESCRIPTION OF THE DRAWINGS
Described herein are techniques for managing, verifying and otherwise processing invoice data. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include obvious modifications and equivalents of the features and concepts described herein.
Embodiments of the present invention include a software architecture for managing and verifying invoice data.
Because the present invention allows invoices to be received from different sources, the incoming invoice data is typically received in different formats. For example, invoice data may be received as email text, Adobe® “.pdf” files, text documents, images, extended markup language (“XML”), electronic data interchange (“EDI”) or other structured or unstructured, standard or non-standard formats. According to one embodiment of the present invention, invoice management system 210 may include a unification engine 211 that transforms the incoming invoice data into a common format. The step of transforming the incoming structured and/or unstructured invoice data into a common format is sometimes referred to as a “normalization” step. The normalized invoice data may then be stored in an invoice data repository 212 for centralized access and management. In one embodiment, the invoice data is stored in an XML format, which may have a predefined schema (e.g., EBPXML). Of course, other formats could be used. For example, invoices may be stored in table form using relational databases. In other embodiments, invoices may be stored and/or processed as objects (i.e., invoice objects). Invoices may further include references to relevant information stored as tables or objects in other systems (i.e., context).
One problem associated with invoice management and processing is that it is often difficult to effectively process an invoice based solely on the invoice data received from the vendor. Furthermore, the invoice data received from a vendor is often incomplete, incorrect or outright fraudulent. In one embodiment, invoice management system 210 includes a context builder 214 coupled to invoice data repository 212. Context builder 214 may be used to automatically gather additional information corresponding to each invoice, so that each invoice may be processed faster and more efficiently. Context builder 214 may access other data sources both inside and outside the company to gather additional information corresponding to an invoice. For example, context builder 214 may access data in other software systems or applications such as an inventory application 220 or purchasing application 221. Furthermore, context builder 214 may access other structured or unstructured data from other data sources such as network servers, local computers, document repositories or document management systems (to name just a few) to gather information about purchase orders, goods received, business partners, general ledger, contracts and contacts. In one embodiment, context builder 214 may allow users or administrators to specify what other sources or types of additional information may be beneficial for processing invoices (as opposed to programmers). Accordingly, relevant data may be gathered by context builder 214 and used to augment incoming invoice data with relevant context so that the invoice may be processed more efficiently. For example, in one embodiment context builder 214 automatically populates invoice data fields in order to reduce or eliminate data entry by a human user. Additional features and functionality may be incorporated into context builder 214 as described below.
Invoice management system 210 further includes an invoice processor software component 213 coupled to both invoice data repository 212 and context builder 214. Invoice processor 213 may use data from invoice data repository 212 and the data gathered by context builder 214 to automatically verify the invoice data. For example, invoice processor may perform checks for duplicate invoices, errors & omissions, fraud, and routing errors. If the invoice data is verified successfully, the invoice data may be posted in a financial application 250, for example. However, if the invoice data is not verified, an exception manager 215 may be invoked to report problems to relevant personnel and control the resolution of the problem.
In one embodiment, exception handler 215 provides functionality to control the processing of invoice exceptions and may further facilitate collaborative resolution of invoice problems. One advantage of the present embodiment is that exception handler 215 may act as a single point for capturing and processing of exceptions and for automating the dispute resolution process using collaborative tools. For example, in one embodiment all exceptions are stored in an exception repository (not shown) for centralized management and an “exception case” may be created by the system. The system may intelligently forward the exception case to different individuals in the company or external individuals if a particular individual's participation is necessary for resolution of the exception. The information transferred between individuals may be intelligently controlled so that each individual only receives the information necessary for solving particular problems. For example, exception manager 215 may forward information about the exception to users in different groups in company 230 such as accounts payable 230A, purchasing 230B, requisitions (“REQ”) 230C, cost center management (“CCM”) 230D or goods received (“G/R,” e.g., a manufacturing facility) 230E if the participation of employees in those groups is required to resolve the issue. Exception manager 215 provides flexible automated collaboration between such users and the vendors associated with each invoice. For example, in one embodiment exception manager 215 manages notifications pertaining to exceptions between one or more employees in the company 230 and employees at a vendor 240. Vendor 240 may receive invoice information corresponding to an exception case from a user over email along with comments and an optional interactive form. Vendor 240 may then dispute the exception (e.g., if the exception pertains to a duplicate or fraudulent invoice), confirm the exception or provide additional information via the interactive form, for example. Once the exception is resolved, the exception case is closed and the invoice data may be posted.
Invoice management system 210 may further include a search engine including, for example, a search index 216 that may be accessed by invoice processor 213, context builder 214 and exception manager 215. Invoice processor may use search engine capabilities to access the search index to search for invoice information in the same system or other systems. For example, an index of processed invoices may be maintained, and a search through the index may be made as new invoices enter the system (e.g., for duplicate detection). The index may be a combined subset of multiple database tables that includes a variety of invoice data. Simple checks for the same date or same amount may be performed by a simple database search. However, more complex searches such as “similarity searches” may be performed to find invoice data or context for an invoice. In one embodiment, information may be retrieved using similarity search techniques disclosed in commonly-owned concurrently filed U.S. Patent Application No. Unassigned (Attorney Docket No. 000005-000400US; SAP Docket No. 2004P00889 US) entitled “Information Retrieval Method with Efficient Similarity Search Capability,” naming Alexandru M. Caracas, Tobias Niekamp and Sascha H. Schmitt as inventors, the contents of which is hereby incorporated herein by reference in its entirety. Context builder 214 may access the search index 216 for searching for additional information about the invoice. Finally, exception manager 215 may access the search index to allow users to search exception cases or context as described below. Search functionality may also be supplied to users during exception management.
Invoice management system 210 may further include an integration layer as shown in
Exemplary context information may include document context, organizational context and people context. Document context may include the purchase order associated with an invoice, the requisition upon which the purchase order was based, the blanket order (e.g., a contract) that the purchase order refers to or relates to, goods receipts associated with the invoice, service confirmations, payment information for invoices that have been posted, prior invoices for the purchase order associated with the invoice, advanced shipment notifications associated with the invoice, bills of lading for goods received or links to scanned versions of all such structured or unstructured documents. Organizational context may include the purchasing group responsible for the purchase order, the purchasing organization, the plant(s) referred to in the line items of the purchase order, the cost centers, projects, work orders or assets for which the purchase order was created, for example. People context may include the purchasing agent, the supplier contact for the purchase order, the requisitioner, the receiving clerk, the person responsible for the cost center, project, work order, or asset, or the accounts payable clerk that processed a previous invoice.
The context builder may be used to autopopulate invoice data. First, the system may search an incoming invoice for a purchase order number. From the purchase order number, the system may use the index database to access the PO. From the PO, the system searches for the purchase requisition (“PR”), and from the PR the system can acquire the requisitioner. Once the system knows the requisitioner, the system can search for the requisitioner's cost center by accessing employee reference (e.g., an human resources database) and populate the cost center automatically. For an approval workflow, the system searches for hierarchical information for the requisitioner's organization and send email to his manager automatically. Of course, the above described process is just one example of how autopopulation may be carried out. Autopopulation algorithms and rules may be defined and altered in accordance with different system requirements. Thus, context may be gathered from across a wide range of information sources, and the information from one or more sources may be used to access yet further information to gather relevant context and autopopulating the fields of the invoice.
Embodiments of the present invention also support invoice templates, which may be managed by template manager 902. Invoice templates allow a user to define characteristics of incoming invoices (e.g., for a particular vendor) based on historical transactions. An invoice template may include a collection of characteristics that a user may look for when an invoice enters the system. Invoice templates may include a plurality of fields that have predefined values (e.g., the vendor's name, identification number, address or other characteristics relating to that vendor that do not change from invoice to invoice). As invoices enter the system, a template (e.g., corresponding to a particular vendor) may be accessed and compared to the incoming invoice. When a template field has a value, each incoming invoice must have that same value in the corresponding field. For example, when an invoice is received and transformed, the system may determine who is sending the invoice by examining the name and/or vendor number. Next the system may access a template corresponding to the particular vendor and compare one or more templates to the invoice. By comparing the templates predefined characteristics of the invoice to the incoming invoice, the system can determine whether or not there is a variance in an incoming invoice from previously received invoices. Embodiments of the present invention also include templates having one or more fields with a range. In this case, when an invoice is compared against the template, the value of the field in the invoice must be in the range specified in the template. Templates may also include lists of values (e.g., multiple addresses). In this case the invoice must have a value from the template list in a corresponding invoice field.
In one embodiment, invoice processor 1000 includes a process manager 1010 and verification component 1020 (sometimes referred to as an “exception inspector”). Process manager 1010 allows users to specify verification rules and exception work flow rules and handling procedures, retrieves invoices from invoice repository 1050 and controls the routing in accordance with the specified rules and procedures. Verification component 1020 executes the rules on each invoice as they are retrieved from the repository 1050. Verification component 1020 may provide a list of checks applicable to an incoming invoice and the order of execution, and apply the checks to each invoice. Details of verification failures may be returned and stored for further analysis or use. Verification component 1020 allows for configuring each check as specified by a user, and may support activation or deactivation of each check as desired by a user. In one embodiment, all exceptions occur before the data in a backend system is changed by the invoice posting so that roll-back is not an issue until the invoice gets posted. Embodiments of the present invention may include some or all of at least the following verification checks:
Template Check
Invoice data is compared to a template that has been setup by the party receiving the invoice. Example: If the template has been defined such that the PO number field is required and vendor must be “SAP,” and the system receives an invoice with PO Number blank and vendor “SAP,” then this check fails.
Missing Data Check
The invoice and its context are checked to see if it contains all mandatory information. If invoice date, invoice amount and vendor name have been specified in the verification rules as mandatory, then if any one of these fields is blank, this check fails.
Invalid Data Check
The information provided in the invoice does not conform to standards or does not exist in the system (e.g., a unit of measure should confirm to a standard, date is not in the correct format, a tax distribution is not as specified by the company, the vendor is new and does not exist in the system, PO number does not exist in company's system, the requisitioner is not an employee of the buying organization,
Duplicate Invoice Check
The incoming invoice and its context are compared with existing invoices. The criteria for what fields are compared and whether an exact match or a fuzzy match is used may be configurable.
Non-PO Invoice Check
If the incoming invoice has no PO then the system may initiate a predefined “approval” workflow, which may route the invoice to the cost center manager, for example.
Line Item Mismatch Check
The system cannot match the PO Line Item to the Invoice Line Item (e.g., the descriptions on line items of the invoice and the PO do not match).
Price Variance Check
Detects differences in pricing between expected prices specified in a PO and the actual price indicated in the invoice received from the supplier. Example cases include: item price has changed, negotiated discounted price was not applied, freight charges are not specified in PO but appear in invoice, incorrect tax applied, etc. Price comparisons may be done at the item level as well as total gross amount. Prices may be compared using a configurable tolerance factor specified as a percentage or absolute value rather than for exact equality (e.g., price in invoice must be within 2% of price in PO, or within $1 of expected price).
Quantity Variance Check
Quantity variance can occur when the invoice comes in before the goods are shipped, when the good are received but the GR clerk hasn't yet entered then into the system or when the goods are received but the quantity received does not match invoice quantity.
As mentioned above, in some embodiments the exception manager may be role based (i.e., exception manager determines at least some of the users involved in a exception handling procedure). Moreover, in some embodiments the exception manager may determine how particular users are contacted (e.g., email, etc. . . . ), when particular users are contacted (i.e., according to exception handling rules) and what information such users receive. Thus, embodiments of the present invention may include storing role information (e.g., exception handlers job information), communication information, exception routing rules or data filtering rules to facilitate more efficient exception handling.
In one embodiment, exception manager 1120 provides an “Inbox” user interface. The Inbox and the data retrieved and displayed in the Inbox may be automatically modified based on different user roles. A user may select one invoice from a list and drill-down to see the invoice data and particular exception for the invoice of interest (e.g., header and line item information). Context information such as purchase order, vendor, related invoices, goods receipt, contacts, attachments and case history are accessible either directly in the exception store or through a reference to another repository. Exception manager 1120 may be coupled to an index database (not shown) to allow a user to search through invoices or to manually search for additional information about an invoice. Exception manager 1120 may also provide filtering for inbox management. For example, a user may apply a filter to reduce the number of invoices shown in the Inbox and focus on specified subsets of exception cases. Exception manager 1120 may also support posting, deleting, editing and forwarding of invoices as required for exception handling, or the ability to email or chat with contacts concerning particular exception cases. Exception manager 1120 may further track the history of an invoice so different participants can gain a full understanding of the history of each case. In one embodiment, after an invoice is processed by the exception manager and the exception resolved, the invoice processor performs the verification on the invoice again. Dispute management component 1130 may be integrated into exception manager 1120 or operate as a stand alone component providing work flows and data access for resolving disputed invoices.
The following are example procedures for resolving exceptions corresponding to the above-mentioned verification checks.
Template Exception Handler
If a template check fails then the system may highlight the fields that made the template check fail and allow the user to correct the invoice or forward the invoice to another contact for resolution.
Missing Data Handler
If the requisitioner information is available then the invoice is routed to the requisitioner through an email form. The requisitioner can then attempt to fill up the data or send it back to the vendor or any other contact who might have this information. The system may search the context information and provide suggestions to the user.
Invalid Data Handler
When the invoice does not adhere to standard formats, the invoices are sent back to the vendors for correction.
When the vendor does not exist in the system, a work item is sent to the purchasing officers Inbox. He can then open the item, look at the invoice and its context, create the vendor and resolve the open item.
When the PO number specified in the invoice does not exist in the system, an interactive form is sent to the requisitioner via email, he can then correct the PO number or forward the exception to the vendor for resolution.
When errors like date mismatch, tax distribution problems or requisitioner not found occur, the vendor is directly notified of the problem through an interactive form.
Duplicate Invoice Handler
The original invoice and the duplicate invoice are displayed side by side to a user such as an AP clerk. He can then decide to reject or accept the new invoice. If he rejects the invoice an email is sent to the vendor with the complete context of the two invoices and their scanned images. The vendor can dispute this duplicate if needed.
Non PO Authorization Handler
The cost center of the requisitioner is checked and the invoices forwarded to his manager for approval. The invoice is sent through email as an interactive form and authorization is through a digital signature.
Line Item Mismatch Handler
The invoice line items and the PO line items are displayed side by side, and a user such as an AP clerk can select the appropriate line item in the invoice that matches the PO. If he cannot make this decision then he can forward this exception to the requisitioner for resolution.
Price Variance Handler
If the price on the PO is incorrect, a user such as an AP Clerk may change the PO pricing. If the price variance is above the limit then approval by an AP Manager may be needed before accepting Invoice. Limits may be configurable. If pricing in an invoice is not correct then allow the system to send the invoice back to the vendor.
Quantity Variance Handler
If the invoice comes in before the goods are received, the exception handler does not process this invoice for a certain number of days. The number of days the system will “WAIT” may be configurable. Once this time frame has passed, and if the good still haven't been received, a work item is sent to the GR clerk for verification. The GR clerk can then forward this exception to the vendor for resolution. If the goods have come in, the GR clerk can confirm his work item as received. If the quantity received doesn't match the invoice quantity then the AP clerk is given the option of short payment, in which case he can pay for the goods already received and notify the vendor of the same.
EXAMPLE USER INTERFACES AND WORK FLOWS
At 1201A, a user (“U1”) employed by a vendor mails or faxes a paper invoice to the company buying the vendor's goods or services. At 1202, the company receives the invoice, and another user (“U2”) may enter the invoice data into the system using an invoice entry software component. Alternatively, invoice data in electronic form at 1201B can be transmitted automatically to an invoice management system. At 1203, the invoice data is processed by the invoice management system. At 1204, the system detects a possible duplicate and sends a notice to U2 or another user (“U3”) employed by the company (e.g., in a different department) along with the invoice data, information from the context builder and suggested actions. For example, the notice may appear in an “Inbox” as described in more detail below. U2 may review the information and determine that it is in fact a duplicate. U2 may then quickly mark the duplicate for deletion and automatically transmit an electronic notification to U1. The electronic notification may include some or all of the invoice data, invoice context information and an electronic form. At 1206, the electronic notification is received by U1 (e.g., in an “Inbox”). When U1 receives the notification, the information can be reviewed quickly and the duplicate can be confirmed or disputed quickly as shown at 1207. If the duplicate is confirmed at 1209, it may be routed to invoice management system at 1210 and automatically deleted with no further user interaction. If U1 disputes that the invoice is a duplicate, a dispute signal may be sent to U2 for further processing.
Exceptions may be presented to a user in the form an “inbox” (i.e., an exception inbox) 1310. Exception inbox 1310 may include one or more rows each corresponding to an exception such as “Duplicate” 131I indicating the existence of a potentially duplicative invoice, “Missing Information” 1312 indicating that an invoice has been received without certain information, and “Line Item Mismatch” 1313 indicating that one or more line items on the invoice (i.e., information about individual items purchased from the vendor) do not match up with line items in the invoice management system (e.g., information about individual items requested in a purchase order). The exceptions may be color coded so that each exception is displayed in a different color. A user may access and process an exception by selecting one of the exception row entries (e.g., by double-clicking on a row entry with a mouse).
Invoice data and context information may be displayed as fields (i.e., columns) for each exception in an Inbox. For example, the first field 1314 may indicate the type of exception. Invoice data displayed with each exception may include the “source” of the invoice 1315 (e.g., Paper/OCR, Fax/OCR, EDI, XML), “invoice number” 1316, “invoice date” 1317, invoice “amount” 1318, “vendor” 1319 and a “description” 1320, for example. Other invoice data or context information may also be displayed. Inbox 1310 may include a display of summary information 1321 including the total number of invoices in the “inbox,” and the number of each type of exception. Inbox 1310 may allow a user to enter a new invoice (e.g., using electronic button 1322), post invoices 1323 or delete invoices 1324.
For example, both the original invoice 1325B and the new invoice 1325A are displayed side by side at 1326A and 1326B for easy comparison. Invoice displays 1326A and 1326B may include incons 1399A and 1399B indicating the source of the invoice. For example, icon 1399A may display a graphic indicating that the source of the invoice was a facsimile (i.e., “FAX”). Similarly, icon 1399B may display a graphic indicating that the source of the invoice was electronic (e.g., an image of a computer). Additionally, invoice displays 1326A and 1326B may include the following invoice data grouped and displayed as entries in the upper portions 1327A and 1327B: invoice number, an accounting document number (“Acc. document”), purchase order number (“PO”), the name of the “Requisitioner,” invoice data, posting date, vendor identification, customer name, customer address, customer phone number, customer fax, and the user's email. The following invoice data is grouped and displayed side by side in tables 1328A and 1328B: “Description,” quantity or hours ordered, quantity or hours received, price or rate, and total for a plurality of line items. The following invoice data is grouped and displayed side by side: payment mailing information 1329A and 1329B (e.g., the name, address, city, state, zip code, phone number and fax number of the vendor), the terms of payment 1330A and 1330B (e.g., “Net 30”), and tables 1331A and 1331B including subtotal, tax (if any), shipping costs, miscellaneous expenses and balance due.
GUI 1300B further includes features for retrieving and displaying other important information useful for streamlining the management and processing of invoices. For example, invoice management system may retrieve and display detailed invoice information, detailed line item information or an image of an invoice if a user selects “Detailed Invoice” 1333A, “Detailed Line Items” 1333B or “Scanned Invoice” 1333C, respectively. In one embodiment, a user may also retrieve and display scanned invoices by selecting link 1332A (“Compare Scanned Invoices”).
A user may access yet more information about an invoice by selecting “Detailed Invoice” view (e.g., by accessing link 1333A in
Invoice log 1335 may be used to track the event history of the invoice. For example, invoice log 1335 may include the date, event and name of the person involved in the event. This information is displayed at 1335A. Furthermore, “Other Documents” 1334 may include accessing a variety of documents relating to the invoice, such as a materials description 1334A, a work description 1334B or other related documents such as a contract pertaining to the invoice, for example. Since a variety of users may access the invoice during processing, different users may attach different relevant documents so that relevant documentation pertaining to the invoice is readily available for access and review through GUI 1300D. Documents may be attached by typing in the name of the document at 1334C or browsing the network and selecting particular files using the “Browse” feature 1334D.
Different users may attach notes to the invoice by typing text into field 1337A. The text may be posted by selecting “post it” 1337B, for example. A list of notes may be displayed at 1337C along with the date the note was posted (“Date”), the text (“Notes”) and an identification of the user who entered the note (“Entered By”).
In one embodiment, an invoice management system includes an integrated communication system that allows different users to correspond about invoice issues. For example, a user may correspond with contacts automatically using “Contacts” 1336. Additionally, a user may enter contact information corresponding to each invoice. For example, at 1336A, a user may enter a contact's name or email or both. The contact is added to the system by selecting “Add Contacts” 1336B. The contacts associated with the invoice are listed at 1336C along with “Role” and name (i.e., “Contact”) fields. Roles may include vendor or company groups such as requisitioner, cost center manager, A/R manager, A/P manager or A/P clerk, for example. A user may correspond with a contact by creating a new email message, chat session or other electronic communication.
Referring again to
In other embodiments, an invoice management system may send notifications to different users within the company to resolve the exception. For example, in one embodiment, the invoice management system may send a notification to a requisitioner if requisition information is available. The requisitioner may receive an electronic form, for example, and update the invoice data and return the updated information to the system automatically. The requisitioner may forward the notification to the vendor or other users in the company (e.g., in other departments). In one embodiment, if vendor information is not available, an exception is set to a user in the company (e.g., a purchasing officer). The user may examine the invoice data and context, assign a vendor and resolve the exception, or forward the notification to another user more likely to have the required information. In another embodiment, when a purchase order specified in the invoice does not exist in the invoice management system, an interactive form may be sent to the requisitioner as a notification (e.g., email). The requisitioner may then correct the purchase order number or forward the exception to the vendor for resolution. Thus, the flexibility of the integrated data and communication techniques of the invoice management system described herein may be used to resolve many different types of invoice exceptions efficiently through streamlined interaction with relevant information holders.
In one embodiment, when a missing information notification is sent to a vendor, an exception is created and a “Missing Information” exception 1312 appears in an exception inbox as shown in
A user may mouse click one of the blocked invoices to obtain a more detailed view. For example, the invoice at 1710 has been blocked waiting for approval for 37 days. A user may mouse click the “Approval” invoice 1710 to obtain more information about the exception.
In one embodiment, the notification is an email including invoice data and an electronic signature (i.e., a digital signature). For example,
The following specification is one possible implementation of an exception pool that may be used in an invoice management system. While the following example illustrates a table-based implementation, it is to be understood that other implementations may be used. For example, the exception repository could be implemented as objects that are associated with an invoice or invoice object. The following Tables are examples of TABLE TYPE
Definitions:
A) Domain
B) Data Element
C) Structure
D) Table Type
The following Tables are examples of TABLE DEFINITIONS. The exception pool may include a table BBPD_IMS_EXPPOOL, which is the exception pool that contains exceptions related to invoices. This table may be used as the core table for exception processing. There may also be other tables that contain useful information. Table BBPD_IMS_EXPPOOL has the following structure:
The exception pool may include a Lock Object table E_IMS_EXC, which is lock object for synchronization of the exception pool.
The exception pool may include a Table BBPD_IMS_EXPREF, which is a reference to another item such as a PO, Invoice or context. These items could either reside in a reference pool or the invoice pool. There may be multiple reference items for an exception.
The exception pool may include a plurality of Agent Application Program Interfaces (“APIs”) that allow external access for retrieving exceptions, searching exceptions, modifying exceptions or adding exceptions. For example, a user may retrieve an exception according to the input exception ID. References related to the exception will also be retrieved. A warning embedded in an export parameter E_RET may indicate that the exception with the specified ID does not exist.
The exception pool may include an Agent API that searches for exceptions with specified field values. References related to these exceptions are also retrieved. A user inputs an IS_INVOICE_EXCEPTION_UI structure, whose fields specify the searching criteria. An empty field implies that there're no requirements for this field. If no records satisfy those criteria an empty export parameter ET_INVOICE_EXCEPTION would be returned.
The exception pool may include an Agent API that modifies the exception specified by the input parameter IS_INVOICE_EXCEPTION_UI's ID field. If the input parameter's fields are empty, such fields would not influence the exception pool. All the references related to the specified exception will be deleted first, and new references will be created according to the REFERENCES field of the input parameter. Redundant fields in the reference pool may be set with the values contained in IS_INVOICE_EXCEPTION_UI itself, rather than the attached REFERENCES. This measure may be used to keep the consistency between the BBPD_IMS_EXPPOOL and BBPD_IMS_EXPREF database tables. One cannot make a reference's fields different from its related exception with BBP_IV_IMS_MODIFY_EXCEPTION.
The exception pool may include an Agent API that adds an exception reference. Redundant fields such as EXP_ID and INV_ID may be set according to the related exception, rather than the fields of the input I_EXPREF. This may be used as another measure to keep the consistent of IMS_INVEXP and IMS_EXPREF tables.
Embodiments of the present invention may include a search engine to support invoice information retrieval. Techniques that may be used to search for information are disclosed in U.S. patent application Ser. No. 10/789,426, entitled “Fast Aggregation of Compressed Data Using Full Table Scans,” filed Feb. 27, 2004 by Stefan Biedenstein et al., the contents of which is hereby incorporated herein by reference in its entirety. Additional techniques that may be used to search for information are disclosed in U.S. patent application Ser. No. 10/789,812, entitled “Merging Partial Results into Single Result,” filed Feb. 27, 2004 by Jens-Peter Dittrich et al., the contents of which is hereby incorporated herein by reference in its entirety.
The above description illustrates various embodiments of the present invention along with examples of how aspects of the present invention may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present invention as defined by the following claims. For example, an invoice management system may include some or all of the innovative features described above. Additionally, while one embodiment of an invoice management system may be advantageously implemented as a stand-alone software system, features and advantages of the present invention may also be obtained by incorporating the methods and/or software systems defined by the following claims as part of one or more existing systems. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents will be evident to those skilled in the art and may be employed without departing from the spirit and scope of the invention as defined by the claims.
Claims
1. An invoice management system comprising:
- an invoice processor for receiving a plurality of invoices and automatically verifying each invoice according to a plurality of rules; and
- an exception manager for processing invoices that fail verification.
2. The invoice management system of claim 1 further comprising an exception repository.
3. The invoice management system of claim 1 further comprising a plurality of work flows.
4. The invoice management system of claim 3 wherein the plurality of work flows include at least one of a duplicate invoice handler, a missing data handler, an invalid data handler, an authorization handler, a line item mismatch handler, a price variance handler, a quantity variance handler, a template exception handler, or a customized work flow.
5. The invoice management system of claim 1 wherein the exception manager includes an integrated communication system.
6. The invoice management system of claim 1 further comprising a search engine coupled to the exception manager.
7. A computer implemented method of processing invoices comprising:
- automatically verifying invoices according to a plurality of rules;
- generating an invoice exception when an invoice is not verified;
- associating data with the invoice exception; and
- storing the invoice exception in an exception repository.
8. The method of claim 7 wherein invoice data and context information are stored in the exception repository.
9. The method of claim 7 further comprising accessing context information through a reference to another repository.
10. The method of claim 7 further comprising initiating one of a plurality of exception work flows to resolve the exception.
11. The method of claim 10 wherein different work flows are automatically initiated based on the type of error that triggered the exception.
12. The method of claim 10 wherein the work flows are customized by a user.
13. A method of processing invoices comprising:
- automatically verifying an invoice according to a plurality of rules;
- generating an invoice exception if the invoice is not verified;
- retrieving data associated with the invoice exception; and
- displaying the retrieved data to a user.
14. The method of claim 13 wherein the data associated with the invoice exception is displayed to a user in an exception inbox.
15. The method of claim 14 wherein the exception inbox includes one or more rows corresponding to invoice exceptions, and wherein invoice data is displayed as columns.
16. The method of claim 13 wherein if the invoice exception is a duplicate invoice exception, then the method further comprises retrieving and displaying data corresponding to an original invoice and a duplicate invoice.
17. The method of claim 16 further comprising retrieving and displaying images of the original invoice and duplicate invoice.
18. The method of claim 13 further comprising displaying invoice data and context data for an invoice in a detailed invoice view.
19. The method of claim 13 further comprising sending an electronic notification of the invoice exception to one or more users.
20. The method of claim 19 wherein the electronic notification includes at least a portion of associated invoice data or context information.
21. A computer-readable medium containing instructions for controlling a computer system to perform a method of processing invoices comprising:
- automatically verifying an invoice according to a plurality of rules;
- generating an invoice exception if the invoice is not verified;
- retrieving data associated with the invoice exception; and
- displaying the retrieved data to a user.
22. The computer-readable medium of claim 21 wherein the data associated with the invoice exception is stored in an exception repository.
23. The computer-readable medium of claim 21 wherein if the invoice is not verified, the data associated with the invoice exception is processed according to at least one exception work flow.
24. The computer-readable medium of claim 21 wherein the data associated with the invoice exception is displayed to a user in an exception inbox.
25. The computer-readable medium of claim 24 wherein the exception inbox includes one or more rows corresponding to invoice exceptions, and wherein invoice data is displayed as columns.
26. The computer-readable medium of claim 21 wherein if the invoice exception is a duplicate invoice exception, then the method further comprises retrieving and displaying data corresponding to an original invoice and a duplicate invoice.
27. The computer-readable medium of claim 26 further comprising retrieving and displaying images of the original invoice and duplicate invoice.
28. The computer-readable medium of claim 21 further comprising displaying invoice data and context data for an invoice in a detailed invoice view.
29. The computer-readable medium of claim 21 further comprising sending an electronic notification of the invoice exception to one or more users.
30. The computer-readable medium of claim 29 wherein the electronic notification includes at least a portion of associated invoice data or context information.
Type: Application
Filed: Aug 10, 2005
Publication Date: May 4, 2006
Applicant: SAP AG (Walldorf)
Inventors: Ramshankar Venkatasubramanian (Santa Clara, CA), Hartmut Vogler (Foster City, CA), Eckhard Farrenkopf (Mountain View, CA), Heinz Kagermann (Leimen), Heinz Roggenkemper (Los Gatos, CA), Suresh Babu (Los Altos, CA), Hila Schlank (Sunnyvale, CA)
Application Number: 11/201,072
International Classification: G06Q 40/00 (20060101);
