US20050075960A1

US20050075960A1 - System and method for automated incoming payment and invoice reconciliation

Info

Publication number: US20050075960A1
Application number: US10/866,015
Authority: US
Inventors: Stacy Leavitt; Stephen Malloy; Robert Rogoff; Brian Schweigel; William Steiner; Alan Walters; Xiang Kong
Original assignee: OLD WORLD INDUSTRIES Inc
Current assignee: OLD WORLD INDUSTRIES Inc
Priority date: 2003-10-02
Filing date: 2004-06-10
Publication date: 2005-04-07
Also published as: US20050075978A1; WO2005038556A2; US20060112010A1; WO2005038556A3; WO2005040973A2; WO2005038557A2; US20050075979A1; EP1668453A2; WO2005040973A3; US20060116956A1; JP2007507799A; CN1926568A; EP1668452A4; CN1942890A; WO2005038557A3; CA2540654A1; US20070038564A1; CA2540702A1; EP1668452A2; JP2007507800A

Abstract

A system and method for automated incoming payment and invoice reconciliation is provided. A buyer of goods sends a remittance to the seller's financial institution. The buyer's remittances is processed to generate payment data which is supplied to a payment matching application. The payment matching application retrieves buyer information from said payment data and queries the seller for all outstanding invoices of said buyer. The payment matching application then attempts to match the received payment to one or more of the buyer's outstanding invoices. If a match is found, the payment is processed and the seller's financial institution and accounting system are automatically updated. If no match is found, the payment is flagged for further processing.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 60/508,221 filed Oct. 2, 2003, entitled “Adjustment Management System And Method.” This application is related to U.S. patent application Ser. No. ______ filed ______, entitled “System And Method For Automated Payment And Adjustment Processing” and U.S. patent application Ser. No. ______ filed ______, entitled “System And Method For Seller-Assisted Automated Payment Processing and Exception Management.”

BACKGROUND OF THE INVENTION

The present application generally relates to systems and methods for automatically matching and processing an incoming payment from a buyer with an invoice that has been previously sent to the buyer. More specifically, the present application presents an automated electronic system and method for matching incoming payments with a previously sent invoice, processing the transaction at the seller's side in conjunction with the seller's financial institution, closing out the transaction, and updating the seller's accounting system.
FIG. 1 illustrates a typical transaction 100 for the purchase of goods according to the prior art. As shown in FIG. 1, the transaction involves a buyer 110, a seller 130, and a financial institution 120. Typically, the buyer 110 sends a purchase request 102 or purchase order to the seller 130. The purchase request 102 identifies the goods the buyer 110 desires. The seller 130 receives the buyer's purchase request and then ships the goods to the buyer 110.
Along with or separate from the goods, the seller 130 may send a statement or invoice 105. The invoice 105 typically lists the goods being shipped and may include other information such as price, quantity, a seller coding or identification such as a SKU number and/or other order information. Alternatively, instead of a single invoice for a single shipment, a statement reflecting multiple shipments may be employed in situations where multiple shipments are sent to the same buyer.
Once the buyer 110 has received the seller's goods and invoice 105, the buyer 110 must pay for the goods. Presently, buyers pay for goods using any of a variety of methods including checks, Automated Clearing House (ACH) or other electronic/wire transfer or cash. Regardless of the method of payment, the buyer's payment is remitted to the financial institution 120 as payment 115. In some cases the payment and/or information is sent initially to the seller 130, who then passes it along to the financial institution 120.
The financial institution 120 receives the buyer's payment 115 and deposits the funds into seller's account at the financial institution 120. T The financial institution 120 then alerts the seller 130 that a payment has been received by sending payment data 125 to the seller 130.
The payment data 125 may take the form of a monthly, weekly, or typically a daily account summary. In the most preferable configuration, the account summary is updated several times a day. The payment data may also be electronically sent to the seller 130 or may be provided to the seller 130 by allowing the seller to electronically access the financial institution's records or photocopies may be mailed to the seller 130.
Additionally, as mentioned above, the buyer's payment may be received in any of a variety of methods. However, regardless of the type of payment received, the payment is typically converted to an electronic expression by the financial institution. For example, a paper check that is received by the financial institution may be scanned or imaged and the payment data on the face of the check may be converted into an electronic expression by a data entry person at the financial institution 120. ACH or wire transfers are already in an electronic form, but the financial institution's record of the transaction may also reflect the originator of the ACH, and the date of the ACH, for example. Typically, most of the bank's electronic data is sent to the seller 130 as the payment data 125.
Once the payment data 125 has been received by the seller 130, the seller 130 must typically then begin the laborious task of matching each received payment with the corresponding invoice. That is, in order to confirm that the buyer 110 has paid for the goods that were shipped, the seller 130 matches the payment data 125 received from the financial institution 120 to the invoice data 105 that was sent to the buyer 110. Once the seller 130 has matched the invoice data 105 to the payment data 125, the transaction is said to be closed-out, provided that the invoice data matches the payment data exactly. For a seller with a large number of invoices, this process may be very time consuming.
Additionally, until the payment data 125 has been successfully matched to the invoice data 105 by closing out the transaction, the seller 130 does not know whether the correct payment has been received from the buyer 110. The buyer 110 may have over or underpaid, for example. Consequently, until the transaction has been closed out, the seller 130 cannot be sure whether the current balance reflected in the seller's account at the financial institution 120 represents available cash or whether some amount is due back to the buyer 110 as an overpayment, for example.
FIG. 2 illustrates a typical work flow 200 for a processing a transaction for selling goods. First, at step 210, the sell side 201 sends an invoice to the buy side 202. Next, at step 220, the invoice is initially reviewed by the buyer. Any disputes are handled in step 230, for example by making an adjustment. Also at step 230, any dispute or adjustment is reviewed and approved by the buyer. As discussed further below and indicated in FIG. 2, the dispute and adjustment process may be quite time and labor consuming for the seller. Finally, at step 240, payment is sent from the buyer to the seller.
Note that in step 240, the payment received from the buyer is often manually matched to an invoice at the seller, which is quite time consuming. Even if some data is electronically provided, the buyer's payment systems are typically not equipped to process the received data without substantial human interaction.
Thus, the current practice for reconciling incoming payment data with invoice information at the seller is necessary, but is labor intensive and slow. Consequently, the current practice may be quite costly in terms of work hours for performing processing as well as the delay in posting cash or following up with a buyer.
Thus, a need has long been felt for a system and method for automating the reconciliation of invoice information with incoming payment data. A need has especially been felt for such a system that provides integration with the seller's cash account at a financial institution.

BRIEF SUMMARY OF THE INVENTION

The embodiments of the present invention provide a system and method for automating the reconciliation of incoming payment data with invoice data and automatically updating the seller's accounting system and the seller's financial institution. First, the seller ships goods and sends one or more invoices to the buyer. The buyer then pays for the goods by sending a payment and remittance to the seller's financial institution. The seller's financial institution processes the buyer's payment and payment information for payment data. The payment data is supplied to an invoice and payment matching application. The payment matching application preferably retrieves an identification of the buyer's invoice from the payment data and then queries the seller's accounting system for all outstanding invoices for the particular buyer. The payment matching application then attempts to match the invoice from the payment data with one or more of the buyer's outstanding invoices. If the payment matching application finds a full match, the invoiced payment is processed and the payment matching application sends posting data to the seller's accounting system and updates the seller's financial institution. If no full match is found, then the payment data is flagged for further processing by the seller. The present system may preferably be directly integrated with the seller's financial institution.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates a typical transaction for the purchase of goods according to the prior art.
FIG. 2 illustrates a typical work flow for a processing a transaction for selling goods.
FIG. 3 illustrates an invoice and payment matching application according to an embodiment of the present invention.
FIG. 4 illustrates a flowchart of the operation of the automated incoming payment and invoice reconciliation system of FIG. 3 in greater detail.
FIG. 5 illustrates an example of some of the types of informational sources that may be included in the payment data.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 3 illustrates an automated incoming payment and invoice reconciliation system 300 according to an embodiment of the present invention. The payment reconciliation system 300 includes a buyer 310, a financial institution 320, a seller 330, an invoice and payment matching application 340, and a payment management application 350. The payment management application 350 includes the financial institution 320 and the invoice and payment matching application 340.
As further described below, a purchase request 302 travels from buyer 310 to the seller 330. Invoice information 305 travels from the seller 330 to buyer 310. The invoice information 305 may travel separate from the goods and/or services provided by the seller 330, or may travel along with the goods and/ore services. Payment information 315 is sent from buyer 310 to the seller's financial institution 320. Payment data 325 is sent from the financial institution 320 to the invoice and payment matching application 340. Order data 335 is sent from the seller to the invoice and payment matching application 340. The order data 335 may be sent to the payment matching application 340 when the underlying goods are invoiced to the buyer or may be sent to the payment matching application at some later time. The posting data 345 is sent from the invoice and payment matching 340 to the seller 330.
In operation, the reconciliation system 300 proceeds generally as follows. First, the buyer 310 may decide to purchase goods, for example, from the seller 330. Typically, the buyer 310 then notifies the seller 330 that the buyer 310 wishes to make a purchase by sending a purchase request 302 to the seller 330. The seller 330 then receives the buyer's purchase request 302. The seller 330 then ships the desired goods to the buyer 310 and also sends invoice information 305 to the buyer 310.
The invoice information 305 preferably includes information relating to the goods that were shipped from the seller 330 to the buyer 310. For example, the invoice information 305 preferably includes a seller coding identifying the goods being shipped, the price, quantity, and/or other order information.
As mentioned above, the buyer receives the invoice information 305 and the goods. The buyer 310 then reviews the received goods. The buyer 310 preferably then pays for the received goods. However, the amount of the buyer's payment may differ from the payment amount invoiced by the seller 330 for a variety of reasons.
For example, if the received goods do not match the goods identified in the invoice information 305, the buyer's payment may differ from the invoice total. Additionally, for example, some or all of the goods may be damaged or destroyed. Alternatively, the price or quantity of the actual goods received may not match the agreed price or quantity of the goods appearing in the invoice information. Additionally, the seller 330 may have shipped goods other then the goods desired by the buyer 340. These are merely a few examples of the myriad difficulties that may be encountered in shipping the goods to the buyer that may result in a discrepancy from the invoice information 305.
Returning to FIG. 3, once the buyer 310 has received the goods, the buyer then pays for the goods by submitting payment information 315 to the financial institution 320. However, as shown in FIG. 3, the present embodiment operates to transform the financial institution 320 into an payment management application 350 by integrating the financial institution 320 with the invoice and payment matching application 340.
That is, the buyer's payment information 315 is sent to the financial institution 320. The payment information 315 may be any of a variety of forms ranging from cash or check to electronic fund transfers such as Electronic Data Interchange (EDI), for example. The financial institution 320 receives the payment information 315 and generates the payment data and remittance info 325. The payment data and remittance info 325 preferably includes all of the remittance data and may include additional information such as scanned images of received checks, the date of receipt of the buyer's remittance, or an invoice number included by the buyer on the check, for example. The payment data 325 is then sent to the invoice and payment matching application 340.
In addition to the payment data and remittance info 325, the invoice and payment matching application 340 also receives order data 335 from the seller 330. The order data 335 preferably includes three types of information, invoice-related information, buyer-related information and seller-related information.
With regard to invoice-related information, the order data 335 preferably includes all of the information that was included in the invoice information 305 that was sent to the buyer 310, and may also include information relating to the transfer of the goods such as a bill of lading or electronic images of the invoice information 305.
That is, one element of the payment data 325 preferably identifies the buyer making the payment. Preferably, the outstanding invoices have been previously sentor pre-delivered to the payment matching application 340, for example at the time the invoice was originally sent to the buyer. If the payment matching application 340 is unable to find a particular invoice for a particular seller, then the payment matching 340 may send the payment data to the seller for further processing, as further described below. Alternatively, the payment matching application 340 may then query the seller 330 and retrieve a listing of all outstanding invoices for the indicated buyer as order data 335. If no buyer is indicated in the payment data 325, the payment matching application 340 may preferably retrieve all outstanding invoices for all buyers. That is, the payment and remittance data 325 preferably indicates the buyer. The payment matching application 340 may then query the seller 330 for any information related to that buyer. Additionally, the payment matching application 340 may retrieve the data from the seller 330 in any of a variety of ways. For example, order data 335 may be received by the payment matching application 340 as a batch of information representing several invoices for one or more buyers as opposed to information for a single invoice of a buyer. Additionally, the payment information 315 received from the buyer 310 may represent a batch of several invoices instead of a single invoice.
With regard to buyer-related information, the order data 335 also preferably includes information relating to the buyer itself, such as the number of previous orders by the buyer, any negotiated discounts that apply to the buyer or other incentives, for example, as further described below.
With regard to the seller-related information, the order data 335 may include information with regard to the seller such as the salesperson that originated the order or internal routing information for adjustment approval, for example, as further described below.
Once the invoice and payment matching application 340 receives the payment data 325 and the order data 335, the invoice and payment matching application 340 then proceeds to attempt to match the received payment data to one or more of the outstanding invoices retrieved as part of the order data.
If the payment data 325 is matchable to one or more invoices, the invoice and payment matching application 340 displays or sends an indication of the successful match to the seller 330 as posting data 345. The posting data 345 preferably indicates which invoice or invoices are being paid by the payment data. The seller 330 receives the posting data 345 and the accounting system records at the seller 330 are then updated to reflect that the invoices(s) have been paid in order to close the transaction. Although the present discussion focuses on the operation of the payment matching application 340 on an invoice-by-invoice basis, the payment matching application may also operate on a batch basis. For example, a batch of invoices may be processed at one time. The batch of invoices may be sent to the seller at one time as batch after all invoices have been matched. A reviewer at the seller may then further review, modify and/or approve/reject the matches.
If the payment data 325 is not matchable to one or more invoices, the invoice and payment matching application 340 may then flag the payment data for further processing. The additional processing is further described in U.S. patent application Ser. No. ______ filed ______, entitled “System and Method For Automated Payment And Adjustment Processing” and U.S. patent application Ser. No. ______ filed ______, entitled “System and Method For Seller-Assisted Automated Payment Processing and Exception Management”, both of which are incorporated herein by reference in their entirety.
As mentioned above, the invoice information 305 may take any of several forms. For example, the invoice information 305 may be a paper document or an electronic document such as an e-mail, web-enabled form, or other EDI information exchange.
Although the present embodiment is discussed above in relation to the buyer ordering goods, the buyer may instead be interested in securing services. Similar considerations arise in the context of procuring services with regard to invoice and payment matching. Although the current description focuses on goods, the present invoice and payment matching system applies equally well to services and is not limited to goods. Additionally, the applicability of the present system is not limited to any specific industry or sector.
As mentioned above, the invoice information may include a great deal of information as further described below. However, not all of the items of information listed below need be present in the invoice information. The inclusion of an item as part of the invoice information may be configured by the seller. For example, the invoice information may include information concerning the quantity and price of goods and/or services sold by the seller 330 to buyer 310. The invoice information 305 may also include information such as the delivery date, buyer's 310 name and address, the seller's 330 name and address, any amount of money that is past due from buyer 310 to the seller 330, or any available credit buyer 310 has with the seller 330. In addition, the invoice information 305 preferably includes an invoice number to be used by the seller 330 for identification and tracking purposes.
Similar to the invoice information above, the payment information may take any of a wide number of forms as chosen by the buyer. For example, the payment information 315 may therefore include a check, a financial institution draft, a cashier's check, a money order, an order to charge a credit line, a promissory note, or any other document that shows payment for goods and/or services received. In addition, the payment information 315 may also include an electronic image of the form of payment. For example, the payment information 315 may include an electronic image of a check used to pay for the goods and/or services.
Further to the discussion above, the payment data and remittance information are preferably constructed by the financial institution 320 to the extent that the payment data and/or remittance info are not already available from the buyer in electronic form. That is, the financial institution 320 may review incoming payment information, such as a check for example, and then develop a set of remittance data relating to the check. For example, the financial institution 320 may electronically note the date of receipt, payor, payee, and any account or invoice numbers on the check. The financial institution may also electronically image the received check. The notations made by the financial institution 320 may then be passed to the invoice and payment matching application as part of the payment data and remittance info 325.
Alternatively, if the payment information is electronically delivered to the financial institution 320, the payment information may take any of a wide variety of forms. The financial institution 320 typically processes the received payment information and re-expresses or re-formats the payment information to be in accordance with the financial institution's internal processing desires. The reprocessed electronically received payment information is preferably then passed to the invoice and payment matching application 340 as part of the payment data
The payment data itself may take any of a wide variety of forms as selected by the financial institution 320. For example, the payment data 325 may alternatively be comprised of XML documents, EDI documents, information from internet-based financial services, or any other form of electronic data relating to the payment of goods or services.
The order data 335 and posting data 345 may also take any of wide variety of forms such as e-mail, XML documents, HTML documents, or EDI, for example.
Additionally, the invoice and payment matching application 340 may be implemented, for example, as a package software application or installed at a financial institution or other third party as an application service provider (ASP). As an ASP, the invoice and payment matching application 340 may be directly hosted by the financial institution 320, the seller 330 or a third party. The actual physical location of the invoice and payment matching application 340 is not relevant as long as it remains in communication with the financial institution 320 and the seller 330. For example, the payment matching application 340 may be hosted or installed at a third party or may be otherwise outsourced.
FIG. 4 illustrates a flowchart 400 of the operation of the automated incoming payment and invoice reconciliation system of FIG. 3 in greater detail. First, the payment data and the order data are received at steps 401-402. Next, at step 405, the payment data is received and batched by the financial institution. That is, preferably the financial institution may accumulate a number of payments in a queue to form a batch. Then, a person at the seller may access the financial institution's records to process the batch of payments as a whole. While the accumulation of a number of payments into batches is preferred, the system may process individual payments if desired by the seller.
At step 410, each payment in the batch of payments is evaluated. Preferably, the payment data 325 includes invoice information for linking a payment made by the buyer with a specific invoice number sent to the buyer by the seller. The listing of invoice numbers is preferably retrieved from the seller as part of the order data 335. At step 415, it is determined whether the payment includes an invoice number that matches an invoice number provided by the order data. If a matching invoice number is found, the process proceeds to step 430 and the invoice is matched to the payment. If no invoice number match is found, the process proceeds to step 420 and further processing by the seller may be required.
Although the matching of the payment data to the order data described above is performed on the basis of invoice number, other elements of the payment and/or remittance information may be used to match the buyer's payment. For example, payments may be matched based on a purchase order number or remitter or seller's name, for example.
At step 420, additional processing, such as further automated or human interaction by the seller may be required to match the received payment data with one or more invoices retrieved in the order data. Such further processing is further described in U.S. patent application Ser. No. ______ filed ______, entitled “System And Method For Automated Payment And Adjustment Processing” and U.S. patent application Ser. No. ______ filed ______, entitled “System And Method For Seller-Assisted Automated Payment Processing and Exception Management”, which are incorporated herein by reference in their entirety.
Proceeding now to step 430, the received payment has been matched to a specific invoice number. Next, at step 432, the invoiced payment amount included in the invoice is compared to the received payment. If the received payment matches the invoiced payment, the process proceeds to step 435. At step 435, the payment is marked for posting to the seller's accounting system.
Conversely, if the received payment does not match the invoiced payment, then the process proceeds to step 420 and further automated or human interaction by the seller may be required to match the payment to one or more invoices.
Finally, at step 435, the received payment and its respective invoice are market for posting on the seller's system. At step 490, the posting data is transmitted to the seller to update the seller's accounting system.
Thus, the buyer's payment has been automatically matched with the seller's outstanding invoice and the seller's accounting system has been updated to reflect an accurate indication or available cash. The requirement for human interaction to process the seller's payment by matching the payment to an invoice has been minimized. Although the seller's assistance may be required when the received payment does not match an outstanding invoice, the seller's direct interaction is no longer necessary in the typical case of a payment exactly matching an invoice.
Additionally, although the present description recites that data is received directly from the buyer and seller, the actual data may be retrieved from a third part intermediary, agent, hosting service, or other party on behalf of the respective buyer and seller. Additionally, the payment need not be sent directly from the original buyer and may instead originate with the buyer's distributor, corporate parent, agent, or other third party.
Additionally, although the invoice and payment matching application is preferably integrated as part of the financial institution, the invoice and payment matching application may be implemented as a third party or even at the seller's site.
FIG. 5 illustrates an example of some of the types of informational sources that may be included in the payment data 325. As discussed above, the payment data 325 may include data derived from XML documents 510, EDI documents 520, electronic data 540, and/or data from web services 530. The electronic data 540 may include electronic images of the payment information 315, as described in FIG. 3. The payment data 325 may be configured in any internal format desired by the financial institution that is capable of being received and processed by the invoice and payment matching application 340.
Thus, the automated incoming payment and invoice reconciliation system provides an automated solution to review and verify payment for the transaction between buyer and seller. That is, each payment may be automatically evaluated and matched with an outstanding invoice, preferably using the invoice number. If the payment amount of the transaction matches, the buyer's payment may be directly posted to the seller's account at the financial institution and the seller's accounting system may be updated by the posting data. Preferably, most of the transactions occurring between buyers and sellers proceed as expected and consequently have matching invoice numbers and payment amounts. Consequently, a large percentage of the matching operations that previously may have required human interaction at the seller may now be accomplished automatically. Conversely, if the transaction does not match, then further processing at the seller may be required.
Thus, the present embodiment serves to automatically match payment data with invoice data. As mentioned above, the prior art methodologies for matching payment data with invoice data involved a great deal of manual effort and were quite slow. With the present embodiment, most incoming payments may be matched and processed automatically. Thus reducing effort and cost and providing a more accurate assessment of available cash.
While particular elements, embodiments and applications of the present invention have been shown and described, it is understood that the invention is not limited thereto since modifications may be made by those skilled in the art, particularly in light of the foregoing teaching. It is therefore contemplated by the appended claims to cover such modifications and incorporate those features that come within the spirit and scope of the invention.

Claims

1. A method for automated payment processing, said method including:

receiving payment information at a financial institution from a buyer;

generating payment data based on said payment information;

receiving said payment data at a payment matching application;

querying a seller for order data, wherein said order data includes data regarding one or more outstanding invoices;

receiving said order data from a seller at said payment matching application; and

comparing said payment data to said order data to match said payment data to one or more invoices included in said order data to process said payment.

2. The method of claim 1, said method further including closing out a transaction when said payment data matches one or more outstanding invoices of buyer.

3. The method of claim 1, said method further including flagging said payment data for further processing when said payment data does not match one or more outstanding invoices of buyer.

4. The method of claim 1 wherein said order data only includes invoice information for the buyer submitting said payment information.

5. The method of claim 1 wherein said order data includes all outstanding invoices of said seller.

6. The method of claim 2, said method further including sending posting data to said seller when said payment data matches one or more outstanding invoices of buyer.

7. A method for automated payment processing, said method including:

receiving payment information at a financial institution from a buyer;

generating payment data based on said payment information;

receiving said payment data at a payment matching application;

comparing said payment data to said order data to match said payment data to one or more invoices included in said order data to process said payment,

wherein said payment matching application is implemented as an Application Service Provider (ASP).

8. The method of claim 1 wherein said matching application is integrated with said financial institution.

9. A method for automated payment processing, said method including:

receiving payment information at a financial institution from a buyer;

generating payment data based on said payment information;

receiving said payment data at a payment matching application;

wherein said payment matching application is implemented as a software application at said seller.

10. A method for automated payment processing, said method including:

receiving payment information at a financial institution from a buyer;

generating payment data based on said payment information;

receiving said payment data at a payment matching application;

wherein said payment matching application is implemented as a software application at a financial institution

11. A method for automated payment processing, said method including:

receiving payment information at a financial institution from a buyer;

generating payment data based on said payment information;

receiving said payment data at a payment matching application;

wherein said payment matching application is implemented as a software application that has been outsourced to a third party

12. A method for automated matching of received payments with outstanding invoices, said method including:

receiving payment data at a payment matching application, said payment data representing a payment of a buyer;

receiving order data at said payment matching application, said order data representing one or more outstanding invoices of a seller;

comparing said payment data and said order data to determine which one or more invoices matching said payment data; and

sending posting data to said seller identifying the one or more and one invoices matching said payment data.

13. The method of claim 12 further including updating an accounting system at said seller to indicate the payment of said one or more than one invoices matching said payment data.

14. The method of claim 13 wherein said order data only includes invoice information for said buyer originating said payment information.

15. The method of claim 13 wherein said order data includes all outstanding invoices of said seller.

16. The method of claim 13 wherein said comparing takes places at an Application Service Provider (ASP).

17. The method of claim 16 wherein said ASP is installed at a financial institution.

18. The method of claim 16 wherein said ASP is integrated with a financial institution.

19. The method of claim 16 wherein said ASP is outsourced to a third party provider.

20. The method of claim 19 wherein said third party provider is integrated with a financial institution.

21. A system for automated matching of received payments with outstanding invoices, said system including:

a payment matching application receiving payment data, said payment data representing a payment of a buyer,

wherein said payment matching application also receives order data, said order data representing one or more outstanding invoices of a seller,

said payment matching application comparing said payment data and said order data to determine which one or more invoices matching said payment data, and

said payment matching application sending posting data to said seller identifying the one or more and one invoices matching said payment data.

22. The system of claim 21 further including and accounting system at said seller, said accounting system receiving said posting data and updating one or more entries to indicate the payment of said one or more and one invoices matching said payment data.

23. The system of claim 21 wherein said order data only includes invoice information for said buyer originating said payment information.

24. The system of claim 21 wherein said order data includes all outstanding invoices of said seller.

25. A system for automated matching of received payments with outstanding invoices, said system including:

said payment matching application sending posting data to said seller identifying the one or more and one invoices matching said payment data,

wherein said payment matching application is an Application Service Provider (ASP).

26. A system for automated matching of received payments with outstanding invoices, said system including:

wherein said payment matching application is implemented as a software application at a financial institution.

27. A system for automated matching of received payments with outstanding invoices, said system including:

wherein said payment matching application is implemented as a software application that has been outsourced to a third party.