Patent Application
20050075979
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.
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.
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.
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.
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
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
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
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
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
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.
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
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
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
As further described below with regard to
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.
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.
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
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
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
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.
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
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.
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,
Returning to
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.
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:
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
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.
In the Damage Form 1000, all of the elements are similar to the form 900 of
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
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
The damage chart 1037 includes a listing of the adjustments for up to the 10 separate damaged goods claims. Although the example of
The additional attachments 1065 section of the form 1000 has been supplemented to include a customer quote section.
In the Discount Form 1100, all of the elements are similar to the form 900 of
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.
In the Freight Form 1200, all of the elements are similar to the form 900 of
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.
In the Marketing Form 1300, all of the elements are similar to the form 900 of
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.
In the Miscellaneous Form 1400, all of the elements are similar to the form 900 of
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
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.
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
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.
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
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
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
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.
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
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.
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.
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.”
| Number | Date | Country | |
|---|---|---|---|
| 60508221 | Oct 2003 | US |
