WO2000048053A2

WO2000048053A2 - Commercial transaction management system and method

Info

Publication number: WO2000048053A2
Application number: PCT/US2000/002508
Authority: WO
Inventors: John J. Barry; Rohan Champion; Denis Hogan; George Garner; Ralph Parrott
Original assignee: Etime Capital, Inc.
Priority date: 1999-02-12
Filing date: 2000-02-11
Publication date: 2000-08-17
Also published as: AU3586000A; WO2000048053B1; WO2000048053A3

Abstract

A method and system for providing to commercial market participants a dedicated data processor (22) for consolidating and expediting a financial settlement system. Upon the placement of an order, documents such as the purchase order, confirmation order, invoice and bill of lading are transmitted to the data processor (22) and stored in a suitable database. A proof of delivery is also forwarded to the data processor (22) upon delivery to the buyer (12). The data processor (22) audits and reconciles the transaction information thus facilitating the resolution of possible exceptions which may prevent timely payment.

Description

COMMERCIAL TRANSACTION MANAGEMENT SYSTEM AND METHOD

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of provisional patent application Serial No. 60/119,853 filed February 12, 1999, the disclosure of which is incorporated herein by reference. FIELD OF THE INVENTION

The present invention generally relates to the field of commercial transactions, and more particularly, to an improved commercial transaction management system for streamlining operation, reducing costs, and achieving higher control of the entire commercial transaction settlement process via a dedicated electronic data processor over a computer network.

BACKGROUND OF THE INVENTION Business to business commercial transactions for goods and services account for a significant portion of commerce in the United States and worldwide. Traditionally, such commercial transactions involve multiple parties including a buyer of goods or services, a seller of good or services, and, as necessary, a carrier of goods. In the course of such a commercial transaction, it is necessary to transfer a variety of physical documents between the various parties, many of which include redundant information. As a result of the generation and transfer of these physical documents, a multitude of possible inaccuracies can occur. In fact, by some estimates, 20% of all commercial transactions are affected by errors in the documents used to carry out the transaction. This results in the rejection of the initial invoice demand for financial settlement.

In general, a Buyer issues a purchase order (PO) for a particular quantity of product to a Seller. The Seller, upon receipt of the PO may issue a confirmation order (CO) to the Buyer, indicating its acceptance of the PO and detailing such information as product availability, delivery, pricing, etc. The Seller then fulfills the order. The Seller then creates a bill of lading (BL) that includes a brief description of the goods being shipped and the pertinent freight classification. The Seller creates and delivers independently to the Buyer an invoice (INV) that is the demand for financial settlement from the Buyer. The Seller then tenders the shipment, including a copy of the BL, to the Carrier for delivery to the Buyer or Buyer's designated receiver. The Carrier delivers the goods to the Buyer, and receives a signed acceptance from the

Buyer, which forms a proof of delivery (POD) document that is returned by the

Carrier to the Seller to confirm delivery of the goods.

In addition to the documents discussed above, various additional documents may be generated during the course of the commercial transaction. For example, the Seller will often generate a Pick & Pack Manifest that details the line item contents of the shipment. An advance shipping notification (ASN) can be generated by the Seller to notify the Buyer that the goods will be shipped on or around a certain time to allow the Buyer to plan for receipt and processing of the goods. Additional documents may be generated in connection with the transaction for internal use by the Buyer, Seller or Carrier. For example, a sales order containing information similar to that in the PO can be internally generated by the Seller for internal documentation. The Buyer may also generate a receiving ticket (RT) in connection with receipt of the goods, which is used by the Buyer in reconciling the transaction.

Upon submission of an Invoice to the Buyer, the Seller opens an account receivable for the goods transferred to the buyer. Furthermore, prior to payment and independent of the Seller, the Buyer begins an internal auditing, or reconciliation, process with respect to the received goods. During this process, the Buyer confirms that the transaction was conducted as expected in that the goods actually received (as evidenced in the POD or receiving ticket) conform to the goods requested in the PO. If the transaction is reconciled (i.e. the Buyer confirms that the goods expected were received), the Buyer confirms that payment should be made and closes the open account payable file that was created by the Buyer upon generation and submission of the original PO , which ultimately leads to payment to the Seller for the goods.

If the Buyer fails to reconcile the transaction, however, an account payable will remain open and the Seller will not be paid until such time as the Buyer is satisfied with the transaction. That is, for example, if the description of the goods in the original PO does not match with the description on the invoice; or if the Buyer requested a quantity of 100 in the PO, but only received 90 as evidenced in the POD, the Buyer will withhold payment until this discrepancy is resolved. Often, resolution of such a discrepancy is delayed until the Seller, recognizing that payment has not been made for the goods, contacts the Seller to request payment. Under traditional payment terms, this delay can be 30 days or more. Thus, despite the fact that the

Buyer may recognize a discrepancy that will delay payment relatively early in the process, it may not be addressed until lack of payment is raised by the Seller 30 days or more later.

As the complexity and size of today's global marketplace continues to grow, it is becoming increasingly more important for businesses to develop new and innovative means by which to increase the efficiency and cost effectiveness of conducting business. The above-described process is very complex and includes significant room for error, often through clerical errors in preparing the various documents or physical loss of the documents themselves. Further, the process is very lengthy typically taking from 30 to 90 days to complete.

One known method for improving the efficiency of the commercial transaction process is to generate and transfer the various documents in electronic form, thereby reducing the time taken to transmit such documents. For example, U.S. Patent No.

5,758,327 to Gardner et al. discloses an electronic requisition and authorization process wherein a central computer system connects a variety of supply chain parties including a vendor, various requisitioning companies, and a financial entity. The requisitioning companies can forward an electronic requisition form to the central computer, which is thereafter authorized in accordance with the requisition rules of the company. The central computer then forwards the requisition to an appropriate vendor, where the order is filled. A distribution provider delivers the items to the company and transmits an electronic proof of delivery to the central computer system. The vendor may transmit an invoice to the operators of the central computer system. The invoice from the vendor is matched with the electronic proof of delivery and if the information matches, an invoice is generated by the central computer system and electronically transmitted to the company.

Gardner, however, fails to disclose a system and method for reconciling a commercial transaction to verify the integrity of the transaction. As understood by those of skill in the art, the proof of delivery merely evidences that delivery of a certain shipment has been made with or without exception, and does not provide information necessary in validate and verify the information contained in the invoice received from the vendor. Thus, the system and method of Gardner merely substitutes electronic communications for the physical paper based communications previously used in the commercial transaction process.

Another example of a computerized commerce system is disclosed in U.S. Patent No. 4,799,156 to Shavit et al. Shavit et al. discloses a system for interactive on-line electronic communications and processing of business transaction between at least a plurality of sellers, buyers, financial institutions and freight service providers. Like Gardner, however, Shavit et al. fails to disclose a system and method for reconciling a commercial transaction to verify the integrity of the transaction and merely substitutes electronic communications for the physical paper based communications previously used in the commercial transaction process. Although conversion of business documents from traditional paper copies to electronically transmittable documents reduces the cost and time taken to conduct business transactions, there remains a need for an improved business system that enables market participants to more quickly, accurately, and efficiently identify discrepancies in the various commerce transactions documents that prevent or delay financial settlement and better manage cash and credit settlement between various documents, transactions, and parties. There further remains a need for providing value added services to the commercial transaction market.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide a system and method for overcoming the deficiencies noted above. It is a further object of the present invention to provide an improved commercial transaction management system for streamlining operation, reducing costs, and achieving higher control of the entire commercial transaction settlement process via a dedicated electronic data processor over a computer network. It is another object to provide an electronic data processing system and method that captures commercial transaction information from one or more parties to the commercial transaction.

It is a further object of the present invention to provide such an electronic data processing system and method that receives commercial transaction information, preferably in electronic form, from at least one of a Buyer, Seller and Carrier involved in a commercial transaction.

It is yet another object to provide such a system and method wherein commercial transaction information is forwarded in electronic form from a Buyer, Seller or Carrier using a software agent resident on an ERP system of the Buyer, Seller or Carrier.

It is an object of the present invention to provide a system and method to accelerate payment to a Seller for goods or services provided to a Buyer.

It is a still further object of the present invention to provide such a system and method that reconciles the commercial transaction information to facilitate settlement of the commercial transaction, to validate the integrity of a receivable resulting from the commercial transaction, to facilitate payment to the parties of the commercial transaction, and/or to facilitate factoring or securitization of a receivable resulting from the transaction.

It is another object to provide such an electronic data processing system and method wherein electronic data communication (such as an EDI connection, an

Internet based connection, a LAN, WAN, VPN or other network connection, or a dedicate data connection) is provided between at least one of a Buyer, Seller and Carrier involved in a commercial transaction to facilitate transfer of the commercial transaction information to the data processing system. It is yet another object of the present invention to provide a electronic data processing system and method to provide real-time or near real-time information on the status of a commercial transaction.

It is an object of the present invention to provide a system and method for accelerating the resolution of disputes in a commercial transaction.

It is a further object of the present invention to provide a system and method for decreasing the time necessary to settle a commercial transaction at least by facilitating reconciliation ofdata generated in connection with the commercial transaction and by facilitating resolution resolving disputes arising during the transaction.

It is yet a further object of the present invention to provide a system and method for detecting inconsistencies in commercial transaction documents at the earliest possible time to facilitate reconciliation of, and dispute resolution in, the commercial transaction. It is yet another object of the present invention to consolidate information relating to a commercial transaction from several parties to the transaction in a central electronic data processing system.

It is an object of the present invention to reduce or eliminate errors and inconsistencies between commercial transaction records of parties to a commercial transaction to facilitate settlement of the commercial transaction.

It is yet another object of the present invention to identify suspect receivables early in the commercial transaction process to facilitate resolution of any disputes concerning the receivable, thereby reducing the risk that payment for the receivable will be delayed. It is an object of the present invention to increase the value associated with a receivable by reducing the risk that the receivable will be subject to dispute.

It is a still further object of the present invention to increase the marketability of a receivable to a financial institution for use in securitization or factoring of the receivable. It is an object of the present invention to increase the confidence that a receivable will be timely paid in accordance with the terms and conditions of a commercial transaction, thereby increasing the value of the receivable for use in securitization or factoring. It is another object of the present invention to provide a system and method permitting a Seller of a good or service to validate a receivable by continuously reconciling commercial transaction information throughout the commercial transaction process and upon receipt of a POD from a Carrier.

It is an object of the present invention to provide a system and method that permits a Seller in a commercial transaction to obtain more favorable terms from a financial institution securitizing a receivable due the Seller.

It is a further object of the present invention to provide a system and method that reduces the origination and transaction costs associated with factoring or securitizing a commercial transaction receivable. It is an object of the present invention to provide a system and method for analyzing a receivable resulting from a commercial transaction to provide a quantitative indication of the quality of the receivable.

It is still further object of the present invention to assign a standardized

"score" to one or more receivables resulting from a commercial transaction. It is another object of the present invention to provide an electronic data processing system and method that facilitates reduction in the days sales outstanding

(DSO) of a Seller.

These and other objects are achieved in the present invention through the provision of an electronic data processing system that is connected with and receives information from a plurality of data processing systems disposed at one or more of a

Buyer's, Seller's and Carrier's locations. A software agent is provided to interface to the Buyer's, Seller's or Carrier's data processing systems and operates to extract commercial transaction data in real-time or near real-time from the data processing systems. This data is forwarded, preferably in electronic form, to the electronic data processing system of the present invention, where it is further processed, analyzed, reconciled, and scored to achieve the above objects.

The present invention overcomes the problems noted above, and provides additional advantages, by providing a method and system for providing to commercial market participants a dedicated data processor for consolidating and expediting a financial settlement system. A method in accordance with an exemplary embodiment of the invention is performed by connecting, over a common computer network, a plurality of, Buyers, Sellers, Carriers and Financial Institutions, each connected to the dedicated data processor. Upon the placement of a commercial transaction order, all of the various transaction documents such as the PO, CO, INV, BL and POD are transmitted to the data processor of the present invention in electronic format and stored in a suitable database. It should be understood that any of these documents may initially be non-electronic in format and will be converted into suitable digital forms for processing by the data processor. This conversion is done either by the receiving party, or by a call center associated with the processor. Following delivery of the goods to the Buyer, the Carrier generates a POD and transmits this to the Seller, which is thereafter forwarded to the data processor of the present invention. At this point, all transaction documents are consolidated within the data processor database of the present invention. Following auditing and reconciliation by the data processor of all transaction documents, the processor may transmit authorization to the respective financial institution to credit the accounts of the Carrier and Seller. The Buyer may be either immediately debited, debited after a predetermined period of float, or normally invoiced so that the above system appears invisible to the Buyer, depending upon the terms of trade. This method of consolidating and expediting the financial settlement system greatly reduces the administrative costs associated with the accounts payable/accounts receivable process for all parties. Further, the present invention can be used to reduce or eliminate float for the Seller and the Carrier, thus enabling those parties to maximize use of their funds.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention and its resulting advantages can be more fully understood by reading the following Detailed Description in conjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram of a commercial transaction system the present invention;

FIG. 2 is one embodiment of a dedicated data processor of the present invention;

FIG. 3 is an operation block diagram illustrating the operation of the system of the present invention; FIG. 4 is a block diagram illustrating one embodiment of a business process layer of the present invention;

FIG. 5 is a block diagram illustrating one embodiment of a data presentation layer 42 of the present invention;

FIG. 6 is a block diagram illustrating a method for financing an account receivable in accordance with the present invention; and

FIG. 7 is a flow chart illustrating a method of quantitatively scoring the value of a receivable of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Referring now to the Figures and particularly to Figure 1 , there is illustrated a block diagram of a commercial transaction system generally designated by the numeral 10 including a plurality of market participants. Principal market participants include a Buyerl2, a Seller 14, a Carrier 16, and a Financial Institution 18. Each of the Seller 14, Carrier 16, and Financial Institution 18 are connected via data communications lines 20 to a dedicated data processor 22 of the present invention over a computer network such as the Internet. In addition to connectivity of several market participants over the computer network, the Buyer and Seller are preferably connected to each other either by electronic means 24, or by any suitable nonelectronic means such as in-person, telephone, facsimile, postal service, etc. The Seller 14 and Carrier 16 each typically include enterprise resource planning (ERP) programs (or similar functional application systems) 26 and 28 which permit the storage and manipulation of internal business information. Examples of typical ERPs include those sold under the trademarks SAP, JD Edwards, and BaaN. ERPs are often constructed to include a variety of different software systems, which may or may not be synchronized or linked together on the Seller or Carrier's system or site. Each ERP 26 and 28 further includes databases 29 and 30, respectively, for storing information relating to commercial transactions. Associated with the data processor 22, data acquisition agents 32 and 34 are provided at the Seller 14 and Carrier 16, respectively for retrieving and transmitting transaction information relating to specific commercial transactions from the databases 29 and 30 to the data processor 22. Preferably, data acquisition agents 32 and 34 operate to convert transaction data in databases 29 and 30 from any one of a predetermined number of commercial database formats into extensible markup language (XML) for secure transmission to the processor 22 over the network.

In order to maintain the confidentiality of the transaction data while being transmitted over the network, several layers of protection are preferably utilized. First, each party to the commercial transaction is provided with at least one digital signature. Digital signatures are well known in the art of data protection as a means for authenticating the identity of the various participants when information is shared between two parties. Upon conversion into XML format, the transaction data is signed with the digital signature of the transferee to ensure that the data does in fact originate with the transferee. Further, the data and combined digital signature are encrypted using conventional private key encryption so as to prevent dissemination of the transaction data to unauthorized parties. By both digitally signing and encrypting the transaction data prior to transmission, the data is both authenticated as to its source and protected from unauthorized access.

Referring now to Figure 2, there can be seen one embodiment of the dedicated data processor 22 of the present invention. Data processor 22 preferably includes a plurality of processing layers for performing specific tasks in accordance with the present invention. A data acquisition layer 36 provides for the acquisition of the converted XML transaction data from agents 32 and 34. Data acquired by the data acquisition layer 36 is decrypted, authenticated and archived in at least one database 38 for subsequent use by the processor 22. Further, the data acquisition layer 36 also parses out the information contained in the transaction data so as to populate a variety of fields in the database 38 relating to a particular transaction document. In this manner, the database 38 stores both a raw unparsed copy of the received transaction data as well as a parsed copy which is acted upon by processor 22. In addition to receiving transaction data, the data acquisition layer 36 also operates to securely transmit several items of summary analytical level transaction data to the Seller 14, upon receipt from the Carrier 16.

A business process layer 40 provides for the processing of the acquired data by a variety of software implemented business rules and workflow processes. In addition, a data presentation layer 42 provides for the presentation of information related to the processed data to various individual members of the market participants over the computer network. Further, a message bus 43 provides messaging capabilities between the data processor 22 and the various market participants connected to the processor 22. Specific features of the business process and data presentation layers 40 and 42 will be discussed in more detail below with respect to the operation of the system of the present invention.

Referring now to Figure 3, there is shown a block diagram illustrating the operation of the system of the present invention. In operation, Seller 14 receives a purchase order (PO) 44 for goods from a Buyer 12 either electronically or through conventional means such as over the telephone or via facsimile. Once a PO 44 is received, a sales order (SO) 46 is generated by the Seller 14 and input into the Seller's

ERP and database 29. Agent 32 subsequently converts the SO 46 into XML, signs the data with the Seller's digital signature, encrypts the data with the Seller's private key and securely transmits the data to the data processor 22. Once received by the processor 22, the data acquisition layer 36 decrypts and authenticates the SO 46, archives both a raw version as well as a parsed version of the SO 46 into the database 38. Following generation of the SO 46, the Seller generates a confirmation order (CO) 48 for delivery to the Buyer 12. As is known in the art, the CO 48 mirrors the received PO 44 and informs the Buyer 12 of the availability and terms of sale of the requested items. CO 48 is electronically stored in database 29 in the manner described above. Agent 32 then subsequently retrieves the CO 48 from the database

29 and transmits it to the database 38 of the processor 22.

Following fulfillment of the PO (as evidenced by CO 48 in database 38), the Seller 14 then tenders the goods to the Carrier 16 and generates a bill of lading (BL) 50 for attachment thereto. BL 50 is entered into database 38 in the manner described above. Carrier 16 delivers the goods to the Buyer 12 and generates a proof-of- delivery (POD) 52 indicated either acceptance of the goods or acceptance of the goods with exceptions. The POD 52 is then transferred to database 38 in accordance with the present invention. Upon generation of an Invoice, the Seller opens an account receivable, anticipating payment by the Buyer 12. It should be understood that numerous additional documents such as an advance shipping notification (ASN), an invoice (INV), and a receiving ticket (RT) may be generated by the Buyer 12, Seller 14 or Carrier 16 in accordance with general business practices. These additional documents may be stored in the database 38 for use in ensuring error free processing of the transactions. In addition, upon final payment or non-payment by the Buyer, the account receivable is closed, thereby indicating that the commercial transaction between the parties has been concluded.

Typically in commercial transactions of goods, the Buyer 12 is given a specific term in which it must pay the Seller the amount due for the delivered goods. Common examples of terms of payment include net 30 days and 2/10 net 30 days. From the Buyer's standpoint, the time between delivery of the goods and payment to the Seller is called float and has a given positive value to the Buyer. In other words, the longer the Buyer can go between delivery and payment, the longer it maintains possession of the payment amount, thus increasing its value. Conversely, the time between delivery and payment from a Seller's standpoint is called day sales outstanding (DSO) and has a negative value to the Seller. DSO refers to the time it takes for a receivable to be paid by the Buyer. Since most large Sellers typically borrow against their receivables in some manner, a large average DSO forces the

Seller to pay more interest on the loan secured by the receivable. Reducing the DSO by facilitating settlement of the transaction thus results in considerable savings to the Seller.

In accordance with the present invention, inconsistencies between any two or more documents stored in database 38 of processor 22 are identified in substantially real-time as the documents are sequentially saved in the database. For example, upon entry of both a CO 48 and a BL 50, the common terms contained in both documents are reconciled to determined whether errors have been made in the preparation of the either document. This reconciliation process is carried out at every stage of the transaction, thus verifying the accuracy of all data across the various document types. In addition, during the document collection process, certain documents take precedence over other documents. This eliminates confusion on the part of the system regarding a reconciliation of two contrary documents, without relying upon a confirming third document. For example, a CO is precedent to a BL. Therefore, if during reconciliation, the terms of the stored CO and BL differ, the CO (dependent on the terms of sale and general business practices) is given precedence and an exception to the BL is generated to the Seller. This allows the Seller to rectify the error in the BL prior to tendering the order to the Carrier, thus increasing the likelihood that final settlement of the account receivable will be successful. General business practices are used to determine which documents in the supply chain process take precedence over which other documents as readily understood . The reconciliation process of the present invention virtually eliminates the possibility of error, thus reducing the DSO and greatly increasing the value of the account receivable.

In practice, the DSO is generally driven by two factors: 1) exceptions in the transaction process which take time to resolve; and 2) slow paying Buyers intent on maximizing float for their own benefit. By drastically reducing the time taken to resolve exceptions in the transaction process, the first of these factors in virtually eliminated, thus reducing average DSO for the Seller. Further, by allowing a Seller to specifically identify which of its customers pay on time, which of its customers have legitimate exceptions, and which of its customers are simply slow payers, the Seller is better able to modify its business strategies to maximize the value of the receivable and reduce the DSO. Referring now to Figure 4, there is shown a block diagram illustrating one embodiment of a business process layer 40 of the present invention. Upon the collection of at least two documents into the database 38, business process layer 40 of processor 22 initiates a reconciliation engine 54 to reconcile the information contained in the various documents in order to determine if errors or exceptions have occurred and need to be resolved. The reconciliation engine 54 includes two sublevels of processing capability, a rules engine 56 and a workflow processing engine 58. The rules engine 56 includes a variety of rules 60 associated therewith which govern the method in which transaction document information is reconciled. For example, a given rule might ask whether the ship-to address on the CO and the ship-to address on the BL are identical. If the addresses match, the rules engine 56 indicates that these values are reconciled and an exception is not entered. However, if the two addresses do not match, the rules engine generates an exception and invokes the workflow processing engine 58. It should be noted, that all rules 60 do not necessarily match the information contained in the various documents. Rather, the rules 60 are formulated on the basis of established business principles to determined whether an exception should be generated. An example of a particular rules engine capable of use with the present invention is the Blaze Advisor Rule Engine sold by Blaze Software, Inc. of Mountain View, California.

In accordance with one embodiment of the present invention, the rules engine 56 is customizable by a specific system customer. In a Seller oriented model, rules 62 specific to a particular Seller may be implemented throughout the rules engine in order to more accurately assess the likelihood that a particular receivable (or class of receivables) will be paid within the terms of payment. Similarly, the system customer (e.g., the Seller) may indicate that specific rules should apply to specific customers of the customer (e.g., Buyers). This enables the customer to implement rules relating to specific customers which have been developed based upon a previous business history with the customer. The remainder of the rules 60 implemented in the rules engine 56 are default rules provided by the system operator. In general, it is preferred that at least 80% of the rules 60 in the rules engine 56 be default rules provided by the system operator and that 20% or less of the rules 62 be submitted or customized by the customer. This reduces the necessary work on the part of the customer and enhances "off-the-shelf operation of the system.

In the event that an exception is generated by the rules engine 56, the workflow processing engine 58 is invoked as a means for resolving the exception. The workflow processing engine 58 includes a variety of workflow processes 64 operable to respond to the various exceptions generated by the rules engine 56. Preferably, each possible exception has an associated workflow processes, although it is contemplated that several exceptions may activate a single workflow process. Essentially, each workflow process reacts to an exception by providing and implementing a plan of action designed to resolve the exception. For example, upon receiving an indication that the ship-to-address on the BL does not correspond to the ship-to address on the CO, an associated workflow process 66 is invoked. A first step 68 of the workflow process 64 may be to send a message 70 through the message bus 43 to an accounts receivable (A/R) personnel member 72 indicating the disparity and asking for a response on how to resolve the issue. The workflow process 66 may then invoke a time-out procedure 74 providing that, if a suitable response is not received from the A R personnel in a predetermined time period, a message is sent to a higher level individual 76. The workflow process 66 would continue to act to provide a resolution to the exception until a termination point 78 had been reached. Absent a suitable response to all resolution queries at the termination point 78, workflow process 66 would not reconcile the documents and a flag would be maintained for the particular transaction, indicating that at least one document had not been reconciled. However, upon receiving a response 80 capable of resolving the exception, the workflow process 66 modifies the information in the database 38 in accordance with the resolution and removes the exception. At this point, the workflow process 66 is ended and the business process layer 40 of processor 22 returns to the rules engine 56 for invocation of the next rule 60. Each of the actions taken by the workflow processing engine 58 is tracked by the processor 22 so as to provide a fully auditable trail of the actions taken in response to a determined exception. Once the rules engine 56 has determined that no exceptions exist, the value of the receivable is limited only by the likelihood that the Buyer will be a slow payer.

Referring now to Figure 5, there is shown a block diagram illustrating one embodiment of a data presentation layer 42 of the present invention. Data presentation layer 42 includes at least one software application 82 which permit users of the system 10 to create and view reports relating to the information stored in the database 38. Preferably, the software application 82 is an Internet portal application which permits users to access data reports 84 relating to their specific transactions over the Internet. An example of a suitable Internet portal application is the Brio ONE infrastructure sold by Brio Technology of Palo Alto, California. Examples of suitable reports 84 generated and viewed through the application 82 include sortable lists of orders and transactions, a detailed description of the current stage in the settlement and reconciliation process of a particular transaction including the total number of exceptions, as well as the type and severity of each exception.

In a broader perspective, authorized parties will be able to access a vast number of analytical analyses of the data based upon business history of a Seller, overall or with respect to a particular Buyer, developed through the systematic input of transaction information into the database 38. One example of such an analysis is a breakdown of average DSO by Buyer. Information such as this allows the Seller to more easily determine the course of business in both broad terms and with respect to particular Buyers.

It should be noted that, since transaction information is continually input into database 38, the scope of the reports generated by the application 82 may be automatically updated at predetermined intervals. This prevents the information contained in the reports from becoming stale, thereby reducing the overall value of the report information. In one preferred embodiment of the data presentation layer 42, the internet application 82 is provided with a hierarchical certificate authentication system 83. Such authentication systems permit access to varying degrees of information between different individuals. In other words, rather than disseminate all available information on a customer-by-customer basis, a hierarchical certificate scheme 83 permits the system to differentiate between user authorization levels down to various individuals that work for the same customer. For example, a A/R customer service representative should be able to access certain specific reports relating to transactions under their control, but should not be able to access the cross-buyer analytical information or company history profile. However, the Chief Financial Officer of the Buyer should certainly have access to the full variety of reports. The hierarchical certificate scheme permits varying levels of access within the same organizational structure.

Referring now to Figure 6, there is shown a block diagram illustrating a method for financing an account receivable in accordance with the present invention. As disclosed above, a Financial Institution 18 is preferable connected to the data processor 22. As is well known in the art, a large number of Sellers 14 in commercial transactions desire to accelerate the effective payment of their receivables by selling the receivable to the Financial Institution 18. For a percentage of the receivable, the Financial Institution 18 buys the receivable from the Seller, either on a transaction by transaction basis (i.e., a factoring arrangement) or on a quasi-permanent basis (i.e., a securitization agreement). The percentage involved reflects the desired amount of profit on the part of the Financial Institution as well as the degree of risk associated with the receivable, and the cost of originating the program which requires analysis the relevant data and determining the risk factor. Because the commercial transaction system 10 of the present invention increases the likelihood that a receivable will be paid within the terms of payment, the Financial Institution 18 may choose to utilize this capability to determine the risk associated with a given factoring or securitization program. Because the likelihood of in term payment is increased and because the system 10 has absorbed the costs of acquiring and analyzing the relevant data, the Financial Institution 18 is able to increase the profitability of the financing operation as well as decrease the percentage rate withheld from the Seller upon transfer of the receivable. This aspect of the present invention is referred to as the Financial oriented model.

Similar to the Seller oriented model discussed in detail above, the system 10 includes data acquisition agents 84 and 86 provided at the Seller's and Carrier's ERPs, respectively. Each agent 84 and 86 securely transmits transaction information between the parties and a data processor 88. A data acquisition layer 90 at the processor 88 receives the data and populates a database 92 accordingly. A business process layer 94 at the processor 88 invokes a rules engine 96 and a workflow processing engine 98 to systematically reconcile transaction information as it is received into the database 92. Unlike the Seller oriented model described above, the Financial oriented model does not permit Seller customization of rules engine 96. Rather, the reconciliation rules are strictly governed by the Financial Institution 18 in an effort to standardize the reconciliation process between different Sellers. Further, because the system 10 is operated by a trusted third party, the risk that the Seller is financing fraudulent receivables is eliminated, thereby reducing the likelihood that the receivable will not be paid.

In addition to standardizing the reconciliation process, the processor 88 also includes a scoring engine 100 which provides for quantitative risk assessment of each receivable or defined group of receivables. Referring now to Figure 7, there is shown a flow chart illustrating a method of quantitatively scoring the value of a receivable of the present invention. The scoring process is initiated in step 700 by the completion of the goods reconciliation or in step 702 by the lack of reconciliation by the rules and workflow processes engines 96 and 98. In other words, scoring of the receivable is completed following reconciliation of the POD or a corresponding time-out of a critical exception. Although multiple shipments may result from a single PO, each shipment is scored separately. This is because each path represents the lowest level of granularity in a given transaction. The following tests are conducted on the transaction data for use in the scoring process. 1) Field Population Test; 2) Critical Data Test; 3) Data Element Validation Test; 4) Data Transportation Test; 5) Document Count Test; 6) Terms and Conditions Test; 7) Goods and Services

Validation Test; 8) Invoice Validation Test; 9) Freight Invoice Validation Test; 10) Number of Open Critical Exceptions Test; and 11) Number of Open Problematic Exceptions Test. Field Population Test 704: All transaction documents are pulled in and a null field test is run. This test determined whether the data elements required for reconciliation of each document are present in the database. If any data is missing then the document score will be increased by "1" for each item ofdata missing. Each document will have the score appended to the document. The overall shipment score will be the sum of the shipment document scores.

Critical Data Missing Test 706: All transaction documents are pulled in and the null field test is run against the critical data elements. The same data elements used in reconciliation will be checked for each document. If the data is missing then the document score will be increased by "1". Each document will have the score appended to the document. The path score will be the sum of the path document scores. Essentially, this tests gives greater weight to critical data elements. The definitions of the various critical data elements are predefined by the system 10.

Data Element Validation Test 708: All transaction documents are pulled in and a table is created which compares data elements for each document types. Each data element that is present, but apparently meaningless will increase the document score by "1".

Data Transposition Test 710: All transaction documents are pulled in and a transposition test is run. The same data elements used in reconciliation will be checked for each document comparison. If there is a conversion error then the document pair score (i.e., the combines score of each of the documents involved in the conversion) will be increased by "1". Each document will have the pair score appended to the document. The shipment score will be one half the sum of the shipment document pair scores.

Document Count Test 712: All transaction documents are pulled in and the count is taken per shipment. The document count for a given path covers the SO, CO, ASN, INV, and the POD for a total of five documents. Therefore for each ASN against a sales order the count will be five if correct and a negative one for everyone that is absent.

Terms and Conditions Test 714: Pull in the CO, ASN and INV and determine whether the INV correctly applies the terms and conditions agreed to in the CO. If terms are net 30 days for the product does the INV reflect that payment is required 30 days after the invoice date. Also, has the product been shipped as stated in the CO promised date and ASN actual ship date and has the partial shipment request been honored? If there is compliance than it is indicated by appending the words "In T&C compliance" to the invoice or "Not in T&C compliance". The score increments "1" for each of wrong payment required date, late shipment, and a partial shipment where partial was not allowed.

Goods and Services Validation Test 716: Pull in the CO, ASN and the INV. Through comparison of the line detail of the CO and the detail of the ASN determine whether the goods ordered were the goods shipped. Also determine whether it was these goods that were invoiced and in the quantity specified on the ASN. If these items are validated then append to the invoice "goods validated". If these are not validated then appended to the invoice "goods invalid." The score is incremented by "1" for the wrong SKU (i.e., product number, description, quantity in excess of CO line quantity.)

Invoice Validation Test 718: Pull the CO and the INV and compare the line item unit price, total price (proportional / rounding error), and tax (proportional / rounding error). If there is agreement between these items on each document then append to the goods invoice "price valid", versus if not "price invalid." The score increments by "1" for each wrong unit price, total price, or tax.

Freight Invoice Validation Test 720: Pull the BL and the Freight INV and compare the line item unit price, total price (proportional / rounding error), and tax (proportional / rounding error). If there is agreement between these items on each document then append to the goods invoice "price valid", versus if not "price invalid." The score increments by "1" for each wrong unit price, total price, or tax. Number of Open Critical Exceptions Test 722: Pull in and count, for each shipment, the number of unclosed critical (non-reconcilable) exceptions. Take the count and that is the score. Append the score to the ASN.

Number of Open Problematic Exceptions Test 724: Pull in and count, for each shipment, the number of unclosed exceptions less the critical (non-reconcilable) exceptions. Take the count and that is the score, append the score to the ASN

After conducting the aforementioned tests, the scoring engine transmits, in step 726, a transaction score relating the results of the various tests. Each tests score is positioned side by side to form at least an 11 digit number. Comparison of this number with predefined risk allocation tables in step 728 permits the Financial

Institution 18 to readily determine the risk of the measure transaction.

Since a transaction based risk assessment scoring method does not account for anomalous transactions, additional steps are undertaken to examine the risk of the Buyer, based upon the Buyer's past transaction history. Initially, the scoring engine 100, in step 730, obtains a Dunn & Bradstreet credit rating for the Seller. Then, using the information contained in the database 88, the scoring mechanism 100 proceeds to step 732, where a standard deviation of the Buyer's one year payment against terms record is calculated, with respect to purchases from the Seller. This enables the Financial Institution to determine whether the Buyer has a recent history of paying in term. In step 734, the scoring mechanism 100 determines the Buyer's average dollar volume per purchase over the past year as well as the fluctuation in the profile of this dollar volume. In step 736, the scoring mechanism 100 determines an historical average dollar volume of active and unclosed (i.e., unpayed) transactions and its corresponding profile. In step 738, the scoring mechanism 100 determines a present dollar volume of active and unclosed transactions. This Buyer specific scoring information supplements the transaction specific scoring information and enables the Financial Institution to better allocate the risk in the investment.

While the foregoing description contains numerous details, it is to be understood that these are provided for purposes of explanation only, and that these details are not to be read as limitations of the present invention. The specific exemplary embodiments described above can be modified in many ways without departing from the spirit and scope of the invention, as defined by the following claims and their legal equivalents.

Claims

We claim:

1. A method of reconciling a commercial transaction for the sale of goods between a buying party and a selling party using an electronic data processing system comprising the steps of: receiving purchase order information from the buying party identifying at least one item to be received from the selling party; storing said purchase order information in said electronic data processing system; receiving bill of lading information from the selling party identifying at least one item to be provided to a carrier for delivery to the buyer in response to said purchase order information; storing said bill of lading information in said electronic data processing system; receiving proof of delivery information from said carrier identifying at least one item delivered to the buying party by said carrier; storing said proof of delivery information in said electronic data processing system; comparing at least two of said purchase order information, said bill of lading information, and said proof of delivery information using said electronic data processing system to generate reconciliation information indicating whether said at least two of said purchase order information, said bill of lading information, and said proof of delivery information are reconciled; and storing said reconciliation information in said electronic database processing system.