U.S. patent application number 10/865997 was filed with the patent office on 2005-04-07 for system and method for seller-assisted automated payment processing and exception management.
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 | 20050075979 10/865997 |
Document ID | / |
Family ID | 34465079 |
Filed Date | 2005-04-07 |
United States Patent
Application |
20050075979 |
Kind Code |
A1 |
Leavitt, Stacy A. ; et
al. |
April 7, 2005 |
System and method for seller-assisted automated payment processing
and exception management
Abstract
A system and method for seller-assisted automated payment and
adjustment processing is provided. A seller receives a payment from
a buyer that does not match the seller's invoice and consequently
requires an adjustment. An adjustment document creator receives the
payment data from the buyer and retrieves buyer-specific order data
from said seller to construct an adjustment document. A variety of
adjustment documents may be created depending upon the actual
adjustment required. The adjustment document may then be
automatically routed to a set of one or more buyer-specific human
reviewers for approval of the adjustment. The automated payment and
adjustment processing system is preferably integrated with the
seller's financial institution.
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; (Lake Zurich,
IL) |
Correspondence
Address: |
McAndrews, Held & Malloy, Ltd.
34th Floor
500 W. Madison Street
Chicago
IL
60661
US
|
Family ID: |
34465079 |
Appl. No.: |
10/865997 |
Filed: |
June 10, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60508221 |
Oct 2, 2003 |
|
|
|
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
G06Q 30/04 20130101;
G06Q 20/14 20130101; G06Q 40/00 20130101; G07G 5/00 20130101; G07F
9/04 20130101; G06Q 20/04 20130101; G06Q 20/12 20130101; G06Q
20/0457 20130101; G07G 1/06 20130101; G07F 17/42 20130101; G06Q
20/00 20130101; G06Q 20/102 20130101 |
Class at
Publication: |
705/040 |
International
Class: |
G06F 017/60 |
Claims
1. A method for automatically generating an adjustment document,
said method including: receiving payment information from a buyer;
receiving invoice information from a seller; comparing said payment
information and said invoice information; and automatically
generating an adjustment document when said payment information
differs from said invoice information.
2. The method of claim 1 wherein said adjustment document is one of
a plurality of available adjustment documents.
3. The method of claim 2 further comprising receiving remittance
information regarding said payment information and wherein said
adjustment document is automatically generated based at least in
part on said remittance information.
4. The method of claim 2 wherein the difference between said
invoice information and said payment information is a currency
amount and said adjustment document is automatically generated
based at least in part on the size of the currency amount.
5. The method of claim 1 further including routing said adjustment
document to a human reviewer for approval.
6. The method of claim 5 wherein the difference between said
invoice information and said payment information is a currency
amount and wherein said routing is based at least in part on the
size of said currency amount.
7. The method of claim 5 wherein said routing is based on a
predetermined seller configuration.
8. The method of claim 5 wherein said routing is based at least in
part on the identity of said buyer.
9. The method of claim 5 further including routing said adjustment
document to an additional human reviewer for approval.
10. A method for automatically routing an adjustment document to a
reviewer, said method including: receiving an electronic adjustment
document at a workflow approval processor, said adjustment document
based on a payment received from a buyer; determining a routing
workflow for said adjustment document, wherein said routing
workflow is variable depending on information in said adjustment
document; and automatically routing said adjustment document from
said workflow approval processor to at least one of a plurality of
reviewers based on said routing workflow.
11. The method of claim 10 wherein said routing is based on the
identity of said buyer.
12. The method of claim 10 wherein adjustment document includes a
currency amount being disputed and wherein said routing is based at
least in part on the size of said currency amount.
13. The method of claim 10 wherein said routing is based on a
predetermined seller configuration.
14. The method of claim 10 wherein said routing is based at least
in part on the identity of said buyer.
15. The method of claim 10 further including routing said
adjustment document to an additional human reviewer for
approval.
16. A method for automatically routing an adjustment document to a
reviewer, said method including: receiving an electronic adjustment
document at a workflow approval processor, said adjustment document
based on a payment received from a buyer; determining a routing
workflow for said adjustment document, wherein said routing
workflow is variable depending on information in said adjustment
document; and automatically routing said adjustment document from
said workflow approval processor to at least one of a plurality of
reviewers based on said routing workflow, wherein said routing is
performed by an Application Service Provider (ASP).
17. The method of claim 10 further including: receiving an approval
from said at least one of a plurality of reviewers; processing said
payment received from said buyer using said adjustment document;
and posting said payment received from said buyer.
18. The method of claim 10 further including: receiving a denial
from said at least one of a plurality of reviewers; and referring
said adjustment document to a collections department.
19. A system for automatically generating an adjustment document,
said method including: a payment processing and exception
management application receiving payment information from a buyer
and receiving invoice information from a seller; a business data
filter comparing said payment information and said invoice
information; and an adjustment document creator automatically
generating an adjustment document when said payment information
differs from said invoice information.
20. The system of claim 19 wherein said adjustment document creator
includes a plurality of available adjustment documents.
21. The system of claim 20 wherein said adjustment document creator
automatically generates said adjustment document based at least in
part on the identity of said buyer.
22. The system of claim 20 wherein the difference between said
invoice information and said payment information is a currency
amount and said adjustment document creator automatically generates
said adjustment document based at least in part on the size of the
currency amount.
23. The system of claim 20 further including a workflow approval
processor routing said adjustment document to a human reviewer for
approval.
24. The system of claim 23 wherein said workflow approval processor
routes said adjustment document based on the identity of said
buyer.
25. The system of claim 23 wherein the difference between said
invoice information and said payment information is a currency
amount and wherein said workflow approval processor routes said
adjustment document based at least in part on the size of said
currency amount.
26. The system of claim 23 wherein said workflow approval processor
routes said adjustment document based on a predetermined seller
configuration.
27. The system of claim 23 wherein said workflow approval processor
routes said adjustment document to an additional human reviewer for
approval.
28. The system of claim 19 wherein said workflow approval processor
is implemented as an Application Service Provider (ASP).
29. The system of claim 19 wherein said workflow approval processor
is implemented at a financial institution
30. The system of claim 19 wherein said workflow approval processor
is outsourced to a third party
31. A system for automatically routing an adjustment document to a
reviewer, said system including: a workflow approval processor
receiving an electronic adjustment document, said adjustment
document based on a payment received from a buyer, wherein said
workflow approval processor determines a routing workflow for said
adjustment document, wherein said routing workflow is variable
depending on information in said adjustment document; and a
plurality of reviewers, wherein said workflow approval processor
automatically routes said adjustment document to at least one of
said plurality of reviewers based on said routing workflow.
32. The system of claim 31 wherein said workflow approval processor
routes said adjustment document based on the identity of said
buyer.
33. The system of claim 31 wherein adjustment document includes a
currency amount being disputed and wherein said workflow approval
processor routes said adjustment document based at least in part on
the size of said currency amount.
34. The system of claim 31 wherein said workflow approval processor
routes said adjustment document to an additional reviewer for
approval.
35. The system of claim 31 wherein said workflow approval processor
is implemented as an Application Service Provider (ASP).
36. The system of claim 31 wherein said workflow approval processor
is implemented at a financial institution
37. The system of claim 31 wherein said workflow approval processor
is outsourced to a third party
38. The system of claim 31 wherein said workflow approval processor
receives an approval from said at least one of a plurality of
reviewers, processes said payment received from said buyer using
said adjustment document, and posts said payment received from said
buyer.
39. The system of claim 31 wherein said workflow approval processor
receives a denial from said at least one of a plurality of
reviewers and refers said adjustment document to a collections
department.
40. A method for automatically generating an adjustment document,
said method including: receiving payment information from a buyer;
receiving invoice information from a seller; comparing said payment
information and said invoice information; and automatically
generating an adjustment document when said payment information
differs from said invoice information, wherein said comparing is
performed by an Application Service Provider (ASP).
41. A method for automatically generating an adjustment document,
said method including: receiving payment information from a buyer;
receiving invoice information from a seller; comparing said payment
information and said invoice information; and automatically
generating an adjustment document when said payment information
differs from said invoice information, wherein said comparing is
performed by a software package installed at a financial
institution.
42. A method for automatically routing an adjustment document to a
reviewer, said method including: receiving an electronic adjustment
document at a workflow approval processor, said adjustment document
based on a payment received from a buyer; determining a routing
workflow for said adjustment document, wherein said routing
workflow is variable depending on information in said adjustment
document; and automatically routing said adjustment document from
said workflow approval processor to at least one of a plurality of
reviewers based on said routing workflow, wherein said routing is
performed by a software package installed at a financial
institution.
43. A method for automatically routing an adjustment document to a
reviewer, said method including: receiving an electronic adjustment
document at a workflow approval processor, said adjustment document
based on a payment received from a buyer; determining a routing
workflow for said adjustment document, wherein said routing
workflow is variable depending on information in said adjustment
document; and automatically routing said adjustment document from
said workflow approval processor to at least one of a plurality of
reviewers based on said routing workflow, wherein said routing is
performed by a software package that has been outsourced to a third
party
44. A method for processing payments from a buyer, said method
including: receiving invoice information from a seller, said
invoice information representing at least one unpaid invoice billed
to a buyer by said seller; receiving payment information from a
buyer; electronically comparing said payment information to said
invoice information to make an automated determination whether said
payment information is matchable to at lease one of said unpaid
invoices; and transmitting said payment information to a reviewer
at said seller when said automated determination is not able to
match said payment information to at least one of said unpaid
invoices.
45. The method of claim 44 further including allowing the reviewer
at the user to match said payment information with at least one of
said unpaid invoices.
46. The method of claim 45 wherein said automated determination is
not able to match said payment information to at least one of said
unpaid invoices because the payment amount of said payment
information does not match a payment amount included in one of said
at least one unpaid invoices.
47. The method of claim 46 wherein said payment amount of said
payment information does not match said payment amount of one of
said at least one unpaid invoices due to data entry error.
48. The method of claim 46 wherein said payment amount of said
payment information does not match said payment amount of one of
said at least one unpaid invoices because said payment information
includes a payment amount for more than one of said unpaid invoices
and said payment information does not indicate which of said more
than one unpaid invoices are included.
49. The method of claim 46 wherein said payment amount of said
payment information does not match said payment amount of one of
said at least one unpaid invoices because the payment amount of
said payment information represents pre-payment for an invoice that
does not yet exist.
50. The method of claim 46 wherein said payment amount of said
payment information does not match said payment amount of one of
said at least one unpaid invoices because the payment amount of
said payment information represents payment for an invoice that has
already been paid.
51. The method of claim 46 wherein said payment amount of said
payment information does not match said payment amount of one of
said at least one unpaid invoices because said invoice is subject
to a deduction or adjustment.
52. The method of claim 46 wherein said seller is a first seller
and said payment amount of said payment information does not match
said payment amount of one of said at least one unpaid invoices
because said payment amount of said payment information represents
a payment to a second seller other than said first seller.
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 Incoming Payment and
Invoice Reconciliation" and U.S. patent application Ser. No. ______
filed ______, entitled "System And Method For Automated Payment And
Adjustment Processing."
BACKGROUND OF THE INVENTION
[0002] The present application generally relates to systems and
methods for management of exceptions such as adjustments taken by
buyers with regard to invoices sent by a seller. More specifically,
the present application presents a seller-assisted automated system
and method for processing exceptions, such as deductions taken by a
buyer or credits to a buyer, processing the transaction at the
seller's side, 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 at that time or
at some time thereafter. Presently, in many cases, buyers pay for
goods using any of a variety of methods including cash, checks,
credit cards, Automated Clearing House (ACH) or other
electronic/wire transfer. Regardless of the method of payment, the
buyer's payment and/or information is remitted to the financial
institution 120 as remittance information 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
and remittance 115 and deposits the funds in seller's account at
the financial institution 120. 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 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 can not 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] As may be expected, matching payment data to invoice
information may be quite time consuming, especially when the seller
130 is shipping goods to a large number of buyers 110.
Additionally, matching payment data to invoice information may be
further complicated because the received payment data 125 may not
match the invoice 105.
[0012] That is, the buyer may submit a payment that differs from
the invoiced amount. The payment submitted by the buyer may be less
than or greater than the invoiced amount. For example, the payment
submitted by the buyer may be less than the invoiced amount when
the buyer's payment is not for all of the goods, for example, such
as when some of the goods are not received or are damaged.
Additionally, the buyer's payment may be less than the invoiced
amount due to a disagreement as to price or quantity of goods or of
a discount received by the buyer. Conversely, the payment submitted
by the buyer may be greater than the invoiced amount due to errors
by the buyer such as typographical errors or billing discrepancies
or when the buyer pre-pays or over pays.
[0013] When a payment received from a buyer does not match the
seller's invoice, an adjustment to the invoice is typically made.
When the adjustment results in a lessening of the invoice amount,
the adjustment is referred to as a deduction (also known as a
chargeback or dispute). Typically, the customer demands an
adjustment. This demand for an adjustment is commonly referred to
as an adjustment request. Though a deduction doesn't necessarily
have to reference a specific seller's invoice, adjustment requests
are typically in the form of a deduction in the invoice amount. For
example, when a customer receives damaged goods, he or she demands
that the invoice amount be reduced to reflect that the good had
been damaged, and therefore demands an adjustment request in the
form of a deduction in the invoice amount. Additionally, the
buyer's payment may not match the seller's invoice if the seller's
invoice was in error from the start. Alternatively, a buyer's
invoice may be given an adjustment such as a buyer-specific
discount, for example.
[0014] An adjustment request may be in several forms. For example,
the adjustment request may be a phone call from the buyer to the
seller requesting an adjustment. Also, the adjustment request may
be a letter or email from the customer to the seller. In addition,
the adjustment request may be a payment less than the invoice
amount or an agreed upon allowance, along with a debit memo
outlining the reasons for adjustment. Alternatively, the adjustment
request may also be any form of electronic communication such as
electronic data from a website.
[0015] 141 Once the adjustment request has been received by the
seller, the adjustment request is typically passed to a human for
review. The reviewers are individuals who review the adjustment
request and the relevant documents in order to approve or deny the
adjustment request. The consent of more than one reviewer may be
necessary to allow a particular customer to make an adjustment.
Once all of the reviewers have reviewed the adjustment request and
all the relevant documents, the adjustment request is either
approved or denied.
[0016] If the seller approves the adjustment request, the seller
issues a credit to the customer. Re-invoicing the buyer typically
has a similar effect on the seller's accounting system as issuing a
credit to the customer. Conversely, if the customer requests an
adjustment in the form of a deduction in the invoice amount, and
the adjustment request is approved by the seller, the seller
reduces the invoice amount through a credit memo and accepts a
lower payment from the buyer.
[0017] As mentioned above, when adjustment requests are received by
sellers, the sellers must monitor and resolve the adjustment
requests. Typically, sellers must manually collect the adjustment
request and all relevant documents. The relevant documents
typically include the invoice, payment information, and delivery
information. The payment information is any documentation
confirming payment for the goods. For example, payment information
may include a check from the customer, an electronic fund transfer
from the customer to the seller, or documentation of a charge to a
credit account. The delivery information is any documentation
confirming delivery of the goods. For example, delivery information
may be a proof of delivery.
[0018] Once the seller collects the adjustment request and all the
relevant documents, the seller sends the adjustment request and the
relevant documents to one or more reviewers. Assembling the
adjustment request and routing the adjustment request to the
correct reviewers is difficult and time consuming in practice. For
sellers using older systems, typically the documents supporting the
adjustment request must be gathered manually into an adjustment
package. Additionally, the adjustment package must stay together as
it travels from reviewer to reviewer. Finally, there is typically a
delay in the routing of the adjustment package and the potential
for loss of part or all of the supporting documents.
[0019] More modern systems typically involve at least a portion of
the documentation of the adjustment package in electronic form. For
example, a bill of lading may be retrieved from an electronic
inventory system by a reviewer at the reviewer's desk. However,
much of the documentation is typically still in paper form.
Additionally, even if one or more of the items of documentation are
in electronic form, the items of documentation are typically on
different systems that do not cross-communicate.
[0020] Additionally, even if the items of documentation in the
adjustment package are available in electronic form, the current
business practice is typically duplicative of effort, especially in
the case where multiple reviewers are required. For example, a
first reviewer may receive the paper portion of the adjustment
package, log in to a first application to retrieve a first
electronic item of documentation, log into a second application to
retrieve a second electronic item of documentation, etc., and
eventually approve the adjustment. The adjustment is then sent to a
second reviewer who typically duplicates the process just performed
by the first reviewer or may review a copy of the adjustment
documents prepared by the first reviewer.
[0021] 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.
[0022] 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.
Additionally, at step 230, the adjustment or dispute process is
identified as labor intensive and lengthy for both the buyer and
the seller.
[0023] Thus, current systems for resolving adjustments are overly
costly for a number of reasons. First, there is an abundance of
information to monitor. This information includes customer
information, invoice information, the cause for the adjustment
request (i.e., whether a deduction or overpayment refund is being
sought), past invoices of the customer, past adjustment requests
from the customer, and the customer's credit line with the seller,
and may include other information.
[0024] Second, in large businesses, there is often an inability to
ensure that all of the relevant departments of the seller (for
example, the accounting department, shipping department, and credit
department, among others) are able to review, edit, and approve or
deny the adjustment request. This inability to ensure that all of
the relevant departments of the seller review the adjustment
request stems from the manual coupling of the adjustment request
and the relevant documentation, as discussed above. Undoubtedly,
errors occur on a frequent basis where, for example, a reviewer
does not receive all of the documentation that he requires to
properly review the adjustment request.
[0025] In a related problem, third, it may be very difficult to
ensure that all relevant departments of the seller perform their
reviews in a timely manner, especially when several departments are
involved. For example, delay in ensuring that a first reviewer
receives all of the documentation required for his review of the
adjustment request will cause further delay for subsequent
reviewers. In this way, when other reviewers are waiting for the
first reviewer to complete his review of the adjustment document
and relevant documentation, delay in the processing of the
adjustment request ensues. This delay becomes even more troublesome
when multiple levels of review (that is, one reviewer must wait and
review a first reviewer's resolution of the adjustment request) are
required by the seller. For example, where a seller requires that
all initial reviews of an adjustment request be reviewed by a
manager of reviewers, any delay in routing the information to, and
receiving a resolution from, one or more of the reviewers will only
cause additional delay.
[0026] Finally, any delay in ensuring that all relevant departments
review the adjustment request will cause additional delays in
pursuing collection of a debt owed by a customer or in issuing a
refund owed to a customer. This can cause business losses due to
lengthy collection delays and a loss of customer goodwill. In
addition, current systems and methods do not provide for
integration between the adjustment management system and method and
the bank of the seller.
[0027] Thus, a need has long been felt for a sales adjustment
management solution that eliminates or minimizes many of the
problems associated with current systems. A need has especially
been felt for such a system that provides the greatest degree of
automation of adjustment management, for example, making sure all
relevant documents are collected and delivered to a human reviewer.
Additionally, a need has long existed for such a system that
simplifies the routing of outstanding adjustments to the relevant
human reviewer and provides better routing and documentation of the
adjustment process and is directly integrated with the seller's
financial institution. Also, a need has long been felt for an
adjustment management system that provides for greater integration
with the seller's financial institution.
BRIEF SUMMARY OF THE INVENTION
[0028] The embodiments of the present invention provide a system
and method for automating the processing of adjustments to payments
received from a buyer. That is, a buyer sends a payment to a
seller, but the buyer's payment does not match the seller's
invoice. Consequently, an adjustment to the buyer's payment may be
required. A payment processing and exception management application
receives the buyer's payment information and retrieves
buyer-specific order data from data available to the seller. The
payment processing and exception management application includes an
adjustment document creator which automatically creates an
adjustment document based on the payment data and order data. The
adjustment document may be one of several available adjustment
documents that may be used for different adjustments. The
adjustment document is then passed to a workflow approval
processor. The workflow approval processor then routes the
adjustment document to one or more human reviewers. The set of
human reviewers may be buyer-specific or may be determined based on
information in the payment data received from the buyer or upon a
comparison of the payment data received from the buyer with
information in the buyer-specific order data, such as the
outstanding invoices of the buyer. Additionally, the payment and
adjustment management application is preferably integrated with the
seller's financial institution.
BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS
[0029] FIG. 1 illustrates a typical transaction for the purchase of
goods according to the prior art.
[0030] FIG. 2 illustrates a typical work flow for a processing a
transaction for selling goods.
[0031] FIG. 3 illustrates an automated payment processing and
exception management system according to an embodiment of the
present invention.
[0032] FIG. 4 illustrates an embodiment of the adjustment
management application of FIG. 3 in greater detail.
[0033] FIG. 5 illustrates an example of some of the types of
informational sources that may be included in the payment data.
[0034] FIG. 6 illustrates a flowchart of the operation of the
business data filter according to one embodiment of the present
invention.
[0035] FIG. 7 illustrates an example of the buyer-specific
information that may be received by the adjustment document creator
to allow the adjustment document creator to create and route the
adjustment document.
[0036] FIG. 8 illustrates a variety of exemplary documents and
other items for incorporation into the adjustment document.
[0037] FIG. 9 illustrates a Customer Compliance Form example
according to an embodiment of the present invention.
[0038] FIG. 10 illustrates a Damage Form example according to an
embodiment of the present invention.
[0039] FIG. 11 illustrates a Discount Form example according to an
embodiment of the present invention.
[0040] FIG. 12 illustrates a Freight Form example according to an
embodiment of the present invention.
[0041] FIG. 13 illustrates a Marketing Form example according to an
embodiment of the present invention.
[0042] FIG. 14 illustrates a Miscellaneous Form example according
to an embodiment of the present invention.
[0043] FIG. 15 illustrates a Price Form example according to an
embodiment of the present invention.
[0044] FIG. 16 illustrates a Quantity Form example according to an
embodiment of the present invention.
[0045] FIG. 17 illustrates a Return Form example according to an
embodiment of the present invention.
[0046] FIG. 18 illustrates a Tax Form example according to an
embodiment of the present invention.
[0047] FIG. 19 illustrates a Warranty Form example according to an
embodiment of the present invention.
[0048] FIG. 20 illustrates an exemplary operation of the workflow
approval processor in accordance with a pre-configured
buyer-specific adjustment approval workflow.
[0049] FIG. 21 illustrates an exemplary task list for a human
reviewer summarizing all outstanding adjustments awaiting review by
the human reviewer.
[0050] FIG. 22 illustrates a flowchart of an embodiment of the
procedure for processing an adjustment form.
[0051] FIG. 23 illustrates a high-level representation of an
adjustment document, such as the adjustment documents of FIGS.
9-19.
DETAILED DESCRIPTION OF THE INVENTION
[0052] FIG. 3 illustrates an automated payment processing and
exception management system 300 according to an embodiment of the
present invention. The payment processing and exception management
system 300 includes a buyer 310, a financial institution 320, a
seller 330, an adjustment processing application 340, and a payment
and adjustment management application 350. The payment and
adjustment management application 350 includes the financial
institution 320 and the adjustment processing application 340.
[0053] 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 and remittance data 325 is sent
from the financial institution 320 to the adjustment processing
application 340. Order data 335 is sent from the seller to the
adjustment processing application 340. The order data 335 may be
sent to the adjustment processing application 340 when the
underlying goods are invoiced to the buyer, or may be sent to the
adjustment processing application 340 at some later time. The
posting data 345 is sent from the adjustment processing application
340 to the seller 330.
[0054] In operation, the payment processing and exception
management 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.
[0055] 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.
[0056] As mentioned above, the invoice information 305 and the
goods are received by the buyer 310. 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.
[0057] 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. Additionally, for example, some of the
goods may be damaged or destroyed. Alternatively, the agreed price
or quantity of the actual goods received may not match the price or
quantity of the goods appearing in the invoice information.
Additionally, the seller may have shipped goods other then the
goods desired by the buyer. 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 departure from the invoice
information 305.
[0058] Returning to FIG. 3, once the goods have been received by
the buyer 310, the buyer then pays for the goods by transmitting
payment information 315 to the financial institution 320. That is,
the buyer 310 submits payment information 315 including a payment
to the seller's financial institution 320. Again in some cases, the
buyer 310 may submit the payment directly to the seller 300, who
will in turn submit the payment to the financial institution 320.
However, as shown in FIG. 3, the present embodiment operates to
transform the financial institution 320 into a payment and
adjustment management application 350 by integrating the financial
institution 320 with the adjustment processing application 340.
[0059] That is, once the goods have been received by the buyer 310
or in accordance with the terms of the accompanying invoice, the
buyer then pays for the goods. However, if one or more of the
above-mentioned difficulties with the goods has occurred, the
amount that the buyer may submit as payment may differ from the
amount included in the invoice information 305. When the payment
amount submitted by the buyer 310 differs from and is less than the
payment amount included in the invoice information 305, the
difference in the payment amounts is referred to as a
deduction.
[0060] As mentioned in the background section above, when a buyer
310 takes a deduction in the typical fashion, the taking of the
deduction necessitates a great deal of work for the seller.
Typically, the seller must reconcile the payment amount received
from the buyer with the goods and invoice information that were
sent to the buyer, which may be a complicated and time-consuming
process.
[0061] In a few of the previous systems, in order to reduce the
amount of time spent reconciling the invoice information, the
seller may request that the buyer submit a debit memo in order to
allow the buyer to take a deduction, either manually or through a
web site. Managing deductions by using such a form may assist a
seller in its internal accounting, but may entail additional delay
in approval by the seller and disbursement or credit to the buyer.
Consequently, such a system is often viewed as onerous by both
buyer and seller. In other previous systems, buyers may refuse to
pay an invoice unless it is accurate, that is, unless a final
revised invoice showing all adjustments has been received by the
buyer, or a credit memo issued to offset the incorrect invoice, or
a deduction is authorized prior to payment. However, such a system
is typically viewed unfavorably by the seller because it typically
involves an additional delay for payment.
[0062] Conversely, as shown in FIG. 3, the buyer 310 submits
payment information 315 including a payment to the seller's
financial institution 320. However, as shown in FIG. 3, the present
embodiment operates to transform the financial institution 320 into
a payment and adjustment management application 350 by integrating
the financial institution 320 with the adjustment processing
application 340.
[0063] That is, the buyer's payment and remittance information 315
is sent to the financial institution 320. The payment 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 and
remittance information 315 and generates the payment and remittance
data 325. The payment and remittance data 325 preferably includes
all of the payment and remittance information and may include
additional remittance data such as scanned images of received
checks, received remittance advices, and/or debit memos. The
payment and remittance data 325 is then sent to the adjustment
processing application 340.
[0064] In addition to the payment and remittance data 325, the
adjustment processing 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 and may include
additional information.
[0065] 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.
[0066] That is, one element of the payment and remittance data 325
preferably identifies the buyer making the payment. Preferably, the
outstanding invoices have been previously sent or pre-delivered to
the adjustment processing application 340, for example at the time
the invoice was originally sent to the buyer. If the adjustment
processing application 340 is unable to find a particular invoice
for a particular seller, then the adjustment processing application
340 may default to a standard deduction form, as further described
below. Alternatively, the adjustment processing 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 adjustment processing
application 340 may preferably retrieve all outstanding invoices
for all buyers. That is, the payment and remittance data 325
preferably indicates the buyer. The adjustment processing
application 340 may then query the seller 330 for any information
related to that buyer. Additionally, the adjustment processing
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 adjustment processing 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.
[0067] 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.
[0068] 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.
[0069] Once the adjustment processing application 340 receives the
payment and remittance data 325 and the order data 335, the
adjustment processing application 340 then proceeds to attempt to
match the received payment and remittance data 325 to one or more
of the outstanding invoices retrieved from the order data 335.
[0070] As further described below with regard to FIG. 6, if the
payment data 325 is immediately matchable to one or more invoices,
the adjustment processing application 340 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 adjustment processing application
340 on an invoice-by-invoice basis, the adjustment processing
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 and/or all exceptions to the invoiced handled as
further described below. For example, the adjustment processing
application 340 may process the batch of invoices, match the
invoices that it is able to match, and then concentrate on
classifying the exceptions in the remaining invoices before passing
the entire batch of invoices to the seller as further described
below. A reviewer at the seller may then further review, modify
and/or approve/reject the exceptions.
[0071] If the payment data 325 is not immediately matchable to one
or more invoices, then the seller may be claiming an adjustment or
an error has occurred and the adjustment processing application 340
may then flag the payment data for further processing as further
described below with regard to FIG. 6.
[0072] The adjustment processing application 340 may then attempt
to apply a set of seller-configurable business rules to the payment
data in order to attempt to automatically resolve and process the
adjustment, as further described below. For example, the adjustment
processing application 340 may be configured with a set of rules
for each buyer so that adjustments below a certain threshold or
less than a certain percentage of an invoice amount are
automatically granted.
[0073] If the adjustment processing application 340 is unable to
automatically resolve the adjustment, the adjustment processing
application 340 may then generate an adjustment form. As further
described below, the adjustment form may then be classified using a
reason code configured by the seller and then routed to the
relevant human for resolution, as further described below with
regard to FIGS. 4-20. The adjustment form preferably includes all
data necessary to resolve (approve or disprove) the adjustment.
[0074] The operation of the initial invoice and payment matching is
further described in U.S. patent application Ser. No. ______ filed
______, entitled "System And Method For Automated Incoming Payment
and Invoice Reconciliation", which is incorporated herein by
reference in its entirety. Additionally, the operation of the
automated adjustment processing is further described in U.S. patent
application Ser. No. ______ filed ______, entitled "System And
Method For Automated Payment And Adjustment Processing", which is
incorporated herein by reference in its entirety.
[0075] Once the adjustment processing application 340 has processed
the payment and remittance data 325 and order data 335 and the
buyer's adjustment has been resolved, the adjustment processing
application 340 sends posting data 345 to the seller 330. As
further described below, the posting data 345 may take any of
several forms such as an instruction to create a credit memo, an
adjustment to inventory, or an instruction to forward the deduction
to collections.
[0076] 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.
[0077] 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 adjustment
management. Although the current description focuses on goods, the
present payment processing and exception management system applies
equally well to services and is not limited to goods.
[0078] 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 ship 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 may include an invoice number to be used by the seller 330 for
identification and tracking purposes. For example, the invoice
information 305 may include an invoice number so that the seller
330 may be able to track which goods and/or services have been
delivered or provided to buyer 310. In addition, the invoice
information 305 may also include a bill of lading and/or other
documentation such as the freight bill, proof of delivery, and/or
price quote.
[0079] 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.
[0080] Further to the discussion above, the payment and remittance
data are preferably constructed by the financial institution 320 to
the extent that the payment data and/or remittance information is
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
data relating to the check. For example, the financial institution
320 may electronically note the date of receipt, amount, payer,
payee, and any account, MICR, or invoice numbers on the check. The
financial institution may also electronically image the received
check, remittance information, and debit memo. The notations made
by the financial institution 320 may then be passed to the
adjustment management application as part of the payment and
remittance data 325.
[0081] 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 may then be passed to the adjustment processing
application 340 as part of the payment and remittance data.
[0082] The payment and remittance data itself may take any of a
wide variety of forms as selected by the financial institution 320.
For example, the payment and remittance 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.
[0083] 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.
[0084] Additionally, the adjustment processing 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 adjustment
processing application 340 may be directly hosted by the financial
institution 320, the seller 330 or a third party. The actual
physical location of the adjustment processing application 340 is
not relevant as long as it remains in communication with the
financial institution 320 and the seller 330. For example, the
adjustment processing application 340 may be hosted or installed at
the financial institution, installed at a third party or may be
otherwise outsourced.
[0085] FIG. 4 illustrates an embodiment of the adjustment
processing application 340 of FIG. 3 in greater detail. As shown in
FIG. 4, the adjustment processing application 340 includes a
business data filter 410, an adjustment document creator 420, and a
workflow approval processor 430. As discussed above with regard to
FIG. 3, the deduction management application 340 receives the
payment and remittance data 325 from the financial institution 320
and the order data 335 from the seller 330. The payment and
remittance data 325 and order data 335 are then passed to the
business data filter 410 of the adjustment processing application
340.
[0086] In operation, the business data filter 410 receives the
order data 335 and the payment and remittance data 325 and attempts
to match the payment and remittance data 325 with one or more
invoices included in the order data. If the business data filter
410 is able to match the payment and remittance data 325 with one
or more invoices in the order data 335, the business data filter
sends posting data 345 to the seller 330 to close out the
transaction, as described above. If the business data filter 410 is
not able to match the payment and remittance data 325 with one or
more invoices in the order data 335, then the payment and
remittance data 325 is further processed by the business data
filter as described below with regard to FIG. 6.
[0087] The business data filter 410 then applies a series of
business rules in order to attempt to match the order data 335 and
the payment and remittance data 325, as further described below
with regard to FIG. 6. If the business data filter 410 is able to
find a match after the application of the business rules, then the
business data filter 410 sends posting data 345 to the seller 330.
The business rules applied by the business data filter may
preferably be configured to be buyer specific, as further described
below.
[0088] However, if the business data filter 410 is still not able
to match the payment data to one or more invoices after the
application of the buyer-specific business rules, the business data
filter 410 sends the payment and remittance data 325 to the
adjustment document creator. An adjustment document 425 is then
created at the adjustment document creator 420. Posting data 345 is
also sent to the seller 330 by the adjustment document creator 420
to alert the seller's accounting system that a payment has been
made and an adjustment document has been created.
[0089] The assembled adjustment document 425 is sent to the
workflow approval processor 430. The workflow approval processor
430 routes the adjustment document 425 to a predetermined and
customizable set of human reviewers at the seller 330 for review
and/or approval. The structure of the adjustment approval forms and
the routing of the approval forms are further described below with
regard to FIGS. 8-20. If the adjustment document is approved by the
set of human reviewers, then the workflow approval processor sends
the additional posting data to the seller 330. However, if the
adjustment document is not approved by the set of human reviewers,
the seller 330 may instead forward the adjustment document to
collections for further action.
[0090] As further described below with regard to FIG. 7, the
adjustment document 425 preferably includes the payment data as
well as all relevant data with regard to the buyer. The relevant
data with regard to the buyer preferably includes the buyer's
previous purchasing and payment activity including any credit
rating, as well as seller-side information with regard to the buyer
such as the seller's account representative for the buyer or any
previous discounts given to the buyer.
[0091] The business data filter 410 may also seek to validate
payment data when the buyer's information is missing from the
transaction. For example, if the payment data does not include an
indication of the buyer, the business data filer 410 may attempt to
match the payment amount or any other available information to all
outstanding invoices for all buyers. If a match is discovered, the
business data filter 410 may automatically. prompt the user to
confirm the attempted match from secondary criteria, for example,
non-invoice identification fields.
[0092] Preferably, the transaction verification provided by the
business rules includes the validation of the following aspects of
the transaction. Validation of the customer information of the
buyer 310. Validation of the delivery information of the goods
transferred to the buyer, preferably including, for example, the
invoice and/or bill of lading, and the dollar amounts. Validation
of the buyer's payment such as determining whether the buyer's
payment is a duplicate of an already received payment or if the
amount remitted by buyer differs from the invoiced amount by a sum
less than a predetermined threshold tolerance, or if the total
invoice amount is less then a predetermined amount.
[0093] 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 remittance information 315, as
described in FIG. 3 as well as other information. The payment data
325 may be configured in any internal format desired by the
financial institution that is capable of being parsed by the
adjustment processing application 340.
[0094] 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. Additionally, prior art
methodologies for matching payment data with invoice data did not
automatically integrate the matching with the seller's financial
institution.
[0095] FIG. 6 illustrates a flowchart 600 of the operation of the
adjustment management application in greater detail. First, the
payment data and the order data are received at steps 601-602.
Next, at step 605, the payment data received and aggregated for the
customer by the financial institution. That is, the financial
institution may accumulate a number of payments in a deposit 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.
Alternatively, the payments may be processed individually rather
than as a batch.
[0096] At step 610, each payment in the batch of payments is
evaluated. Preferably, the payment data 601 includes invoice
information 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 602. At step 615, 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 630 and the invoice is matched to the
payment. If no invoice number match is found, the process proceeds
to step 620.
[0097] At step 620, several alternatives are presented to the
seller in order to allow the seller to apply the payment data to
one or more of the buyer's outstanding invoices. Throughout the
flowchart 600, process steps enclosed in a box with a slanted top
indicate actions taken by the seller, as opposed to actions that
take place automatically in the system. At step 620, the seller may
take one of several actions that correspond to the reason that the
payment data did not match with an invoice number. First, the
payment data may not have matched with an invoice number because
the payment data includes an error, such as an error in the invoice
number. In this case, the data may be corrected at step 625 to
allow the invoice number in the payment data to match one of the
outstanding invoice numbers. The process may then proceed to step
630. Alternatively, the payment data may be split among more than
one invoices at step 626 and the process may then proceed to step
630. Alternatively, if the seller determines that the payment
received from the buyer is a pre-payment at step 627, then the
process proceeds to step 660.
[0098] At step 630, the received payment has been matched to a
specific invoice. Next, at step 632, 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 635. At step 635, the payment is marked for posting to the
seller's accounting system.
[0099] Conversely, if the received payment does not match the
invoiced payment, the process proceeds to step 640. At step 640,
business rules are applied in order to allow the payment to "match"
the invoice even if the payment amount is not exactly the invoiced
amount. For example, a global threshold may be set for the system
so that even if the received payment differs from the invoiced
payment amount, if the difference is small enough then the invoice
and payment still are considered a match. For example, as a global
threshold, if the received payment differs from the invoices amount
by less than 1% or is less than $100, the invoice and payment may
still be considered to match. The global threshold is preferably
set by the seller.
[0100] In addition to global business rules that may be applied to
all buyers, buyer-specific business rules may be applied. For
example, a buyer-specific threshold that is more generous than the
global threshold may be employed instead of the global threshold in
order to allow the received payment and the invoice to match. For
example, the seller may configure a buyer-specific threshold of 2%
or $500 and as long as the payment received does not differ from
the invoiced amount by more than the buyer-specific threshold, the
payment is considered to match the invoice. Additionally, other
buyer-specific criteria such as discount payment terms or other
incentive may be applied.
[0101] The business rules including the global and buyer-specific
thresholds may be retrieved from the seller as part of the order
data at step 602. Alternatively, the business rules may be
retrieved from the seller when the process proceeds to step 640. As
another alternative, the business rules may be stored in the
adjustment management application and may be available to the
seller for periodic updates. All of the business rules are
preferably configurable by the seller.
[0102] Turning now to step 642, if the payment amount matches the
invoiced amount after the application of the business rules, the
process proceeds to step 650. At step 650, a G/L (General Ledger)
adjustment record is created to credit the difference between the
invoices payment and the received payment. The process then
proceeds to step 635 and the payment is marked for posting. Once
the payment is marked for posting, the posting data is transmitted
to the seller at step 690.
[0103] However, if the payment amount does not match the invoiced
amount after the application of the business rules at step 642, the
process proceeds to step 643. At step 643, the payment amount is
examined to determine whether the received payment represents a
partial payment. If the received payment represents a partial
payment, the process proceeds to step 655 and an adjustment to the
A/R is made. The process then proceeds to step 635 and the payment
is marked for posting.
[0104] Conversely, if the received payment does not represent a
partial payment, the process proceeds to step 660 and an adjustment
form, such as a deduction form is created. The creation and
processing of the adjustment form is further described in FIG. 22.
The process then proceeds to step 655 and an adjustment to the A/R
is made. The process then proceeds to step 635 and the payment is
marked for posting as described above.
[0105] FIG. 22 illustrates a flowchart 2200 of an embodiment of the
procedure for processing an adjustment form. Similar to FIG. 6,
throughout the flowchart 2200, process steps enclosed in a box with
a slanted top indicate actions taken by the seller, as opposed to
actions that take place automatically in the system. First, at step
2201, an adjustment form such as a deduction form is created.
Several examples of adjustment forms are shown in FIGS. 9-19 below.
As further explained below, several different types of adjustment
forms are provided based on the specific adjustment desired by the
buyer. When the adjustment form is created, the adjustment form is
preferably populated with all available data that may be relevant
to the adjustment. For example, the adjustment form preferably
includes the payment data pertaining to the received payment as
well as the order data pertaining to the specific buyer and
invoice.
[0106] Returning to step 2201, once the adjustment or deduction
form has been created, the deduction form is then routed according
to a seller-configured workflow 2205. For example, a specific
adjustment may be routed to one set of reviewers at the seller
while another adjustment may be routed to another set of reviewers
at the seller. For example, adjustments may be routed based on the
size of the adjustment, the buyer taking the adjustment, and/or the
total outstanding adjustment amount for the specific buyer as well
as other factors as explained further below with regard to FIG.
20.
[0107] The adjustment form is received by a reviewer at step 2210
and evaluated. The process then proceeds to step 2215. At step
2215, the reviewer may add notes or statements to the deduction
form. Next, at step 2220, the reviewer may determine whether
additional supporting documentation is needed. If additional
supporting documentation is needed, the process proceeds to step
2225 and the supporting documentation is attached. After the
supporting documentation has been attached or if no documentation
is needed, the process proceeds to step 2230.
[0108] At step 2203, it is determined whether further review is
needed. The determination of whether further review is needed may
be automated or driven by a reviewer. For example, a reviewer may
determine that further review is needed and choose to route the
deduction document to another reviewer for review. In this case the
process proceeds back to step 2205 and the deduction form is routed
to a new reviewer.
[0109] Additionally, the process may automatically determine
whether an additional reviewer is needed. For example, the workflow
for the approval of a specific deduction document may indicate that
the deduction document must pass through two or more reviewers. In
this case, after the first reviewer has completed their review, the
deduction document is automatically routed to the next reviewer for
review and the process proceeds back to step 2205. The adjustment
form may be routed sequentially or in parallel, as further
described below with regard to FIG. 20.
[0110] A reviewer may choose one of three options with regard to a
deduction form. That is, the deduction form may be fully approved,
partially approved, or not approved. First, at step 2204, the
process determines whether the deduction has been partially
approved. If the deduction has been partially approved, an
adjustment record is created for the approved deduction amount at
step 2250. Next, at step 2260, data is transmitted to the seller
indicating that the deduction has been partially approved and the
amount of the approval. Additionally, at step 2250, the unapproved
portion of the deduction form is forward to collection.
[0111] If the deduction has not been partially approved, the
process proceeds to step 2245. At step 2245, the process determines
whether the deduction is either fully approved or fully rejected.
If the deduction is rejected, the process proceeds to step 2250 and
the deduction is forwarded to collections for further action. If
the deduction is fully approved, the process proceeds to step 2250,
as above, and adjustment document is created for the deduction and
send to the seller at step 2260.
[0112] FIG. 7 illustrates an example of the buyer-specific
information that may be received by the adjustment document creator
to allow the adjustment document creator to create and route the
adjustment document. The adjustment document creator 420 preferably
receives customer information 710, a workflow participants list
720, applicable sales information 730, and adjustment information
740 to create the adjustment document 425.
[0113] As illustrated, the adjustment document creator 420 creates
the adjustment document 425 by collecting, compiling, and
re-formatting several items of information from the various
information sources 710-740. For example, the customer information
710 may include information about buyer 310, including buyer's 310
name, business, and contact information. The adjustment information
740 includes any data or information on any debits or credits that
the seller 330 or the financial institution 320 may have in the
buyer's 310 name.
[0114] The workflow participants list 720 is a list of various
reviewers who may be required to review the adjustment document 425
as further described below. The workflow participants list 720 is
preferably highly customizable by the seller 330 in order to match
the workflow of the adjustment document to the internal
business/accounts receivable structure of the seller.
[0115] In this way, the seller 330 may customize the workflow
participants list 720 in order to ensure that the proper reviewers
review the adjustment document 425. For example, the seller 330 who
has sold goods to a buyer on a line of credit may likely desire
that a credit analyst review the adjustment document 425. In a more
complex example, the seller 330 may desire that several reviewers
review the adjustment document 425, including the credit
department, the accounting department, the operations department,
the account representative, the Chief Financial Officer, the sales
department, and/or the transportation department. Therefore, the
seller 330 may customize the workflow participants list 720 to
ensure that all of these reviewers receive the adjustment document
425. Additional examples of workflow configuration include by
customer, by reason code and by dollar amount.
[0116] Additionally, the adjustment document 425 may be sent to the
reviewers either simultaneously or sequentially. That is, in one
embodiment, the adjustment document 425 proceeds one reviewer at a
time with only a single reviewer considering the sales document at
one time. The next reviewer is only provided with the adjustment
document when the previous reviewer has finished with the document.
For example, the adjustment document may travel sequentially
through the reviewers via e-mail.
[0117] In another embodiment, all of the designated reviewers may
be provided with access to the adjustment document 425 at the same
time. For example, the adjustment document 425 may be available at
a centralized location such as a web page, for example. As each
reviewer reviews the document, the reviewer may indicate changes or
actions taken on the website.
[0118] Turning now to the information supplied to the adjustment
document creator 420 from the applicable sales information
repository 730, the applicable sales information 730 preferably
includes all applicable information from the payment data 325,
including the invoice, the sales order, the bill of lading, the
purchase order, and buyer's 310 check as further illustrated below
with regard to FIG. 8. Depending on the type of adjustment document
425, however, the applicable sales information 730 may comprise
more or less information. For example, if the goods were not
delivered to buyer 310 by the seller 330, it is unlikely that a
bill of lading may exist to include in the applicable sales
information 730. Therefore, the applicable sales information 730
(and, correspondingly, the adjustment document 425) may not include
the bill of lading.
[0119] Additionally, the adjustment document creator preferably
generates several different types of adjustment documents depending
upon the actual adjustment that is to occur, as further described
below. Depending upon the specific type of adjustment document to
be created, different types and quantities of information from the
various databases are incorporated into the adjustment
document.
[0120] FIG. 8 illustrates a variety of exemplary documents and
other items for incorporation into the adjustment document 425. As
shown in FIG. 8, the adjustment document 425 may include
information from or scanned copies of a freight bill 810, a check
820, an invoice 830, miscellaneous supporting documents 840, proof
of delivery 850, a customer quote 860, and a bill of lading 870.
The freight bill 810 may be an electronic image of the freight bill
used for delivery of the goods purchased by buyer 310. The check
820 may be an electronic image of buyer's 310 payment for the
goods. The check 820 may be any evidence of a payment, including
electronic images of 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. The invoice 830 may be an electronic
image of the invoice used in the sale of goods to buyer 310. The
miscellaneous supporting documents 840 may include any electronic
data or images of any documents used to sell and transfer the goods
from the seller 330 to buyer 310. This includes correspondence from
either the seller 330 or buyer 310. The proof of delivery 850 may
be an electronic image of any documents that prove that the goods
were delivered to buyer 310. The customer quote 860 may be an
electronic image or other electronic representation of any document
that contains a quote by the seller 330 for the sale of goods
and/or services to buyer 310. The bill of lading 870 may be an
electronic image of the bill of lading used in the delivery of the
goods to buyer 310.
[0121] Any of the various items of information may be provided in
any of a variety of ways including links to electronic copies of
the documents, links to scanned copies of the documents, or any
other type of document outsourcing.
[0122] As mentioned above, FIG. 8 is merely exemplary of the
documents that may be incorporated into the adjustment document.
Additional document or fewer than all of the illustrated documents
may be employed.
[0123] Returning to FIG. 7, as was discussed above, the adjustment
document creator preferably generates several different types of
adjustment documents depending upon the actual adjustment that is
to occur. FIGS. 9-19 illustrate several exemplary adjustment
documents that may be employed in several differing situations. As
stated above, the information contained in each of the exemplary
adjustment documents of FIG. 9-19 may be seller-configurable and
the documents themselves may also be seller-configurable.
[0124] Additionally, although the adjustment document creator may
determine an initial adjustment document for use by the set of one
or more human reviewers, the human reviewer may choose to override
the adjustment document creator's selection and use a different
adjustment form. The initial determination may be based on data
supplied by the buyer such as a deduction code or reason code as
contained within a vendor compliance manual or it maybe simply be a
default setting as configured by the seller. All information and/or
scanned images may be directly transferred from each of the
adjustment documents to any of the other adjustment documents.
[0125] As mentioned above, the present system preferably recognizes
the type of adjustment by evaluating reason codes provided by the
seller using a variety of options. Additionally, a default code may
be designated by the seller so that the default adjustment may be
an advertising issue, for example. Alternatively, the present
system may be configured so that all adjustments must be
individually coded by the seller at the time of creation of the
adjustment form.
[0126] FIG. 9 illustrates an exemplary customer compliance form 900
type of adjustment document 425. The customer compliance form 900
includes a title 910, initiator information 915, reviewer
information 920, customer information 925, salesman information and
credit analyst information 930, transaction information 935, an
adjustment chart 940, a G/L Code 945, an Inventory Records Affected
indicator 950, a CM Payment Term 955, a Reason for Non-Compliance
Indicator 960, a hyperlink to additional attachments 965,
adjustment notes 970, a history of adjustment notes 975, and a
status indicator for each reviewer 980 which may be employed as an
audit trail of the workflow processor.
[0127] The title 910 includes information such as buyer's 310 name,
an adjustment form type identifier, a reason code, a status
indicator, an adjustment number, a dispute flag, and a last action
date. The status indicator is an indication of "unresolved,"
"resolved," "collected," or "not collected", for example The status
indicator is used to indicate the current status of the adjustment
request. In this way, the adjustment document 425 may have a status
indicator of "unresolved" when the adjustment request has not been
resolved. Conversely, the adjustment document 425 may have a status
indicator of "resolved" when the adjustment request has been
resolved. In addition, the adjustment document 425 may have a
status indicator of "collected" when the money owed by buyer 310 to
the seller 330 has been collected. Conversely, the adjustment
document 425 may have a status indicator of "not collected" when
the money owed by buyer 310 to the seller 330 has not been
collected. Additional status indicators may include "partially
approved" when a reviewer has partially approved the deduction and
"opened" when the deduction form has been created, but the
deduction has not yet been resolved.
[0128] The adjustment number of the title of the customer
compliance form example 900 of an adjustment document 425 is a
number used to identify the adjustment document 425. For example,
buyer 310 may have several adjustment requests currently pending
with the seller 330. In order for the seller 330 to adequately
monitor all of the pending adjustment requests, all of the pending
adjustment requests are listed in a separate adjustment document
425 and identified by separate adjustment numbers. Alternatively,
more than one adjustment request may be contained within a single
adjustment, document 425.
[0129] The reason code of the title of the customer compliance form
example 900 of an adjustment document 425 is an indicator of the
cause of the adjustment request. In this way, a letter or number or
combination of several numbers and/or letters may be used to
quickly identify the cause of the adjustment request. For example,
the seller 330 may have the following reason codes:
1 Reason Code Reason for Adjustment Request 1 Customer compliance 2
Damage 3 Freight 4 Marketing 5 Miscellaneous 6 Discount 7 Price 8
Quantity 9 Return 10 Tax 11 Warranty
[0130] Additionally, the dispute flag may be used as an indication
as to whether or not the adjustment document has been resolved. The
dispute flag `on` may mean there has not been a decision on the
adjustment. The dispute flag `off` may mean that a decision has
been made (decision meaning approval or denial of the
adjustment).
[0131] The last action date of the title of the customer compliance
form example 900 of an adjustment document 425 is the date on which
the adjustment request was last acted upon. For example, if the
last action taken on the adjustment request was a reviewer
reclassifying the adjustment document 425 on April 15, then the
last action date may indicate the last action taken (i.e., a
reclassification of the adjustment document 425) and the date
(i.e., April 15).
[0132] The initiator information of the customer compliance form
example 900 of an adjustment document 425 is information relating
to the party who initiated the adjustment request. For example, if
a credit analyst initiated the adjustment request, then information
about the credit analyst may be listed as initiator
information.
[0133] The reviewer information of the customer compliance form
example 900 of an adjustment document 425 is information relating
to the reviewer who reviewed the adjustment document 425. For
example, if a credit analyst reviewed the adjustment document 425,
then information about the credit analyst may be listed as reviewer
information.
[0134] The customer information of the customer compliance form
example 900 of an adjustment document 425 is information relating
to buyer 310. The salesman information of the customer compliance
form example 900 of an adjustment document 425 is information
relating to the salesman who sold the goods and/or services to
buyer 310. The credit analyst information of the customer
compliance form example 900 of an adjustment document 425 is
information relating to the credit analyst who may or may not have
reviewed the adjustment document 425 depending on the workflow.
[0135] The transaction information 935 includes a reference number,
an invoice number, an order number, a debit date, a check
identification, an invoice total, a deduction or payment amount, a
total percentage amount, and several hyperlinks to electronic
images. Various configurations of the transaction information are
employed in the several embodiments of the sales adjustment forms
in the following figures. Additionally, the transaction information
section may be configured to be dynamically expandable. For
example, a reviewer may wish to add additional information to the
transaction information section before passing the adjustment
request to the next reviewer. Thus, the transaction information 935
may be expanded to include line item invoice information such as
production, price or quantity, for example, or any other desired
information.
[0136] The reference number of the customer compliance form example
900 of an adjustment document 425 is a number used to identify the
adjustment request. In this way, each adjustment request may be
easily identified and monitored, even when a single buyer 310 has
several pending adjustment requests. For example, buyer 310 may
have several adjustment requests currently pending with the seller
330. Alternatively, each independent adjustment request may be
assigned a different reference number to easily identify that
adjustment request.
[0137] The invoice number of the customer compliance form example
900 of an adjustment document 425 is a number used to identify the
invoice information 305, discussed above in FIG. 3.
[0138] The order number of the customer compliance form example 900
of an adjustment document 425 is a number used to identify the
order of goods and/or services. For example, a seller 330 may track
a sale to a buyer 310 by an order number. In this way, the seller
330 may reference this order by the order number in the customer
compliance form example 900. Additionally, each invoice number is
preferably associated with a single order number and that field
should populate itself once the invoice number is identified.
[0139] The debit date of the customer compliance form example 900
of an adjustment document 425 is the date on which a debit has been
posted for the goods and/or services sold by the seller 330 to
buyer 310.
[0140] The check identification of the customer compliance form
example 900 of an adjustment document 425 is a number used to
identify the check or electronic payment number used by buyer 310
in purchasing the goods and/or services from the seller 330. That
is, the check identification is typically a financial institution
reference.
[0141] The invoice total of the customer compliance form example
900 of an adjustment document 425 is the amount buyer 310 must pay
as listed in the invoice information 305. For example, if the
invoice information 305 indicates that buyer 310 owes $500 for
goods listed in the invoice, then the invoice total is $500.
[0142] The deduction or payment amount of the customer compliance
form example 900 of an adjustment document 425 is the amount buyer
310 is requesting for an adjustment. In this way, the amount that
buyer 310 claims that the invoice amount should be deducted or the
amount that buyer 310 claims that he or she has overpaid is the
deduction or payment amount.
[0143] The total percentage amount of the customer compliance form
example 900 of an adjustment document 425 is the percentage of the
invoice total that the deduction or payment amount is. For example,
if the deduction or payment amount is $100, and the invoice total
is $500, then the total percentage amount is 20%.
[0144] The several hyperlinks to electronic images of the customer
compliance form example 900 of an adjustment document 425 are
electronic hyperlinks to images of various supporting documents.
For example, the several hyperlinks to electronic images may
include an electronic link to an electronic image of buyer's 310
check. In addition, the several hyperlinks to electronic images may
include an electronic link to an electronic image of the invoice or
alternatively a website of buyer for remittance information.
[0145] The adjustment chart of the customer compliance form example
900 of an adjustment document 425 is a chart that includes a total
adjustment, an approved adjustment, a denied adjustment, a check
number, a batch number, and a debit memo number. The total
adjustment is the total amount of the adjustment requested in the
adjustment request. For example, if buyer 310 is requesting a
deduction in the invoice amount of $300, then the total adjustment
is $300. The approved adjustment is the amount of the adjustment
that is approved by the reviewer in the deduction management
application 340. The denied adjustment is the amount of the
adjustment that is denied by the reviewer in the deduction
management application 340. The check number is the number of
buyer's 310 check in which the adjustment occurred. The batch
number is a number used by a seller 330 to identify receipt of
payment date.
[0146] The debit memo number is the number assigned for that
specific deduction or adjustment. That is, when the seller contacts
the buyer for a copy of the debit memo, the seller requests a copy
by referencing the debit memo number.
[0147] The G/L Alpha Code of the customer compliance form example
900 of an adjustment document 425 is a general ledger code. The
general ledger code is a code which is customizable by the seller
330. The G/L code represents where the money to create the credit
memo (pending approval) will come from. The G/L code is the
accrual. The G/L code need not be designated as alpha.
Additionally, the G/L code may be an alphabetic identification, a
numeric identification, or a combination of alphabetic and numeric
identifications.
[0148] The Inventory Records Affected indicator of the of the
customer compliance form example 900 of an adjustment document 425
is an indication of the effect the adjustment request may have on
the seller's 330 inventory. In this way, if the adjustment request
causes the seller's 330 inventory to be greater by 1000 units, the
Inventory Records Affected indicator may have a value of 1000
units. In addition, if the adjustment request has no effect on the
seller's 330 inventory, the Inventory Records Affected indicator
may have a value of "Non Inventory," indicating that there is to be
no change to the seller's 330 inventory.
[0149] The CM Payment Term of the customer compliance form example
900 of an adjustment document 425 is an amount of time before full
payment of the invoice amount is due from buyer 310. For example,
if the CM Payment Term is 60 days, then buyer 310 must render full
payment of the invoice amount within 60 days. Alternatively, since
an adjustment form has been created, the terms for full payment of
the invoice may no longer be relevant.
[0150] The Reason for Non-Compliance Indicator of the customer
compliance form example 900 of an adjustment document 425 is an
indication of why buyer 310 is requesting the adjustment request.
The indicator is preferably configurable by the customer and may
even be dynamic so as to be adjusted by a reviewer on-the-fly. For
example, if buyer 310 is requesting an adjustment for a transaction
because the goods were late, the seller 330 may create a Reason for
Non-Compliance Indicator of "late shipment." Non-compliance
preferable describes a situation in which the seller did not meet
the buyer's requirements, for example shipping, bar coding,
packaging or other requirements. Alternatively, the Reason for
Non-Compliance Indicator may be represented as varying alphanumeric
codes to designate a wide variety of causes for the adjustment
request.
[0151] The hyperlink to additional attachments of the customer
compliance form example 900 of an adjustment document 425 is an
electronic hyperlink to any electronic images of relevant
documentation. For example, if the several hyperlinks to electronic
images contain hyperlinks to electronic images to buyer's 310
check, the invoice, and the bill of lading, but do not contain a
hyperlink to an electronic image of a customer quote, the hyperlink
to additional attachments may contain a hyperlink to an electronic
image of the customer quote. Alternatively, additional attachments
may be used for attaching scanned documents that may not be offered
via hyperlink. The field also allows for data from other systems to
be copied and pasted here. The hyperlinks may be configured to
direct a user to any desired type of information.
[0152] The adjustment notes of the customer compliance form example
900 of an adjustment document 425 are annotations to the adjustment
document 425. In this way, a seller 330 may annotate sales records
while processing deductions represented by the adjustment document
425. In addition, the adjustment notes allow a seller 330 to insert
relevant documentation, such as excerpts from email or other
information, into the adjustment document 425.
[0153] The history of adjustment notes is a compilation of past
adjustment notes. In this way, anytime a seller 330 inputs
adjustment notes into an adjustment document 425, the past notes
are saved in the history of notes.
[0154] The status indicator for each reviewer of the customer
compliance form example 900 of an adjustment document 425 is an
indication for each reviewer's resolution of the adjustment
request. In this way, every reviewer that reviews the adjustment
document 425 and either approves or denies the adjustment document
425 may include his or her approval in the status indicator. For
example, if a credit analyst reviews the adjustment document 425
and approves the adjustment document 425, the status indicator for
the credit analyst may state "approved." Conversely, if another
reviewer denies the adjustment document 425, his or her status
indicator may state "denied." In addition, if a reviewer has not
yet reviewed the adjustment document 425, his or her status
indicator may state "pending." Additionally, an option to change
reviewers may be added. For example, the credit analyst may not be
a reviewer for a specific deduction depending on the workflow.
[0155] FIG. 10 illustrates a Damage Form example 1000 of an
adjustment document 425. The Damage Form example 1000 of an
adjustment document 425 includes many of the same items as the
customer compliance form example 900 of FIG. 9. For example, the
Damage Form example 1000 includes a title 1010, initiator
information 1015, reviewer information 1020, customer information
1025, salesman information and credit analyst information 1030,
transaction information 1035, a multi-transaction chart 1037, an
adjustment chart 1040, an Inventory Records Affected indicator
1050, a CM Payment Term 1055, a hyperlink to additional attachments
1065, adjustment notes 1070, a history of adjustment notes 1075,
and a status indicator for each reviewer 1080.
[0156] In the Damage Form 1000, all of the elements are similar to
the form 900 of FIG. 9 except for the transaction information 1035,
multi-transaction chart 1037, and additional attachments 1065.
[0157] The transaction information 1035 includes a reference
number, an invoice number, an invoice date, an order number, an
order total, the invoice terms, a purchase order number, a ship
date, a first product identification area including a product
identification, the cost per unit, the quantity billed and paid, a
second product identification area including product
identification, the cost per unit, the quantity billed and paid, a
deduction amount, a total percentage amount, several hyperlinks to
electronic images. The transaction information may be used to keep
track of the actual items that were recorded as damaged by the
buyer, as well as other information relating to the shipping of the
items such as the original purchase order and the ship date, for
example, is damaged during shipping. Additionally, multiple
products may be individually itemized with regard to damage, as
shown in FIG. 10. Although only two products are individually
itemized in the form 1000 of FIG. 10, the form 1000 may be
customized to show any number of products.
[0158] Additionally, the 1035 fields are preferably always shown to
be available for population. However, if the damaged product does
not reference a specific invoice/order then those fields remain
blank. Often, the majority of damaged product is directly from the
buyer's inventory and there may be no way to determine the specific
invoice/order it came from. When this is the case, the populated
form preferably includes product, amount per unit, and quantity. As
mentioned above with regard to the form of FIG. 9, the transaction
information 1035 is easily configurable by the user, preferably
dynamically.
[0159] The damage chart 1037 includes a listing of the adjustments
for up to the 10 separate damaged goods claims. Although the
example of FIG. 10 includes us to 10 claims, the form of FIG. 10
may be easily expanded by the user to include any number of claims.
The chart includes the amount of the requested deduction, the GL
code of the requested deduction and the year. The amount of
deduction desired in the present form 1000 is shown in the first
column of the chart.
[0160] The additional attachments 1065 section of the form 1000 has
been supplemented to include a customer quote section.
[0161] FIG. 11 illustrates a Discount Form example 1100 of an
adjustment document 425. The Discount Form example 1100 of an
adjustment document 425 includes many of the same items as the
customer compliance form example 900 of FIG. 9. For example, the
Discount Form example 1100 includes a title 1110, initiator
information 1115, reviewer information 1120, customer information
1125, salesman information and credit analyst information 1130,
transaction information 1135, an adjustment chart 1140, a G/L Alpha
code 1145, an Inventory Records Affected indicator 1150, a CM
Payment Term 1155, a hyperlink to additional attachments 1165,
adjustment notes 1170, a history of adjustment notes 1175, and a
status indicator for each reviewer 1180.
[0162] In the Discount Form 1100, all of the elements are similar
to the form 900 of FIG. 9 except for the transaction information
1135 and additional attachments 1165. As discussed above with
regard to FIG. 9, the additional attachments 1165 are highly
configurable by the user.
[0163] The transaction information 1135 includes a reference
number, an invoice number, an invoice date, an order number, an
order total, the invoice terms, a purchase order number, a
deduction amount, a total percentage amount, and several hyperlinks
to electronic images. The transaction information 1135 shows the
discount given in the original terms of the order and matches the
original discount to the invoiced amount as a deduction. The
discount may then be approved by the reviewers. Additionally, the
10 fields in section 1135 may be used for multiple discounts on one
adjustment.
[0164] The additional attachments 1165 includes a link to a price
approval. Preferably, before granting a discount, the salesperson
received approval to grant the discount from a manager. Such a
written price approval may be scanned and included in the form
1100.
[0165] FIG. 12 illustrates a Freight Form example 1200 of an
adjustment document 425. The Freight Form example 1200 of an
adjustment document 425 includes many of the same items as the
customer compliance form example 900 of FIG. 9. For example, the
Freight Form example 1200 includes a title 1210, initiator
information 1215, reviewer information 1220, customer information
1225, salesman information and credit analyst information 1230,
transaction information 1235, an adjustment chart 1240, a G/L Alpha
code 1245, an Inventory Records Affected indicator 1250, a Freight
Term 1255, a hyperlink to additional attachments 1265, Adjustment
notes 1270, a history of adjustment notes 1275, and a status
indicator for each reviewer 1280.
[0166] In the Freight Form 1200, all of the elements are similar to
the form 900 of FIG. 9 except for the transaction information 1235,
a Freight Term 1255, and additional attachments 1265. As discussed
above with regard to FIG. 9, the additional attachments are highly
configurable by the user.
[0167] The transaction information 1235 includes a reference
number, an invoice number, an invoice date, an order number, an
invoice total, the freight terms, the billed amount (freight), the
paid freight amount, a purchase order number, a deduction amount, a
total percentage amount, and several hyperlinks to electronic
images. The transaction information 1235 also shows the actual
percent of the invoice that was deducted as "Total %". The second
column of the transaction information 1235 may be used to deny a
portion of the claimed deduction while still allowing a portion of
the claimed deduction to be reviewed for approval.
[0168] The actual freight terms for this order are included in the
1235 section. The freight terms in section 1255 represent the terms
of the customer set up in their customer master. Often different
products ship using different methods. That is why section 1235
preferably shows the true representation of the freight terms on
that specific shipment.
[0169] The additional attachments 1265 includes a link to get a
customer quote for freight. The quote may be imaged and attached to
the document.
[0170] FIG. 13 illustrates a Marketing Form example 1300 of an
adjustment document 425. The Marketing Form example 1300 of an
adjustment document 425 includes many of the same items as the
customer compliance form example 900 of FIG. 9. For example, the
Marketing Form example 1300 includes a title 1310, initiator
information 1315, reviewer information 1320, customer information
1325, salesman information and credit analyst information 1330,
transaction information 1335, a multi-transaction chart 1337, an
adjustment chart 1340, a Promo code 1345, an Inventory Records
Affected indicator 1350, a Marketing Comments indicator 1355, a
hyperlink to additional attachments 1365, adjustment notes 1370, a
history of adjustment notes 1375, and a status indicator for each
reviewer 1380.
[0171] In the Marketing Form 1300, all of the elements are similar
to the form 900 of FIG. 9 except for the transaction information
1335, multi-transactional chart 1337, promo code 1345, marketing
comments 1355, and additional attachments 1365. However, the
multi-transactional chart 1337 and additional attachments 1365 are
similar to those of FIG. 10.
[0172] The transactional information 1335 includes a reference
number, an invoice number (or debit memo number is reference here),
a debit date, a check ID, a debit total, a deduction amount, and a
total percentage amount (if a specific invoice is referenced). The
second column (or any other column) of the transaction information
1335 may be used to deny a portion of the claimed adjustment while
still allowing a portion of the claimed adjustment to be further
reviewed.
[0173] The promo code 1345 and marketing comments 1355 list the
promotional code offering the deduction. There may be more then one
promotional code offering the adjustment. That is why section 1337
has an option for up to 10 fields (to enter 10 separate promotional
codes for one specific adjustment (although section 1337 is
preferably dynamically configurable to any desired number of
fields.) The preferred meaning of `promo code` is the location on
the system in which we have the buyer's G/L codes linked to.
[0174] FIG. 14 illustrates a Miscellaneous Form example 1400 of an
adjustment document 425. The Miscellaneous Form example 1400 of an
adjustment document 425 includes many of the same items as the
customer compliance form example 900 of FIG. 9. For example, the
Miscellaneous Form example 1400 includes a title 1410, initiator
information 1415, reviewer information 1420, customer information
1425, salesman information and credit analyst information 1430,
transaction information 1435, an adjustment chart 1440, a G/L Alpha
code 1445, an Inventory Records Affected indicator 1450, a CM
Payment Terms indicator 1455, a hyperlink to additional attachments
1465, Adjustment notes 1470, a history of adjustment notes 1475,
and a status indicator for the credit analyst reviewer 1480.
[0175] In the Miscellaneous Form 1400, all of the elements are
similar to the form 900 of FIG. 9 except for the additional
attachments 1465, and credit analyst reviewer 1480. The
Miscellaneous Form 1400 may be useful for situations that are not
covered by other forms. The additional attachments 1465 includes a
price approval section for the attachment of an image of a price
approval for the miscellaneous deduction. The credit analyst
reviewer 1480 only includes a credit analyst. However, for some
sellers, the credit analyst may not be the human who reviews this
adjustment type. Alternatively, this field may be designated as the
first reviewer. For example, some sellers may have dedicated
persons who only review adjustments. Additionally, the
miscellaneous form 1400 may typically only be used temporarily, for
example, until the needed documents are received from the buyer in
order to reclassify the adjustment into another form.
[0176] FIG. 15 illustrates a Price Form example 1500 of an
adjustment document 425. The Price Form example 1500 of an
adjustment document 425 includes many of the same items as the
customer compliance form example 900 of FIG. 9. For example, the
Price Form example 1500 includes a title 1510, initiator
information 1515, reviewer information 1520, customer information
1525, salesman information and credit analyst information 1530,
transaction information 1535, an adjustment chart 1540, a G/L Alpha
code 1545, an Inventory Records Affected indicator 1550, a CM
Payment Terms indicator 1555, a hyperlink to additional attachments
1565, adjustment notes 1570, a history of adjustment notes 1575,
and a status indicator for the credit analyst reviewer 1580.
[0177] The transaction information 1535 includes a reference
number, an invoice number, an invoice date, an order number, an
invoice total, the invoice terms, a purchase order number, a ship
date, a first product identification area including a product
identification, the quantity, billed price and paid price, a second
product identification area including product identification, the
quantity, billed price and paid price, a deduction amount, a total
percentage amount, and several hyperlinks to electronic images. The
transaction information may be used to manage deductions based on
the price of the invoiced goods. Additionally, multiple products
may be individually itemized with regard to price, as shown in FIG.
15. Although only two products are individually itemized in the
form 1500 of FIG. 15, the form 1500 may be customized to show any
number of products. Additionally, the Seller may want to add a
hyperlink to imaged purchase orders. In the meantime they are
preferably scanned into the additional attachments field.
[0178] FIG. 16 illustrates a Quantity Form example 1600 of an
adjustment document 425. The Quantity Form example 1600 includes
the same information as the Damage Form example 1000 of FIG. 10.
The Quantity Form example 1600 includes a title 1610, initiator
information 1615, reviewer information 1620, customer information
1625, salesman information and credit analyst information 1630, a
transaction information section 1635 including a reference number,
an invoice number, an order number, a total percentage amount,
several hyperlinks to electronic images, an adjustment chart 1640,
a G/L alpha code indicator 1645, an Inventory Records Affected
indicator 1650, a CM Payment Term 1655, a hyperlink to additional
attachments 1665, adjustment notes 1670, a history of adjustment
notes 1675, a status indicator for each reviewer 1680, a P.O.
indicator, a ship date, a product indicator, a price per unit
indicator, a quantity billed, and a quantity paid, similar to as
described in FIG. 9.
[0179] FIG. 17 illustrates a Return Form example 1700 of an
adjustment document 425. The Return Form example 1700 includes the
same information as the Damage Form example 1000 of FIG. 10. The
Return Form example 1700 includes a title 1710, initiator
information 1715, reviewer information 1720, customer information
1725, salesman information and credit analyst information 1730, and
information section 1735 including a reference number, an invoice
number, an order number, a total percentage amount, several
hyperlinks to electronic images, an adjustment chart 1740, a G/L
alpha code indicator 1745, an Inventory Records Affected indicator
1750, a CM Payment Term 1755, a hyperlink to additional attachments
1765, adjustment notes 1770, a history of adjustment notes 1775, a
status indicator for each reviewer 1780, a P.O. indicator, a ship
date, a product indicator, a price per unit indicator, a quantity
billed, and a quantity paid, similar to as described in FIG. 9.
[0180] Alternatively, the Return Form 1700 may also include a field
for a RGA number. For example, when returns occur, the buyer
typically requests an RGA from the seller and then references that
number when the buyer deducts for the return. Also, a return may
not always be specific to an invoice.
[0181] FIG. 18 illustrates a Tax Form example 1800 of an adjustment
document 425. The Tax Form example 1800 includes much of the same
information as the customer compliance form example 900, such as a
title 1810, initiator information 1815, reviewer information 1820,
customer information 1825, salesman information and credit analyst
information 1830, an information section 1835 including a reference
number, an invoice number, an order number, a debit date, a check
identification, an invoice total, a deduction or payment amount, a
total percentage amount, several hyperlinks to electronic images,
an adjustment chart 1840, a G/L Alpha Code 1845, an Inventory
Records Affected indicator 1850, a CM Payment Term 1855, a
hyperlink to additional attachments 1860, a hyperlink to a freight
claim 1865, adjustment notes 1870, a history of adjustment notes
1875, and a status indicator for each reviewer 1880. Similar to the
Freight Form above which reflects the freight billed versus the
freight paid, the Tax Form reflects the tax billed versus the tax
paid.
[0182] FIG. 19 illustrates a Warranty Form example 1900 of an
adjustment document 425. The Warranty Form example 1900 includes
the same information as the Damage Form example 1000 of FIG. 10.
For example, the Warranty Form example 1900 includes a title 1910,
initiator information 1915, reviewer information 1920, customer
information 1925, salesman information and credit analyst
information 1930, and information section 1935 including a
reference number, an invoice number, an order number, several
hyperlinks to electronic images, a product sales tracking section
1937, an adjustment chart 1940, an Inventory Records Affected
indicator 1950, a CM Payment Term 1955, a hyperlink to additional
attachments 1965, adjustment notes 1970, a history of adjustment
notes 1975, and a status indicator for each reviewer 1980. In
addition, the Warranty Form example 1900 includes a product
indicator, and a price per unit indicator, similar to as described
in FIG. 9.
[0183] Alternatively, for some buyers, the buyer may be required to
return warranty product that is considered damaged. For other
buyers, the product may simply be destroyed. In cases where the
warranty items get returned, an additional field may be added to
the warranty form to offer an RGA number or other configurable
field.
[0184] Returning now to the deduction management application of
FIG. 4, after the adjustment document creator 420 has created the
adjustment document 425, the adjustment document is passed to the
workflow approval processor 430. The workflow approval processor
then routes the adjustment document 425 to the necessary reviewer
at the seller 330.
[0185] Additional forms may include a bank fee form. The bank fee
form may reflect fees charged by the financial institution, for
example fees on wire transfers and letters of credit. Often the
financial institution takes a fee off the top before depositing the
remainder in the seller's lockbox.
[0186] FIG. 20 illustrates an exemplary operation of the workflow
approval processor 430 in accordance with a pre-configured
buyer-specific adjustment approval workflow. In FIG. 20, the
adjustment document 425 is received by the workflow approval
processor 430. A pre-configured buyer-specific adjustment approval
workflow is also preferably received by the workflow approval
processor 430 with the adjustment document 425. The workflow
approval processor 430 may then route the adjustment document 425
to one or more of the set of available human reviewers 2010-2080 in
accordance with the pre-configured buyer-specific adjustment
approval workflow. That is, the workflow approval processor 430
preferably automatically routes the adjustment document to the
seller's departments 2010-2080 for review. Additionally, each of
the seller's departments 2010-2080 preferably has access to all of
the supporting notes and documentation 810-870 shown in FIG. 8 that
may be incorporated into the adjustment document.
[0187] If no pre-configured buyer-specific adjustment approval
workflow is received by the workflow approval processor 430, the
workflow approval processor 430 may route the adjustment document
to a default set of one or more of the reviewers 2010-2080.
Additionally, if more than one human reviewer is viewing the
adjustment document at the same time, a procedure to resolve any
conflict may be implemented. Alternatively, the workflow rules may
behave similarly to the business rules. That is, a default workflow
may be implemented that is followed unless overridden by
situation-specific rules. Buyer-specific situation-specific rules
may be one example of situation-specific rules.
[0188] In the example of FIG. 20, the available reviewers include a
credit analyst 2010, the accounting department 2020, the operations
department 2030, one or more specific operations persons 2040, an
account representative 2050, the Chief Financial Officer (CFO) of
the seller 2060, the sales department 2070, and the transportation
department 2080. Additional reviewers, as well as an automated
analysis engine may also be added and the reviewers 2010-2080 of
FIG. 20 are exemplary.
[0189] Additionally, although each reviewer is shown as directly
communicating only with those reviewers close to it in the figure,
in operation, each reviewer may preferably communicate with any
other reviewer. For example, the account representative 2050 may
send the adjustment document 425 to the CFO 2060. In addition, the
CFO 2060 may send the adjustment document 425 to the accounting
department 2020.
[0190] The reviewers may each send an individual approval or denial
of the adjustment document 425 to the workflow approval processor
430. After receiving the individual approval or denial from each
reviewer, the workflow approval processor 430 sends approval data
345 to the seller 330, as described in FIG. 3. Alternatively, not
all reviewers may have authority to approve adjustment. For
example, a specific reviewer may only be included in the workflow
in order to attach a specific document or include some specific
data in the adjustment document 425. Because the posting data has
already been sent to the seller's accounting system, the reviewer's
approvals grant permission to have a credit issued for an already
disputed item included in the adjustment document.
[0191] The workflow approval processor 430 determines which
reviewers should review the adjustment document 425 and preferably
automatically flows the adjustment document to the reviewer(s).
This determination is made based on the buyer-specific workflow
criteria customizable by the seller 330. Once the adjustment
document is received, the accompanying customizable criteria is
preferably stored electronically within the workflow approval
processor 430 and associated with the adjustment document.
[0192] The workflow approval processor then routes the adjustment
document based on the buyer-specific workflow. For example, a
simple buyer-specific workflow may indicate that the adjustment
document be sent to a credit analyst 2010 and then the CFO 2060.
Consequently, the adjustment document may be transmitted to the
credit analyst 2010. When the credit analyst 2010 approves the
adjustment, the credit analyst's approval is then transmitted back
to the workflow approval processor 430. The workflow approval
processor 430 receives the approval and then examines the
buyer-specific workflow to determine if any further approvals are
necessary. In addition to a buyer-specific workflow, the workflow
may be determined by a combination of buyer-specific and reason
codes for the adjustment.
[0193] If an additional approval is necessary, the adjustment
document is then routed to the next human for approval. In this
case, the CFO's approval is also necessary, so the adjustment
document is routed to the CFO.
[0194] Conversely, if the credit analyst 2010 does not approve of
the adjustment, the disapproval is received by the workflow
approval processor 430 and the workflow approval processor 430 then
routes the adjustment document to collections for further
action.
[0195] If no further approvals are necessary, then all humans in
the buyer-specific workflow have approved the adjustment document
and the buyer's payment, including the adjustment, is approved.
[0196] Alternatively, the buyer-specific workflow may include an
analysis of the adjustment document beyond simply the buyer
associated with the adjustment document. That is, the seller may
configure the workflow approval processor to take additional data
from the adjustment document into account when determining the
routing for the adjustment document. For example, the workflow
approval processor may be configured that for a single buyer, an
adjustment below a certain threshold, for example, $10,000, may be
referred to the credit analyst 2010. An adjustment above the
threshold may be referred directly to the CFO.
[0197] Alternatively, the workflow approval processor may implement
a global threshold for all buyers so that all adjustments for all
buyers above the global threshold are automatically routed to a
different set of human reviewers. For example, all adjustments
greater than $100,000 may be immediately routed to the Sales
Manager.
[0198] In addition to routing the adjustment document based on the
amount of the adjustment, the workflow approval processor 430 may
have customizable criteria which examines any of the salesman
information, order number, invoice total, deduction amount, total
percentage amount, Inventory Records Affected indicator, and/or
Reason for Non-Compliance Indicator of the customer compliance form
example 900 of an adjustment document 425, for example, to assist
in routing the adjustment document.
[0199] The workflow approval processor 430 may also send the
adjustment document 425 to additional reviewers determined by
comparison of the customizable criteria and the information in the
adjustment document. For example, the customizable criteria of the
workflow approval processor 430 may also examine the total
percentage amount of the customer compliance form example 900. The
customizable criteria may require that the adjustment document 425
be sent to the CFO 2060 if the total percentage amount of the
adjustment document 425 is greater than a given amount, such as,
for example, 20%. When the criteria of the workflow approval
processor 430 is compared to the customer compliance form example
900 of FIG. 9, the criteria may determine that the total percentage
amount is less than 20%. Therefore, the workflow approval processor
430 may not send the adjustment document 425 to the CFO 2060.
However, note that not all adjustment documents may have a
percentage because not all documents reference a specific
invoice.
[0200] After the workflow approval processor 430 determines which
reviewers should review the adjustment document 425, the workflow
approval processor 430 sends the adjustment document 425 to each of
the selected reviewers. For example, the workflow approval
processor 430 may determine that the credit analyst 2010,
operations department 2030, CFO 2060 and sales department 2080
should review the adjustment document 425, but that the accounting
department 2020, operations reviewer 2040, account representative
2050, and transportation department 2080 should not review the
adjustment document 425. In this case, the workflow approval
processor 430 would send adjustment document 425 only to the credit
analyst 2010, operations department 2030, CFO 2060 and sales
department 2080.
[0201] Alternatively, a seller may have a problem with multiple
people reviewing and trying to save different information to the
same adjustment document. For example, it may be the case that the
original reason behind the adjustment is no longer valid. The
adjustment document may then need to be reclassified and then it
may need to be sent to a whole new group of reviewers.
Consequently, the flow process may route the adjustment document so
that only one reviewer at a time gets the needed information and
then routes the adjustment document to the next reviewer.
[0202] Once each reviewer receives the adjustment document 425, the
reviewer reviews the information contained within the adjustment
document 425. Each reviewer then approves, denies, or routes for
further review the adjustment document 425. The reviewer's approval
or denial of the adjustment document 425 is based largely on each
reviewer's individual criteria. For example, if the credit analyst
2010 determines that, based on its criteria, that the adjustment
document 425 does not meet the credit analyst's 2010 criteria, then
the credit analyst 2010 may deny the adjustment document 425.
Conversely, if the adjustment document 425 does meet the criteria
of the credit analyst 2010, then the credit analyst 2010 may
approve the adjustment document 425.
[0203] Each reviewer who receives the adjustment document 425
reviews the adjustment document 425 and either approves, partially
approves, denies, or routes to additional reviewers. Each reviewer
then sends approval or denial of the adjustment document 425 to the
workflow approval processor 430. Alternatively, the adjustment
document 425 may be directly sent to the next reviewer upon
evaluation by the first reviewer. Alternatively, an reviewer may
interrupt the scheduled flow of the adjustment document to
immediately direct the adjustment document to a certain new
reviewer specific by the current reviewer. For example, an account
representative may be reviewing the adjustment document and the
adjustment document may be scheduled to pass to the sales
department once the account representative's review is complete.
However, the account representative may decide to countermand the
usual procedure and bring the adjustment document immediately to
the attention of the CFO, for example.
[0204] In one embodiment, if any reviewer denies the adjustment,
the workflow processor refers the adjustment document to
collections for further processing. If all reviewers approve the
adjustment, then the adjustment is applied to the buyer's payment
and the buyer's adjustment is approved and a credit memo is sent.
That is, preferably, any amount sent by the buyer is posted
immediately. If an adjustment or deduction is later approved, then
a credit memo is sent to the seller's system to offset the payment
shortfall. If the deduction is denied, then the shortfall remains
on the account in aging and the matter is referred to
collections.
[0205] In another embodiment, the adjustment document may be routed
to one or more reviewers regardless of whether previous reviewers
have approved or denied the adjustment. For example, an adjustment
document may be denied by a first reviewer and yet still routed to
a second reviewer. The second reviewer may then confirm or reverse
the denial of the adjustment document. For example, if the credit
analyst 2010, account representative 2050, and sales department
2070 all receive the adjustment document 425 for their review, and
the credit analyst 2010 and sales department 2070 both approve the
adjustment document 425, but the account representative 2050 denies
the adjustment document 425, the workflow approval processor 430
may deny the adjustment document 425.
[0206] If the workflow approval processor 430 determines that the
adjustment document 425 should be approved, the workflow approval
processor 430 may then determine whether the adjustment document
425 is requesting a deduction in the invoice amount or a refund for
an overpayment. If the workflow approval processor 430 determines
that the adjustment document 425 is requesting a refund for an
overpayment, then the workflow approval processor 430 may create
posting data 345. The posting data 345 may contain directions to
create an invoice in the amount of the overpayment.
[0207] However, if the workflow approval processor 430 determines
that the adjustment document 425 is requesting a deduction in the
invoice amount, then the workflow approval processor 430 may
include a credit memo in the amount by which buyer's 310 invoice
amount should be deducted (it is already deducted, that is how a
425 document gets created. Also, it will not always reference a
specific invoice number).
[0208] Conversely, if the workflow approval processor 430
determines that the adjustment document 425 should be denied, the
workflow approval processor 430 may refer the adjustment document
to the seller's collections department to start the collection
process. The collection process is the process of collecting past
due monies on an outstanding bill. In this way, the workflow
approval processor may begin efforts to collect the amount the
buyer 310 has yet to pay the seller 330 for the seller's 330 goods
or collect the unauthorized deduction.
[0209] Alternatively, a reviewer in the workflow approval process
may also approve or deny the adjustment document 425 based on
customizable tolerances. For example, in the first embodiment, a
denial of the adjustment document 425 by a single reviewer may
result in the workflow approval processor 430 denying the
adjustment document 425. However, in the alternative embodiment,
the workflow approval processor 430 may be customized to allow for
a greater tolerance of one or several reviewer denials of the
adjustment document 425. In this way, the workflow approval
processor 430 may be customized to deny the adjustment document 425
only when at least a majority of the reviewers denied the
adjustment document 425. Alternatively, the workflow approval
processor 430 may be customized to deny the adjustment document 425
only when a ratio of reviewer denials to reviewer approvals is
greater than a given amount.
[0210] Alternatively, any person included as part of the workflow
may be allowed to deny the adjustment document at any point.
However, there may preferably be only one final approver. Such a
system may prevent reviewers from approving everything just so they
don't have to spend time collecting if the adjustment is
denied.
[0211] FIG. 21 illustrates an exemplary task list 2100 for a human
reviewer summarizing all outstanding adjustments awaiting approval
by the human reviewer. The task list 2100 includes a plurality of
outstanding adjustments or disputes 2105, a reviewer name 2120, a
dispute reason code 2115, an adjustment number 2120, a customer
name 2125, a customer number 2130, an invoice/reference number
2135, an invoice date (which is preferably the day the adjustment
was created) 2140, and a due date 2145. The due date is preferably
a seller-configured date by which the adjustment is scheduled by
the seller to be resolved. For example, the seller may set an
internal due date of 30 days for the resolution of the adjustment.
Alternatively, the due date 2145 may be removed or changed to the
received date that the initial payment was received.
[0212] Additionally, the task list 2100 includes a current total
outstanding adjustments 2150 and adjustment aging columns 2155. The
content of the task list 2100 is preferably reviewing the
unresolved elements in the approval processor 430 that are assigned
to a particular reviewer. Additionally, the content of the task
list is preferably produced by a computer application running in
communication with the workflow approval processor 430.
[0213] The appearance and content of the task list 2100 is
preferably highly configurable. For example, the task list may be
readily re-configured to display its contents in groupings based a
number of user-selectable parameters such as customer identity,
size of adjustment, again of adjustment, percentage of adjustment,
and similar groupings.
[0214] The task list 2100 may include adjustments other than those
awaiting approval. For example, the task list may include items
awaiting classification, research, approval, review, or any other
status code that may be employed by the seller. Additionally, an
adjustment may be reclassified as the adjustment is reviewed. For
example, a first reviewer may pass the adjustment to a second
reviewer. The second reviewer may determine that the wrong type of
adjustment form has been used. The second reviewer may then change
the adjustment form type and send the revised adjustment form back
to the first reviewer for further review or to someone else
entirely depending on the configuration of the workflow.
[0215] In operation, a plurality of outstanding adjustments 2105
has been referred to the reviewer 2110 for approval, denial,
partial approval, or further review. The reviewer 2110 may sort the
outstanding adjustments 2105 by any of the column criteria
2115-2155 such as customer invoice data, due date, or outstanding
balance.
[0216] In FIG. 21, the reviewer 2110 has sorted the outstanding
adjustments 2105 by dispute reason code 2115. As discussed above,
each of the dispute reason codes may be associated with one of the
adjustment documents of FIGS. 9-19. Alternatively, the dispute
codes may be configured to be other seller-selected statuses.
Additionally, for each dispute reason code, a total dollar volume
2160 for the dispute reason code is shown
[0217] Once the adjustment documents have been referred to the
reviewer 2110 and assembled in the summary sheet 2100, the reviewer
2110 may simply click on any of the outstanding disputes 2105 to
bring up the adjustment document associated with the outstanding
dispute. Additionally, as mentioned above, each of the adjustment
documents preferably includes all relevant data and/or scanned
images needed by the reviewer 2110 to approve, deny, partially
approve, or further route the outstanding adjustment 2105.
[0218] Thus, preferably the reviewer 2110 has all information
necessary to resolve all outstanding adjustments 2105 in a quick
and relatively effortless fashion. The reviewer 2110 need not
search for information or retrieve any information from differing
systems because all information relating to the payment has already
been assembled for the reviewer.
[0219] Conversely, in some situations, the task list may be
provided to an intermediate reviewer so that the intermediate
reviewer may update one or more of the adjustments on the task list
with desired documentation. The updated adjustments may then be
passed to a reviewer for evaluation.
[0220] Additionally, assuming that the reviewer approves the
adjustment, but further review by a different reviewer is
indicated, then the adjustment document merely migrates from the
task list 2100 of the first reviewer to the summary sheet of the
second reviewer. For example, once the first reviewer has completed
their review, the first reviewer may send the adjustment to the
second reviewer. The electronic transfer of the adjustment document
from the first reviewer's summary sheet to the second reviewer's
summary sheet consequently entails no delay in the transfer and
eliminates any information being lost when transferring the
adjustment document between reviewers. This eliminates a problem in
prior art systems where routing of the adjustment documents was
slow and laborious and often accompanied by loss of needed
information during the routing process.
[0221] Alternatively, instead of migrating from the first
reviewer's task list to the second reviewer's task list, the status
of the adjustment may merely be changed from "open", for example,
to "approved", "unapproved", or some other status code.
[0222] FIG. 23 illustrates a high-level representation of an
adjustment document 2300, such as the adjustment documents of FIGS.
9-19. The adjustment document 2300 includes an adjustment status
control 2305, header information 2310, status information 2320,
customer information 2325, invoice/debit information 2335,
additional information 2340, notes 2360, edit history 2370,
workflow data 2380, attached file control 2365, and attached filed
2370.
[0223] As discussed above, the actual items of information included
in an adjustment document may be configured at several levels. For
example, the seller may institute a default appearance and
information content for a specific type of form. Additionally,
customer-based defaults may be employed to modify the seller-wide
default. Additionally, the content of the adjustment document may
preferably be fine-tuned by a reviewer and the items of information
appearing in the adjustment document may preferably be dynamically
changed by the reviewer. However, the high-level adjustment
document 2300 illustrates the general categories of information
that preferably make up the contents of the adjustment
documents.
[0224] First, with regard to the adjustment status control 2305,
the reviewer may interact with the adjustment status control 2305
to alter the status of the adjustment document. For example, the
adjustment status control 2305 may include a plurality of buttons
representing the various status of the adjustment document that a
reviewer may select.
[0225] The header information 2310 preferably includes the basic
information with regard to the adjustment document such as the name
of the company requesting the adjustment, the category of the
adjustment, the identification number of the adjustment document
and the dispute flag.
[0226] The status information 2320 preferably indicates the current
status of the adjustment document, such as approved, partially
approved, rejected, or awaiting approval, for example. The customer
information 2325 includes information with regard to the customer,
such as the contact information for the customer and/or any
customer specific accounting information such as a customer
discount, for example.
[0227] The invoice/debit information 2335 includes information with
regard to the invoice that the customer is disputing. For example,
the invoice/debit information 2335 may preferably include the date
and amount of the invoice, a listing of the products sent and any
information provided by the buyer, for example, with regard to
items damaged and/or not received.
[0228] The additional information 2340 is highly-configurable by
the reviewer and may include any additional data that the reviewer
chooses to incorporate into the adjustment document. The notes 2360
may include notes from one reviewer to the next with regard to the
seller's claimed adjustment, for example. The edit history 2370
preferably includes a listing of all changes in status that have
taken place for the adjustment document. The workflow data 2380
preferably includes a listing of all reviewers that have reviewed
the adjustment document.
[0229] The attached file control 2365 is preferably an interface
allowing a reviewer to easily attach external files to the
adjustment document. The attached files themselves are represented
as attached files 2367.
[0230] Thus, the preferred embodiments of the present invention
provide an automated sales payment processing and exception
management solution. The automated solution may process a large
number of adjustments quickly according to the seller-configured,
buyer-specific set of business rules. The automated solution may
thus dramatically cut down on the time and effort previously needed
to resolve the majority of adjustments. Consequently, the seller
may experience great savings by minimizing labor and maximizing the
speed of processing many adjustments.
[0231] Additionally, in a preferred embodiment, the payment
matching, business rules, and workflow are all delivered through
the Financial Institution. While some financial institutions may be
attempting to automatically resolve cash payments, no financial
institution directly integrates data received from the seller into
the payment resolution process.
[0232] Also, although the term "buyer" has been used throughout
this application, it is recognized that an actual buyer may
outsource some or all of their payment activities to a third party
or have various activities hosted or provided by a third party. For
example, the buyer may outsource document imaging. The term buyer
is broadly drawn to include any entity submitting payment including
distributors, purchasing groups, independent third parties,
franchisees, transporters and other entities that are involved in
the purchasing process.
[0233] Similarly, the term "seller" has also been used throughout,
but may actually represent a third party or hosted application or
other arrangement. Consequently, the term seller may be broadly
drawn to include any entity receiving payment for goods or
services.
[0234] Additionally, as discussed above, the embodiments of the
present payment and adjustment management application may be
delivered in any of a variety of implementations. For example, the
management application may be installed at a financial institution,
hosted by the seller, outsourced to a third party provider, or
installed at the seller.
[0235] The present embodiments may be most useful in a system that
first attempts to automatically match all received payments with
invoices, such the system further described in U.S. patent
application Ser. No. ______ filed ______, entitled "System And
Method For Automated Incoming Payment And Invoice Reconciliation",
which is incorporated herein by reference in its entirety. The
received invoices that are not able to be directly matched by the
invoice reconciliation system may then be referred to the automated
payment processing and exception management system described
further in U.S. patent application Ser. No. ______ filed ____,
entitled "System And Method For Automated Payment And Adjustment
Processing", which is incorporated herein by reference in its
entirety. Finally, if the automated payment processing and
exception management system is unable to automatically process the
buyer's adjustment, then an adjustment document may be created and
routed to a human for approval as described herein.
[0236] 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.
* * * * *