Abstract:
A system and method is provided for an electronic invoice presentment and payment management service. The system and method automatically link electronic purchase orders, invoices, receipt-of-goods documents, and other transaction-related information to a payment card transaction, such as a purchasing card transaction. The system may be used in conjunction with existing infrastructure and the systems currently employed by a buyer organization and a supplier organization. The system provides for the delivery of Level III data (invoice detail) with every payment card transaction and automatically inputs this Level III detailed transaction data into the buyer&#39;s accounts payable system and enterprise resource planning system.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]    This application claims priority to the following provisional applications which are incorporated herein by reference in their entirety: U.S. Provisional Patent Application No. 60/389,659, entitled “System And Method For Integrated Electronic Payment And Information Infrastructure Between Financial Institutions And Other Organizations,” filed on Jun. 18, 2002; and U.S. Provisional Patent Application No. 60/391,905, entitled “Improved System And Method For Integrated Electronic Payment And Information Infrastructure Between Financial Institutions And Other Organizations,” filed on Jun. 27, 2002.  
     
    
     
       BACKGROUND OF THE INVENTION  
         [0002]    Conventional invoicing and payment collection systems involve labor intensive, paper-based, manual processes for businesses and other organizations. Typically, an invoicer (i.e., the supplier) prepares a paper invoice detailing the goods and services provided to a buying organization, including the charges associated therewith. The invoice is mailed to the buying organization, and the buying organization then verifies the accuracy of the invoice by matching it against a purchase order (PO) previously generated by the buyer for the purchase and a receiver document generated at the time of receipt of the goods or services (a process known as the “three-way match”). Once the invoice is verified, the buying organization sends payment, usually in the form of a paper check through the mail, to the invoicer. The invoicer then submits the paper check to its bank for payment.  
           [0003]    Paper payment systems require the buying organization to send the paper check to the invoicer&#39;s bank either directly through the invoicer or indirectly to a lock box before payment is made from the buying organization&#39;s bank to the invoicer&#39;s bank. This exchange is inefficient, requiring multiple steps and unnecessary delay to compensate the invoicer for goods or services rendered.  
           [0004]    Attempts have been made to automate the invoicing process through the use of third-party service providers. Early electronic invoice presentment and payment (EIPP) solutions, however, focused on the needs of the supplier (biller) and did not adequately address the needs of the buyer (payer). For example, many early EIPP solutions did not address the payment-related needs of the buyer (payer), such as to efficiently and effectively control the initiation of payments, defer their settlement, and reconcile and integrate them into the buyer&#39;s financial systems.  
           [0005]    Furthermore, existing EIPP systems have not typically utilized payment cards (such as credit cards, debit cards, corporate cards, and purchasing cards) as a means of business-to-business payments. Moreover, these EIPP systems have not allowed the use of payment terms associated with payment by payment cards or the validation of buyer invoicing rules prior to payment by payment card.  
           [0006]    Furthermore, existing EIPP systems are not capable of automated integration of payment card data into an organization&#39;s internal systems, such as its enterprise resource planning (“ERP”) system or accounts payable (“A/P”) system. Accordingly, organizations are forced to manually re-key invoice data, match it with the card transaction for reconciliation purposes, and then manually enter the data into the organization&#39;s ERP or A/P system. This process is time consuming and prone to human error.  
           [0007]    Some existing EIPP systems may utilize financial electronic data interchange (EDI) or other electronic payment technologies. However, these payment methods may require significant set-up costs, including costly changes to internal systems and processes, and may require changes in banking relationships as well.  
           [0008]    Thus, there exists a need for an improved electronic invoicing presentment and payment system that is cost-effective, simple to integrate into existing processes and systems, and allows efficient payment and reconciliation of financial records.  
         SUMMARY OF THE INVENTION  
         [0009]    Accordingly, it is an object of the present invention to fulfill a need in the field of invoice presentment and payment (“EIPP”) by providing systems and methods for integrated electronic invoice presentment and payment. One exemplary method includes the steps of receiving a purchase order from a buyer, the purchase order including payment card account information and settlement date information, receiving an invoice from a seller related to the purchase order, receiving an indication of approval of the invoice from the buyer, and masking the payment card account information, in whole or in part, from the seller until the settlement date.  
           [0010]    Another exemplary method includes the steps of receiving an invoice from a seller, receiving an indication of approval of the invoice from a buyer, including payment card account information and settlement date information, and masking the payment card account information, in whole or in part, from the seller until the settlement date.  
           [0011]    Another exemplary method includes the steps of receiving a purchase order from a buyer, the purchase order including payment card account information, receiving an order confirmation or invoice from a seller related to the purchase order, validating the order confirmation or invoice against predetermined buyer-defined rules, and masking the payment card account information, in whole or in part, from the seller until the order confirmation or invoice has successfully satisfied the buyer-defined rules.  
           [0012]    Another exemplary method includes the steps of receiving a purchase order from a buyer, the purchase order including payment card account information, the payment card account information being used to provide payment for the transaction through a payment network, receiving an order confirmation or invoice from a seller related to the purchase order, and matching information in the purchase order, order confirmation or invoice, and payment record for the payment card transaction to provide Level III data.  
           [0013]    Another exemplary method comprises providing an electronic invoice presentment and payment system for receiving an electronic purchase order from a buyer and transmitting the purchase order information to a supplier. The purchase order preferably includes information related to the transaction and to the proposed payment for the transaction (e.g., a payment card).  
           [0014]    Another exemplary method includes providing an electronic invoice presentment and payment system (EIPPS) for receiving an electronic purchase order from a buyer and transmitting the purchase order (PO) to a supplier. The purchase order preferably includes information related to said transaction and to the purchasing card. The steps further include: receiving from the supplier an electronic invoice, transmitting data related to the PO to a payment card network for authorization of said transaction, matching by the EIPPS either the purchase order or the invoice with a record provided by the payment card network, and storing by the EIPPS the detailed data related to the transaction and integrating at least a portion of the detailed data into the buyer&#39;s system.  
           [0015]    Another exemplary method includes facilitating generation of an electronic invoice by the supplier using an electronic invoice presentment and payment system (EIPPS), receiving the electronic invoice from a supplier&#39;s system by the EIPPS, transmitting the electronic invoice from the EIPPS to a buyer, transmitting data associated with the transaction to a payment network to facilitate an electronic payment of the electronic invoice from the buyer to the supplier, matching data from the electronic invoice to the electronic payment, and automatically integrating the detailed data related to the transaction into the buyer&#39;s system.  
           [0016]    Another exemplary system according to the present invention includes a first adapter subsystem coupled to a buyer organization financial system, a second adapter subsystem coupled to a supplier organization financial system, an EIPPS coupled to both the first and second adapter subsystem, and a data repository coupled to said EIPPS.  
           [0017]    The accompanying drawings, which are incorporated and constitute part of this disclosure, illustrate preferred embodiments of the invention and serve to explain the principles of the invention. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0018]    Further objects, features, and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying figures showing illustrative embodiments of the invention, in which:  
         [0019]    [0019]FIG. 1 is a block diagram illustrating a system for a standard purchasing card transaction;  
         [0020]    [0020]FIG. 2 is a block diagram showing an exemplary electronic invoice presentment and payment system in accordance with the present invention;  
         [0021]    [0021]FIG. 3 is a flow chart showing an exemplary method for conducting an electronic invoice presentment and payment transaction in accordance with the present invention;  
         [0022]    [0022]FIG. 4 is a flow chart showing an exemplary method for conducting an electronic invoice presentment and payment transaction in accordance with the present invention;  
         [0023]    [0023]FIG. 5 is a flow chart showing an exemplary method for conducting an electronic invoice presentment and payment transaction in accordance with the present invention. 
     
    
       [0024]    Throughout the figures, unless otherwise stated, the same reference numerals and characters are used to denote like features, elements, components, or portions of the illustrated embodiments.  
       DETAILED DESCRIPTION OF THE INVENTION  
       [0025]    Referring to FIG. 1, an exemplary system for conventional purchasing card transactions  10  is shown. A buying organization  12  places an order with a supplier organization  13  using a purchasing card. The supplier organization then sends an authorization request for the purchase to the issuing bank  11  which issued the purchasing card through the supplier&#39;s acquirer bank or processor  14  which is connected to a payment network  24  (such as the MasterCard payment network). If the authorization request is approved, the supplier organization  13  then ships the goods to buyer organization  12 . After the goods are shipped, the supplier organization  13  submits data regarding the purchase to the acquirer bank or processor  14  and the bank or processor clears and settles the transaction through the payment network  24 .  
         [0026]    By way of background, MasterCard&#39;s purchasing card (i.e., “P-Card”) was first introduced in 1993 to provide organizations with an improved means for expense management. Key benefits of the P-Card are that it 1) provides convenience, 2) reduces paperwork, 3) allows management to exert greater control through the card&#39;s authorization system, 4) is accepted by merchants worldwide as a form of payment according to rules established by certain card associations, and 5) provides reporting back to the organization about the card transactions.  
         [0027]    Typically there are three different types of transaction data that may be reported to a purchasing cardholder. “Level I” data includes only the information that appears on a standard credit card statement, such as the transaction amount, transaction date, merchant name, and city/state of the merchant. “Level II” data includes buyer information, tax amount, the supplier organization&#39;s ZIP code, and the supplier organization&#39;s tax identification information. “Level III” purchasing card data is the most detailed transaction data available, and includes detail on each line item in a purchase, such as item description, product codes, quantity, unit-of-measure, price, delivery zip codes, freight charges, and sales tax information. Level III data is valuable for purchasing organizations, as it can be useful for streamlining the accounting processes and easily merging purchase data with their internal electronic procurement files.  
         [0028]    Although Level III data may be very useful to organizations for reconciliation purposes, unfortunately it is not available a majority of the time because the transmission of Level III data requires the supplier and supplier&#39;s acquirer or processor to be set up to handle Level III data. While some supplying organizations and their acquirers or processors have the capability to provide level III data, most do not.  
         [0029]    Even assuming that Level III data is reported to the buying organization, however, there exists no system for automated integration of Level III P-Card data into an organization&#39;s internal systems such as its Enterprise Resource Planning (“ERP”) system or Accounts Payable (“A/P”) system. Accordingly, organizations are forced to manually re-key invoice data, match it with the card transaction for reconciliation purposes, and then manually enter the data into the organization&#39;s ERP or A/P system.  
         [0030]    Referring now to FIG. 2, an exemplary embodiment of a system for conducting a transaction in conjunction with an exemplary embodiment of the EIPP system  20  in accordance with the present invention will now be described. The system includes the buyer system  12  (which includes a buyer&#39;s enterprise resource and procurement (ERP) system and/or a buyer&#39;s accounts payable (A/P) system) and a seller system  13  (which includes a seller&#39;s enterprise resource and procurement (ERP) system and/or a seller&#39;s accounts receivable (A/R) system). Both the buyer&#39;s system and the seller&#39;s system are coupled to an EIPP system  20  according to the present invention. The seller system may be coupled to seller payment card acquirer bank or processor  14  (hereinafter “Seller Acquirer”) through, for example, a point-of-sale (POS) terminal. The Seller Acquirer  14  is coupled to a payment network (such as the MasterCard payment network).  
         [0031]    The EIPP system  20  includes an EIPP application  25  which is coupled to a buyer adapter software module  21 , a seller adapter software module  23 , a payment card data repository  27 , and a supplier directory  29 . The buyer adapter software module  21  translates purchase order information created by the buyer&#39;s ERP and/or A/P systems to a format usable by the EIPP application  25 . The seller adapter software module  23  translates invoice information created by the buyer&#39;s ERP and/or A/R systems to a format usable by the EIPP application  25 . The buyer adapter  21  may be installed at the buyer&#39;s organization and the seller adapter may  23  be installed at the seller&#39;s organization. The payment card data repository  27  receives and stores transaction information related to payment card information. This repository may be, for example, the MasterCard Global Data Repository, which receives and stores commercial and purchasing card transactional data. The supplier directory  29  contains a profile of each seller. The profile may include information indicating the types of payment the seller accepts, seller ID information, etc. Using the supplier directory  29 , the buyer  12  may easily determine which suppliers are registered to use the EIPP system  20 . The EIPP system  20  may be coupled to an acquirer bank or processor  16  (hereinafter “EIPP Acquirer”).  
         [0032]    The EIPP system  20  may include a wide variety of computer elements, such as personal computers, web servers, databases, and software applications for performing the required operations in accordance with the present invention. The data files created, stored and transferred by the EIPP system may be in numerous formats depending on the particular implementation. In one exemplary embodiment of the EIPP system according to the present invention, the system may store files in Extensible Markup Language (“XML”), a format which provides a flexible means for creating and sharing common information between systems. Furthermore, the EIPP system according to the present invention may utilize numerous different file transfer methods for transferring data to the organizations&#39; systems  12 ,  13  and the data repository  27 . These may include HTTPS File Transfer and MasterCard File Express (“MFE”). It should be noted that the present invention is not limited to implementations using the technologies described herein. Those skilled in the art will understand that the systems and methods of the present invention may be implemented using numerous different interchangeable computer, communications and software technologies within the scope of the invention.  
         [0033]    Preferably, the buyer organization and supplier organization are registered with the EIPP system. In addition, the parties may have reached an agreement as to payment terms (such as net 30 days), and those terms reside in the buyer organization&#39;s electronic procurement/ERP system; however, it is not necessary for the parties to have agreed upon such terms for the operation of the presently claimed invention. Additionally, the supplier organization&#39;s profile is established in the EIPP supplier directory, and may include information related to the supplier organization&#39;s ability to accept particular types of payments, such as MasterCard purchasing cards.  
         [0034]    Advantageously, the EIPP system  20  allows buyers to preserve their PO requisition and approval process (i.e., does not require changes to existing systems or processes) and pay for the transaction with a payment card, such as their MasterCard Purchasing Card. For the purposes of the following discussion, it will be assumed that the payment card is a P-Card, but it will be understood that the invention may utilize any payment card.  
         [0035]    FIGS.  3  to  5  illustrate three different scenarios including P-Card settlement according to the presently claimed invention: 1) immediate P-Card settlement with purchase order; 2) delayed/scheduled P-Card settlement with purchase order; and 3) delayed/scheduled P-Card settlement without purchase order.  
         [0036]    Before going into the detailed steps of FIGS.  5  to  7 , it may be helpful to understand generally the difference between “immediate” and “delayed” (or “scheduled”) settlement. The immediate P-Card scenario is when the supplier (or acquirer/processor) is able to process the P-Card transaction once a PO is turned (“flipped”) into an order confirmation and submitted. The supplier does not have to submit an invoice and wait for approval. The immediate P-Card PO has been pre-approved for payment by the buyer, contingent upon the supplier shipping the goods and submitting an order confirmation. In the delayed P-Card scenario, the supplier is not able to process the P-Card transaction until a P-Card approved invoice has reached a buyer-determined settlement date. A delayed P-Card purchase can originate with a P-Card PO or without a PO. In either case, the submitted invoice from the supplier must go through the invoice approval process first. Once the invoice is approved by the buyer and the settlement date has been reached, the P-Card transaction can be processed by the supplier.  
         [0037]    Immediate P-Card Settlement with Purchase Order  
         [0038]    Referring to FIG. 3, in step  51 , the buyer creates a purchase order (PO) using its electronic procurement/ERP and/or A/P system. The purchase order includes P-card account information and may include other payment details, including, for example in this instance, payment terms to indicate that the supplier organization is to receive “immediate” payment. In step  52 , the purchase order information is communicated to the EIPP application via the buyer adapter.  
         [0039]    The EIPP system then sends a purchase order or a notification to the supplier organization in step  53 . In step  54 , the supplier organization views the purchase order and creates an “order confirmation.” Importantly, the purchase card information is masked (either completely or partially) at this point. The order confirmation may be created by “flipping” the PO—i.e., pressing a button that transfers the information on the PO into an order confirmation. Once the PO is flipped, the seller may make edits to the order confirmation. Once the seller has finished with the edits, if any, the seller may submit the order confirmation to the EIPP system. The order confirmation is extracted by the EIPP system and validated against the purchase order and buyer data validation rules in step  55 . Functionally, an order confirmation looks and behaves like an invoice. It goes through the same data validation (buyer defined) as an invoice. The presentation is the same as an invoice, but with a different title, and it does not require approval from the buyer. When the buyer validation rules are satisfied, the P-card information on the PO and order confirmation become unmasked and available to the seller, and the order confirmation becomes available to the buyer.  
         [0040]    In step  56 , payment is processed either by the seller or by the EIPP system. If payment is processed by the seller, the seller uses the P-card account information to conduct a P-card transaction through its Seller Acquirer. If payment is processed by the EIPP system, the EIPP system conducts a P-card transaction through the EIPP Acquirer. In each case, an authorization request is sent through the payment card network and an authorization response is received. Assuming the transaction is authorized, the supplier organization ships the goods to the buyer organization in step  57 . The MasterCard transaction is then cleared and settled in the traditional manner in step  58 .  
         [0041]    The financial data record which is generated during the purchasing card payment and settlement process is then preferably sent to a data repository, such as MasterCard&#39;s Global Data Repository, in step  59 . The EIPP system then provides order confirmation information to the buyer organization in step  60  for reconciling against open PO in buyer organization&#39;s electronic procurement/ERP systems.  
         [0042]    In step  61 , the EIPP application then sends the relevant data from the purchase order and order confirmation to the data repository, where this transaction data is matched with the corresponding purchasing card financial data record. Alternatively, the purchasing card financial data record may be transferred from the data repository to the EIPP application, and the EIPP application may perform this matching function. The matching function is preferably based on at least two unique match keys: a unique number generated by the EIPP system and the authorization response code for the P-card transaction. The matched data provides Level III details, regardless of supplier or acquirer limitations. In a final step  62 , the matched records are sent to the buyer organization for reconciliation with the issuing bank&#39;s statement and integration into the buyer organization&#39;s AP/ERP systems. Preferably, the matched (enhanced) data resides in the MasterCard Global Central Data Repository and is available for delivery back to the buyer via secure, Web-based reporting tools, such as MasterCard Smart Data OnLine.  
         [0043]    Delayed/Scheduled P-Card Settlement with Purchase Order  
         [0044]    Referring to FIG. 4, a method  70  in accordance with an exemplary embodiment of the present invention will now be described. In this scenario, as in that described with respect to FIG. 3, the buyer organization and supplier organization are registered with the EIPP system, and the parties may (or may not) have reached an agreement as to payment terms. Again, the supplier organization&#39;s profile is established in the EIPP supplier directory. In step  71 , the buyer creates a purchase order that includes various purchasing card payment details. In this instance, the purchase order contains payment terms to indicate that the supplier organization is to receive “delayed” payment. The PO may also include-purchase terms such as, for example, “net 30 days.” In step  72 , the purchase order is extracted by the EIPP system via the buyer adapter. The EIPP system then sends the purchase order or a notification to the supplier organization in step  73 . Importantly, as before, the purchase card information is masked (either completely or partially) at this point. In step  74 , the supplier organization fulfills the purchase order and ships the goods. The supplier organization then creates and submits an invoice into the EIPP system in step  75 . The invoice may be created through the EIPP application or may be created through the seller&#39;s ERP or A/R systems and communicated to the EIPP application. The invoice is checked against buyer validation rules. Subsequently in step  76  the EIPP system transmits the invoice or a notification to the buyer organization. In step  77 , the buyer organization approves the invoice, and the EIPP then holds the invoice until the settlement date, which is determined by the buyer. “Holding” in this case means that the payment card information is not revealed or unmasked until the settlement date and/or that the EIPP system does not process the payment card transaction until the settlement date.  
         [0045]    On the settlement date, the EIPP system reveals or unmasks the P-card account information. Either the seller or the EIPP may then use the information to process the payment. If the seller processes the payment, the seller sends an authorization request to its acquirer (for example, through a POS). The seller&#39;s acquirer sends it through the payment network and subsequently the seller receives an authorization response. If payment is processed by the EIPP system, the EIPP system conducts a P-card transaction through the EIPP Acquirer.  
         [0046]    Assuming the transaction is authorized, the transaction is then cleared and settled in the traditional manner in step  79 . The financial data record is then sent to a data repository, through methods known in the art, such as MasterCard&#39;s Global Data Repository, in step  80 . In step  81 , the EIPP system provides the invoice to the buyer organization for reconciliation against an open purchase order in the buyer organization&#39;s electronic procurement/ERP system. In step  82 , the EIPP then sends data elements from the purchase order and invoice to the data repository, where this transaction data is matched with the corresponding purchasing card financial data record as previously described. Alternatively, the purchasing card financial data record may be transferred from the data repository to the EIPP system, and the EIPP system may perform this matching function. In a final step  83 , the matched records are sent to the buyer organization for reconciliation with the issuing bank&#39;s statement and integration into the buyer organization&#39;s AP/ERP systems. The matched data provides Level III details, regardless of supplier or acquirer limitations. Preferably, the matched (enhanced) data resides in the MasterCard Global Central Data Repository and is available for delivery back to the buyer via secure, Web-based reporting tools, such as MasterCard Smart Data OnLine.  
         [0047]    Delayed/Scheduled P-Card Settlement without Purchase Order.  
         [0048]    Sometimes a transaction may occur without a purchase order. This may happen if the order is initiated through a telephone call, for example. Referring to FIG. 5, a flow chart describing another method  90  in accordance with an exemplary embodiment of the presently claimed invention is shown. FIG. 5 describes a transaction in which no purchase order is generated by the buyer, but rather where the transaction is initiated when the supplier organization submits an invoice to the buyer organization. In this scenario, as before, the buyer organization and supplier organization may or may not have reached an agreement as to payment terms. In step  91 , the supplier organization initiates the transaction by creating and submitting an invoice into the EIPP system. The invoice may be created through the EIPP application or may be created through the seller&#39;s ERP or A/R systems and communicated to the EIPP application. The invoice is checked against buyer validation rules. In step  92 , the EIPP system transmits the invoice to the buyer organization for approval. In step  93 , the buyer organization approves the invoice, schedules a settlement date, and authorizes payment using a payment card such as the MasterCard P-Card. Once the invoice is approved, it may become visible to the seller; however, the P-card account information will be masked or hidden until the settlement date. In step  94 , on the settlement date, the EIPP system or the seller sends an authorization request through its acquirer to the payment network and receives an authorization response. The MasterCard transaction is then cleared and settled in the traditional manner in step  95 .  
         [0049]    The appropriate financial data is then sent to a data repository in step  96 . In step  97 , the EIPP system provides the invoice to the buyer organization for reconciliation in the buyer organization&#39;s electronic procurement/ERP system. In step  98 , the EIPP then sends the relevant data elements from the purchase order and invoice to the data repository, and this transaction data is then matched with the corresponding purchasing card financial data record as described before. In a final step  99 , the matched records are sent to the buyer organization for reconciliation with the issuing bank&#39;s statement and integration into the buyer organization&#39;s AP/ERP systems. The matched data provides Level III details, regardless of supplier or acquirer limitations. Preferably, the matched (enhanced) data resides in the MasterCard Global Central Data Repository and is available for delivery back to the buyer via secure, Web-based reporting tools, such as MasterCard Smart Data OnLine.  
         [0050]    Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.