US20050075979A1

US20050075979A1 - System and method for seller-assisted automated payment processing and exception management

Info

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

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.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 60/508,221, filed Oct. 2, 2003, entitled “Adjustment Management System and Method.” This application is related to U.S. patent application Ser. No. ______ filed ______, entitled “System And Method For Automated 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

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.
FIG. 1 illustrates a typical transaction 100 for the purchase of goods according to the prior art. As shown in FIG. 1, the transaction involves a buyer 110, a seller 130, and a financial institution 120. Typically, the buyer 110 sends a purchase request 102 or purchase order to the seller 130. The purchase request 102 identifies the goods the buyer 110 desires. The seller 130 receives the buyer's purchase request and then ships the goods to the buyer 110.
Along with or separate from the goods, the seller 130 may send a statement or invoice 105. The invoice 105 typically lists the goods being shipped and may include other information such as price, quantity, a seller coding or identification such as a SKU number and/or other order information. Alternatively, instead of a single invoice for a single shipment, a statement reflecting multiple shipments may be employed in situations where multiple shipments are sent to the same buyer.
Once the buyer 110 has received the seller's goods and invoice 105, the buyer 110 must pay for the goods 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.
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.
The payment data 125 may take the form of a monthly, weekly, or typically a daily account summary. In the most preferable configuration, the account summary is updated several times a day. The payment data may also be electronically sent to the seller 130 or may be provided to the seller 130 by allowing the seller to electronically access the financial institution's records or photocopies may be mailed to the seller 130.
Additionally, as mentioned above, the buyer's payment may be received in any of a variety of methods. However, regardless of the type of payment received, the payment is typically converted to an electronic expression by the financial institution. For example, a paper check that is received by the financial institution may be scanned or imaged and the payment data on the face of the check may be converted into an electronic expression by a data entry person at the financial institution 120. ACH or wire transfers are already in an electronic form, but the financial institution's record of the transaction may also reflect the originator of the ACH and the date of the ACH, for example. Typically, most of the bank's electronic data is sent to the seller 130 as the payment data 125.
Once the payment data 125 has been received by the seller 130, the seller 130 must then begin the laborious task of matching each received payment with the corresponding invoice. That is, in order to confirm that the buyer 110 has paid for the goods that were shipped, the seller 130 matches the payment data 125 received from the financial institution 120 to the invoice data 105 that was sent to the buyer 110. Once the seller 130 has matched the invoice data 105 to the payment data 125, the transaction is said to be closed-out, provided that the invoice data matches the payment data exactly. For a seller with a large number of invoices, this process may be very time consuming.
Additionally, until the payment data 125 has been successfully matched to the invoice data 105 by closing out the transaction, the seller 130 does not know whether the correct payment has been received from the buyer 110. The buyer 110 may have over or underpaid, for example. Consequently, until the transaction has been closed out, the seller 130 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
FIG. 2 illustrates a typical work flow 200 for a processing a transaction for selling goods. First, at step 210, the sell side 201 sends an invoice to the buy side 202. Next, at step 220, the invoice is initially reviewed by the buyer. Any disputes are handled in step 230, for example by making an adjustment. Also at step 230, any dispute or adjustment is reviewed and approved by the buyer. As discussed further below and indicated in FIG. 2, the dispute and adjustment process may be quite time and labor consuming for the seller. Finally, at step 240, payment is sent from the buyer to the seller.
Note that in step 240, the payment received from the buyer is often manually matched to an invoice at the seller, which is quite time consuming. Even if some data is electronically provided, the buyer's payment systems are typically not equipped to process the received data without substantial human interaction. Additionally, at step 230, the adjustment or dispute process is identified as labor intensive and lengthy for both the buyer and the seller.
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.
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.
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.
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.
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

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

FIG. 1 illustrates a typical transaction for the purchase of goods according to the prior art.
FIG. 2 illustrates a typical work flow for a processing a transaction for selling goods.
FIG. 3 illustrates an automated payment processing and exception management system according to an embodiment of the present invention.
FIG. 4 illustrates an embodiment of the adjustment management application of FIG. 3 in greater detail.
FIG. 5 illustrates an example of some of the types of informational sources that may be included in the payment data.
FIG. 6 illustrates a flowchart of the operation of the business data filter according to one embodiment of the present invention.
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.
FIG. 8 illustrates a variety of exemplary documents and other items for incorporation into the adjustment document.
FIG. 9 illustrates a Customer Compliance Form example according to an embodiment of the present invention.
FIG. 10 illustrates a Damage Form example according to an embodiment of the present invention.
FIG. 11 illustrates a Discount Form example according to an embodiment of the present invention.
FIG. 12 illustrates a Freight Form example according to an embodiment of the present invention.
FIG. 13 illustrates a Marketing Form example according to an embodiment of the present invention.
FIG. 14 illustrates a Miscellaneous Form example according to an embodiment of the present invention.
FIG. 15 illustrates a Price Form example according to an embodiment of the present invention.
FIG. 16 illustrates a Quantity Form example according to an embodiment of the present invention.
FIG. 17 illustrates a Return Form example according to an embodiment of the present invention.
FIG. 18 illustrates a Tax Form example according to an embodiment of the present invention.
FIG. 19 illustrates a Warranty Form example according to an embodiment of the present invention.
FIG. 20 illustrates an exemplary operation of the workflow approval processor in accordance with a pre-configured buyer-specific adjustment approval workflow.
FIG. 21 illustrates an exemplary task list for a human reviewer summarizing all outstanding adjustments awaiting review by the human reviewer.
FIG. 22 illustrates a flowchart of an embodiment of the procedure for processing an adjustment form.
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

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.
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.
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.
The invoice information 305 preferably includes information relating to the goods that were shipped from the seller 330 to the buyer 310. For example, the invoice information 305 preferably includes a seller coding identifying the goods being shipped, the price, quantity, and/or other order information.
As mentioned above, the 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.
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.
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.
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.
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.
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.
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.
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.
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.
With regard to invoice-related information, the order data 335 preferably includes all of the information that was included in the invoice information 305 that was sent to the buyer 310, and may also include information relating to the transfer of the goods such as a bill of lading or electronic images of the invoice information 305.
That is, one element of the payment 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.
With regard to buyer-related information, the order data 335 also preferably includes information relating to the buyer itself, such as the number of previous orders by the buyer, any negotiated discounts that apply to the buyer or other incentives, for example, as further described below.
With regard to the seller-related information, the order data 335 may include information with regard to the seller such as the salesperson that originated the order or internal routing information for adjustment approval, for example, as further described below.
Once the 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.
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.
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.
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.
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.
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.
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.
As mentioned above, the invoice information 305 may take any of several forms. For example, the invoice information 305 may be a paper document or an electronic document such as an e-mail, web-enabled form, or other EDI information exchange.
Although the present embodiment is discussed above in relation to the buyer ordering goods, the buyer may instead be interested in securing services. Similar considerations arise in the context of procuring services with regard to 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.
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.
Similar to the invoice information above, the payment information may take any of a wide number of forms as chosen by the buyer. For example, the payment information 315 may therefore include a check, a financial institution draft, a cashier's check, a money order, an order to charge a credit line, a promissory note, or any other document that shows payment for goods and/or services received. In addition, the payment information 315 may also include an electronic image of the form of payment. For example, the payment information 315 may include an electronic image of a check used to pay for the goods and/or services.
Further to the discussion above, the payment 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.
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.
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.
The order data 335 and posting data 345 may also take any of wide variety of forms such as e-mail, XML documents, HTML documents, or EDI, for example.
Additionally, the 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:

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
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).
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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%.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The additional attachments 1065 section of the form 1000 has been supplemented to include a customer quote section.
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.
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.
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.
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.
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.
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.
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.
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.
The additional attachments 1265 includes a link to get a customer quote for freight. The quote may be imaged and attached to the document.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
While particular elements, embodiments and applications of the present invention have been shown and described, it is understood that the invention is not limited thereto since modifications may be made by those skilled in the art, particularly in light of the foregoing teaching. It is therefore contemplated by the appended claims to cover such modifications and incorporate those features that come within the spirit and scope of the invention.

Claims

1. A method for 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:

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:

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:

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.