U.S. patent application number 10/866015 was filed with the patent office on 2005-04-07 for system and method for automated incoming payment and invoice reconciliation.
Invention is credited to Kong, Xiang, Leavitt, Stacy A., Malloy, Stephen Louis, Rogoff, Robert, Schweigel, Brian R., Steiner, William M., Walters, Alan J..
Application Number | 20050075960 10/866015 |
Document ID | / |
Family ID | 34465079 |
Filed Date | 2005-04-07 |
United States Patent
Application |
20050075960 |
Kind Code |
A1 |
Leavitt, Stacy A. ; et
al. |
April 7, 2005 |
System and method for automated incoming payment and invoice
reconciliation
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.
Inventors: |
Leavitt, Stacy A.;
(Grayslake, IL) ; Malloy, Stephen Louis; (San
Francisco, CA) ; Rogoff, Robert; (Wilmette, IL)
; Schweigel, Brian R.; (Antioch, IL) ; Steiner,
William M.; (Park Ridge, IL) ; Walters, Alan J.;
(Chicago, IL) ; Kong, Xiang; (Lakezurich,
IL) |
Correspondence
Address: |
MCANDREWS HELD & MALLOY, LTD
500 WEST MADISON STREET
SUITE 3400
CHICAGO
IL
60661
|
Family ID: |
34465079 |
Appl. No.: |
10/866015 |
Filed: |
June 10, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60508221 |
Oct 2, 2003 |
|
|
|
Current U.S.
Class: |
705/35 ;
705/40 |
Current CPC
Class: |
G06Q 20/0457 20130101;
G07G 1/06 20130101; G06Q 20/00 20130101; G07F 17/42 20130101; G06Q
20/04 20130101; G06Q 40/00 20130101; G06Q 20/102 20130101; G06Q
30/04 20130101; G06Q 20/14 20130101; G06Q 20/12 20130101; G07F 9/04
20130101; G07G 5/00 20130101 |
Class at
Publication: |
705/035 ;
705/040 |
International
Class: |
G06F 017/60 |
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; 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, 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; 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, 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; 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, 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; 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, 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: 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, 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: 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, 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: 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, wherein said payment matching application is implemented as a
software application that has been outsourced to a third party.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] 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.
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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
[0015] 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
[0016] FIG. 1 illustrates a typical transaction for the purchase of
goods according to the prior art.
[0017] FIG. 2 illustrates a typical work flow for a processing a
transaction for selling goods.
[0018] FIG. 3 illustrates an invoice and payment matching
application according to an embodiment of the present
invention.
[0019] FIG. 4 illustrates a flowchart of the operation of the
automated incoming payment and invoice reconciliation system of
FIG. 3 in greater detail.
[0020] 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
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
* * * * *