US20050075978A1 - System and method for automated payment and adjustment processing - Google Patents
System and method for automated payment and adjustment processing Download PDFInfo
- Publication number
- US20050075978A1 US20050075978A1 US10/865,076 US86507604A US2005075978A1 US 20050075978 A1 US20050075978 A1 US 20050075978A1 US 86507604 A US86507604 A US 86507604A US 2005075978 A1 US2005075978 A1 US 2005075978A1
- Authority
- US
- United States
- Prior art keywords
- buyer
- payment
- seller
- invoice
- business
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/045—Payment circuits using payment protocols involving tickets
- G06Q20/0457—Payment circuits using payment protocols involving tickets the tickets being sent electronically
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/04—Billing or invoicing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/42—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for ticket printing or like apparatus, e.g. apparatus for dispensing of printed paper tickets or payment cards
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F9/00—Details other than those peculiar to special kinds or types of apparatus
- G07F9/04—Means for returning surplus or unused coins
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
- G07G1/00—Cash registers
- G07G1/01—Details for indicating
- G07G1/06—Details for indicating with provision for the noting of the money to be paid
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
- G07G5/00—Receipt-giving machines
Definitions
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- current systems and methods do not provide for integration between the adjustment management system and method and the bank of the seller. This, in turn, causes additional delay in the final resolution of adjustment requests. This delay will be because the seller will have to notify the customer, who will then have to send payment to the seller. In a similar manner, any posting of money owed to the customer will also be delayed.
- 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.
- 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.
- such a system is typically viewed unfavorably by the seller because it typically involves an additional delay for payment.
- 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. 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 .
- 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).
- ASP application service provider
- 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 .
- the adjustment processing application 340 may be hosted or installed at a third party or may be otherwise outsourced.
- the present system may provide for automated processing of payments from sellers when the sellers are claiming and adjustment such as a deduction.
- automatic processing adjustments that fall within the pre-configured business rules a large quantity of adjustments may be automatically handled by the system without requiring any human interaction. Instead, human interaction may only be required for the small number of adjustments that fall outside of the business rules. Consequently, because many adjustments/deductions may now be handled automatically, a significant cost reduction in worker-hours may be realized.
Abstract
A system and method for automated adjustment processing using pre-configured sets of business rules is provided. The seller pre-configures a set of business rules for use in processing an adjustment for a specific buyer. The set of business rules may be variable for each buyer and/or globally set. When a payment is received from a seller and an adjustment is required, an adjustment management application retrieves the buyer's set of business rules from the seller. The set of business rules are then applied to attempt to match the received payment to one of the buyer's outstanding invoices. If the match is successful, the buyer's payment is processed.
Description
- 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 Seller-Assisted Automated Payment Processing and Exception Management.”
- The present application generally relates to systems and methods for the management of exceptions such as adjustments or deductions taken by buyers with regard to payments sent to a seller. More specifically, the present application presents an automated system and method for processing adjustments such as deductions taken by a buyer or credits to a buyer with regard to payments sent to a seller, processing the transaction at the seller's side, closing out the transaction and updating the seller's accounting system.
-
FIG. 1 illustrates atypical transaction 100 for the purchase of goods according to the prior art. As shown inFIG. 1 , the transaction involves abuyer 110, aseller 130, and afinancial institution 120. Typically, thebuyer 110 sends apurchase request 102 or purchase order to theseller 130. Thepurchase request 102 identifies the goods thebuyer 110 desires. Theseller 130 receives the buyer's purchase request and then ships the goods to thebuyer 110. - Along with or separate from the goods, the
seller 130 may send a statement or aninvoice 105. Theinvoice 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 andinvoice 105, thebuyer 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 thefinancial institution 120 asremittance information 115. In some cases the payment and/or information is sent initially to theseller 130, who then passes it along to thefinancial institution 120. - The
financial institution 120 receives the buyer's payment andremittance 115 and deposits the funds in seller's account at thefinancial institution 120. Thefinancial institution 120 then alerts theseller 130 that a payment has been received by sendingpayment data 125 to theseller 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 theseller 130 or may be provided to theseller 130 by allowing the seller to electronically access the financial institution's records or photocopies may be mailed to theseller 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 theseller 130 as thepayment data 125. - Once the
payment data 125 has been received by theseller 130, theseller 130 must then begin the laborious task of matching each received payment with the corresponding invoice. That is, in order to confirm that thebuyer 110 has paid for the goods that were shipped, theseller 130 matches thepayment data 125 received from thefinancial institution 120 to theinvoice data 105 that was sent to thebuyer 110. Once theseller 130 has matched theinvoice data 105 to thepayment 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 theinvoice data 105 by closing out the transaction, theseller 130 does not know whether the correct payment has been received from thebuyer 110. Thebuyer 110 may have over or underpaid, for example. Consequently, until the transaction has been closed out, theseller 130 can not be sure whether the current balance reflected in the seller's account at thefinancial institution 120 represents available cash or whether some amount is due back to thebuyer 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 ofbuyers 110. Additionally, matching payment data to invoice information may be further complicated by the time lag between the time theinvoice 105 was sent to thebuyer 110 and the time thepayment data 125 was received by the seller. Additionally, matching payment data to invoice information may be further complicated because the receivedpayment data 125 may not match theinvoice 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 the invoice with the demand for a refund of overpayment or deduction in the invoice amount written on the invoice. Alternatively, the adjustment request may also be any form of electronic communication such as electronic data from a website.
- 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 either 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 and accepts a lower payment from the buyer.
-
FIG. 2 illustrates atypical work flow 200 for a processing a transaction for selling goods. First, atstep 210, thesell side 201 sends an invoice to thebuy side 202. Next, atstep 220, the invoice is initially reviewed by the buyer. Any disputes are handled in step 230, for example by making an adjustment. Also at step 230, any dispute or adjustment is reviewed and approved by the buyer. As discussed further below and indicated inFIG. 2 , the dispute and adjustment process may be quite time and labor consuming for the seller. Finally, atstep 240, payment is sent from the buyer to the seller. - Note that in
step 240, the payment received from the buyer is often manually matched to an invoice at the seller, which is quite time consuming. Even if some data is electronically provided, the buyer's payment systems are typically not equipped to process the received data without substantial human interaction. Additionally, at step 230, the adjustment or dispute process is identified as labor intensive and lengthy for both the buyer and the seller. - Thus, current systems for resolving adjustments are overly costly for a number of reasons. First, there is an abundance of information to monitor. This information includes customer information, invoice information, the cause for the adjustment request (i.e., whether a deduction or overpayment refund is being sought), past invoices of the customer, past adjustment requests from the customer, and the customer's credit line with the seller, and may include other information.
- Second, in large businesses, there is often an inability to ensure that all of the relevant departments of the seller (for example, the accounting department, shipping department, and credit department, among others) are able to review, edit, and approve or deny the adjustment request. This inability to ensure that all of the relevant departments of the seller review the adjustment request stems from the manual coupling of the adjustment request and the relevant documentation, as discussed above. Undoubtedly, errors occur on a frequent basis where, for example, a reviewer does not receive all of the documentation that he requires to properly review the adjustment request.
- In a related problem, third, it may be very difficult to ensure that all relevant departments of the seller perform their reviews in a timely manner, especially when several departments are involved. For example, delay in ensuring that a first reviewer receives all of the documentation required for his review of the adjustment request will cause further delay for subsequent reviewers. In this way, when other reviewers are waiting for the first reviewer to complete his review of the adjustment document and relevant documentation, delay in the processing of the adjustment request ensues. This delay becomes even more troublesome when multiple levels of review (that is, one reviewer must wait and review a first reviewer's resolution of the adjustment request) are required by the seller. For example, where a seller requires that all initial reviews of an adjustment request be reviewed by a manager of reviewers, any delay in routing the information to, and receiving a resolution from, one or more of the reviewers will only cause additional delay.
- Finally, any delay in ensuring that all relevant departments review the adjustment request will cause additional delays in pursuing collection of a debt owed by a customer or in issuing a refund owed to a customer. This can cause business losses due to lengthy collection delays and a loss of customer goodwill. In addition, current systems and methods do not provide for integration between the adjustment management system and method and the bank of the seller. This, in turn, causes additional delay in the final resolution of adjustment requests. This delay will be because the seller will have to notify the customer, who will then have to send payment to the seller. In a similar manner, any posting of money owed to the customer will also be delayed.
- 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 is capable of handling a large number of adjustment requests in order to reduce unnecessary write-offs by a seller. Also, a need has long been felt for a system to reduce the labor and time investment for processing the adjustments. Additionally, a need has long been felt for a flexible system that may be used to process a wide variety of adjustment requests. Finally, a need has long been felt for an adjustment system that is directly integrated with the seller's financial institution.
- The embodiments of the present invention provide a system and method for automating the processing of adjustments for a payment received from a buyer by using a pre-configured set of business rules selected by the seller for that buyer. That is, the seller pre-configures a set of business rules for use in processing adjustments for a specific buyer. Each buyer may have its own individually configured set of business rules. When a payment is received at a seller from a buyer that does not exactly match any of the outstanding invoices for the buyer, an adjustment management application at the seller applies the set of business rules for the buyer. The adjustment management application then attempts to match the received payment to one of the buyer's outstanding invoices using the buyer's set of business rules. If the adjustment management application is successful in finding a match, the buyer's payment is automatically posted. If the adjustment management application is not successful in finding a match, the buyer's payment is selected for further processing, for example, the payment may be routed to a human reviewer.
-
FIG. 1 illustrates a typical transaction for the purchase of goods according to the prior art. -
FIG. 2 illustrates a typical work flow for a processing a transaction for selling goods. -
FIG. 3 illustrates an automated adjustment management system according to an embodiment of the present invention. -
FIG. 4 illustrates an embodiment of the adjustment management application ofFIG. 3 in greater detail. -
FIG. 5 illustrates an example of some of the types of informational sources that may be included in the payment data. -
FIG. 6 illustrates a flowchart of the operation of the business data filter according to one embodiment of the present invention -
FIG. 3 illustrates an automated payment processing andexception management system 300 according to an embodiment of the present invention. The payment processing andexception management system 300 includes abuyer 310, afinancial institution 320, aseller 330, anadjustment processing application 340, and a payment andadjustment management application 350. The payment andadjustment management application 350 includes thefinancial institution 320 and theadjustment processing application 340. - As further described below, a
purchase request 302 travels frombuyer 310 to theseller 330.Invoice information 305 travels from theseller 330 tobuyer 310. Theinvoice information 305 may travel separate from the goods and/or services provided by theseller 330, or may travel along with the goods and/or services.Payment information 315 is sent frombuyer 310 to the seller'sfinancial institution 320. Payment andremittance data 325 is sent from thefinancial institution 320 to theadjustment processing application 340.Order data 335 is sent from the seller to theadjustment processing application 340. Theorder data 335 may be sent to theadjustment processing application 340 when the underlying goods are invoiced to the buyer, or may be sent to theadjustment processing application 340 at some later time. The postingdata 345 is sent from theadjustment processing application 340 to theseller 330. - In operation, the payment processing and
exception management system 300 proceeds generally as follows. First, thebuyer 310 may decide to purchase goods, for example, from theseller 330. Typically, thebuyer 310 then notifies theseller 330 that thebuyer 310 wishes to make a purchase by sending apurchase request 302 to theseller 330. Theseller 330 then receives the buyer'spurchase request 302. Theseller 330 then ships the desired goods to thebuyer 310 and also sendsinvoice information 305 to thebuyer 310. - The
invoice information 305 preferably includes information relating to the goods that were shipped from theseller 330 to thebuyer 310. For example, theinvoice 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 thebuyer 310. Thebuyer 310 then reviews the received goods. Thebuyer 310 preferably then pays for the received goods. However, the amount of the buyer's payment may differ from the payment amount invoiced by theseller 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 theinvoice information 305. - Returning to
FIG. 3 , once the goods have been received by thebuyer 310, the buyer then pays for the goods by transmittingpayment information 315 to thefinancial institution 320. That is, thebuyer 310 submitspayment information 315 including a payment to the seller'sfinancial institution 320. However, as shown inFIG. 3 , the present embodiment operates to transform thefinancial institution 320 into a payment andadjustment management application 350 by integrating thefinancial institution 320 with theadjustment processing application 340. - That is, once the goods have been received by the
buyer 310 or in accordance with the terms of the accompanying invoice, the buyer then pays for the goods. However, if one or more of the above-mentioned difficulties with the goods has occurred, the amount that the buyer may submit as payment may differ from the amount included in theinvoice information 305. When the payment amount submitted by thebuyer 310 differs from and is less than the payment amount included in theinvoice information 305, the difference in the payment amounts is referred to as a deduction. - As mentioned in the background section above, when a
buyer 310 takes a deduction in the typical fashion, the taking of the deduction necessitates a great deal of work for the seller. Typically, the seller must reconcile the payment amount received from the buyer with the goods and invoice information that were sent to the buyer, which may be a complicated and time-consuming process. - In a few of the previous systems, in order to reduce the amount of time spent reconciling the invoice information, the seller may request that the buyer submit a debit memo in order to allow the buyer to take a deduction, either manually or through a web site. Managing deductions by using such a form may assist a seller in its internal accounting, but may entail additional delay in approval by the seller and disbursement or credit to the buyer. Consequently, such a system is often viewed as onerous by both buyer and seller. In other previous systems, buyers may refuse to pay an invoice unless it is accurate, that is, unless a final revised invoice showing all adjustments has been received by the buyer, or a credit memo issued to offset the incorrect invoice, or a deduction is authorized prior to payment. However, such a system is typically viewed unfavorably by the seller because it typically involves an additional delay for payment.
- Conversely, as shown in
FIG. 3 , thebuyer 310 submitspayment information 315 including a payment to the seller'sfinancial institution 320. However, as shown inFIG. 3 , the present embodiment operates to transform thefinancial institution 320 into a payment andadjustment management application 350 by integrating thefinancial institution 320 with theadjustment processing application 340. - That is, the buyer's payment and
remittance information 315 is sent to thefinancial institution 320. Thepayment 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. Thefinancial institution 320 receives the payment andremittance information 315 and generates the payment andremittance data 325. The payment andremittance 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 andremittance data 325 is then sent to theadjustment processing application 340. - In addition to the payment and
remittance data 325, theadjustment processing application 340 also receivesorder data 335 from theseller 330. Theorder 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 theinvoice information 305 that was sent to thebuyer 310, and may also include information relating to the transfer of the goods such as a bill of lading or electronic images of theinvoice 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 theadjustment processing application 340, for example at the time the invoice was originally sent to the buyer. If theadjustment processing application 340 is unable to find a particular invoice for a particular seller, then theadjustment processing application 340 may default to a standard deduction form, as further described below. Alternatively, theadjustment processing application 340 may then query theseller 330 and retrieve a listing of all outstanding invoices for the indicated buyer asorder data 335. If no buyer is indicated in thepayment data 325, theadjustment processing application 340 may preferably retrieve all outstanding invoices for all buyers. That is, the payment andremittance data 325 preferably indicates the buyer. Theadjustment processing application 340 may then query theseller 330 for any information related to that buyer. Additionally, theadjustment processing application 340 may retrieve the data from theseller 330 in any of a variety of ways. For example,order data 335 may be received by theadjustment 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, thepayment information 315 received from thebuyer 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 andremittance data 325 and theorder data 335, theadjustment processing application 340 then proceeds to attempt to match the received payment andremittance data 325 to one or more of the outstanding invoices retrieved from theorder data 335. - As further described below with regard to
FIG. 6 , if thepayment data 325 is immediately matchable to one or more invoices, theadjustment processing application 340 sends an indication of the successful match to theseller 330 as postingdata 345. The postingdata 345 preferably indicates which invoice or invoices are being paid by the payment data. Theseller 330 receives the postingdata 345 and the accounting system records at theseller 330 are then updated to reflect that the invoices(s) have been paid in order to close the transaction. Although the present discussion focuses on the operation of theadjustment processing application 340 on an invoice-by-invoice basis, the adjustment processing application may also operate on a batch basis. For example, a batch of invoices may be processed at one time. The batch of invoices may be sent to the seller at one time as batch after all invoices have been matched and/or all exceptions to the invoiced handled as further described below. For example, theadjustment processing application 340 may process the batch of invoices, match the invoices that it is able to match, and then concentrate on classifying the exceptions in the remaining invoices before passing the entire batch of invoices to the seller as further described below. A reviewer at the seller may then further review, modify and/or approve/reject the exceptions. - If the
payment data 325 is not immediately matchable to one or more invoices, then the seller may be claiming an adjustment or an error has occurred and theadjustment processing application 340 may then flag the payment data for further processing as further described below with regard toFIG. 6 . - The
adjustment processing application 340 may then attempt to apply a set of seller-configurable business rules to the payment data in order to attempt to automatically resolve and process the adjustment, as further described below. For example, theadjustment 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 management application 340 is unable to automatically resolve the adjustment, after the application of the business rules, the payment and remittance data may be referred to the seller for further processing. - 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 Adjustment Processing”, which is incorporated herein by reference in its entirety.
- Once the
adjustment processing application 340 has processed the payment andremittance data 325 andorder data 335 and the buyer's adjustment has been resolved, theadjustment processing application 340 sends postingdata 345 to theseller 330. As further described below, the postingdata 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, theinvoice 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 tobuyer 310. Theinvoice 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 frombuyer 310 to theseller 330, or anyavailable credit buyer 310 has with theseller 330. In addition, theinvoice information 305 may include an invoice number to be used by theseller 330 for identification and tracking purposes. For example, theinvoice information 305 may include an invoice number so that theseller 330 may be able to track which goods and/or services have been delivered or provided tobuyer 310. In addition, theinvoice 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, thepayment information 315 may also include an electronic image of the form of payment. For example, thepayment 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, thefinancial 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, thefinancial 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. The notations made by thefinancial institution 320 may then be passed to the adjustment management application as part of the payment andremittance 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. Thefinancial 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 theadjustment 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 andremittance 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 postingdata 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, theadjustment processing application 340 may be directly hosted by thefinancial institution 320, theseller 330 or a third party. The actual physical location of theadjustment processing application 340 is not relevant as long as it remains in communication with thefinancial institution 320 and theseller 330. For example, theadjustment processing application 340 may be hosted or installed at a third party or may be otherwise outsourced. -
FIG. 4 illustrates an embodiment of theadjustment management application 340 ofFIG. 3 in greater detail. As shown inFIG. 4 , theadjustment management application 340 includes a business data filter 410 and anadjustment document creator 420. As discussed above with regard toFIG. 3 , theadjustment management application 340 receives the payment andremittance data 325 from thefinancial institution 320 and theorder data 335 from theseller 330. The payment andremittance data 325 andorder data 335 are then passed to the business data filter 410 of theadjustment management application 340. - In operation, the business data filter 410 receives the
order data 335 and the payment andremittance data 325 and attempts to match the payment andremittance data 325 with one or more invoices included in the order data. If the business data filter 410 is able to match the payment andremittance data 325 with one or more invoices in theorder data 335, the business data filter sends postingdata 345 to theseller 330 to close out the transaction, as described above. If the business data filter 410 is not able to match the payment andremittance data 325 with one or more invoices in theorder data 335, then the payment andremittance data 325 is further processed by the business data filter as described below with regard toFIG. 6 . - For example, if the received order data matches an outstanding invoice number for a certain buyer and the amount of the received payment matches the invoiced amount, then posting
data 345 is sent to theseller 330 to post the received payment to the seller's accounting system. - However, if the amount of the received payment does not match the invoiced amount, then the business data filter 410 applies a series of business rules in order to attempt to match the
order data 335 and thepayment data 325, as further described below with regard toFIG. 6 . If the business data filter 410 is able to find a match after the application of the business rules, then the business data filter 410 sends postingdata 345 to theseller 330. Additionally, the business data filter 410 sends thepayment data 325 to theadjustment document creator 420 so that an adjustment document may be created. Theadjustment document 425 is then also sent to theseller 330. However, because the buyer's adjustment has satisfied the business rules, the buyer's adjustment may be automatically accepted by the seller without further human interaction or approval. - If the order data and payment data still do not match after the application of the business rules in the business data filter 410, then the
payment data 325 is still sent to theadjustment document creator 420 and an adjustment document is generated. However, the adjustment document that is created may not be automatically processed by the seller's accounting system because the adjustment did not satisfy the business rules. Additionally, the business rules applied by the business data filter may preferably be configured to be buyer specific, as further described below. - The structure of the adjustment approval forms and the routing of the approval forms are further described in U.S. patent application Ser. No. ______ filed ______, entitled “System And Method For Seller-Assisted Automated Payment Processing and Exception Management”, which is incorporated herein by reference in its entirety.
- The
adjustment document 425 preferably includes the payment data as well as all relevant data with regard to the buyer. The relevant data with regard to the buyer preferably includes the buyer's previous purchasing and payment activity including any credit rating, as well as seller-side information with regard to the buyer such as the seller's account representative for the buyer or any previous discounts given to the buyer. - The business data filter 410 may also seek to validate payment data when the buyer's information is missing from the transaction. For example, if the payment data does not include an indication of the buyer, the
business data filer 410 may attempt to match the payment amount or any other available information to all outstanding invoices for all buyers. If a match is discovered, the business data filter 410 may automatically prompt the user to confirm the attempted match from secondary criteria, for example, non-invoice identification fields. - Preferably, the transaction verification provided by the business rules includes the validation of the following aspects of the transaction. Validation of the customer information of the
buyer 310. Validation of the delivery information of the goods transferred to the buyer, preferably including, for example, the invoice and/or bill of lading, and the dollar amounts. Validation of the buyer's payment such as determining whether the buyer's payment is a duplicate of an already received payment or if the amount remitted by buyer differs from the invoiced amount by a sum less than a predetermined threshold tolerance, or if the total invoice amount is less then a predetermined amount. -
FIG. 5 illustrates an example of some of the types of informational sources that may be included in thepayment data 325. As discussed above, thepayment data 325 may include data derived fromXML documents 510,EDI documents 520,electronic data 540, and/or data fromweb services 530. Theelectronic data 540 may include electronic images of theremittance information 315, as described inFIG. 3 . Thepayment data 325 may be configured in any internal format desired by the financial institution that is capable of being parsed by theadjustment management application 340. - Thus, the present embodiment serves to automatically match payment data with invoice data. As mentioned above, the prior art methodologies for matching payment data with invoice data involved a great deal of manual effort and were quite slow. With the present embodiment, most incoming payments may be matched and processed automatically. Thus reducing effort and cost and providing a more accurate assessment of available cash.
- Additionally, the present embodiment is preferably directly integrated with the seller's financial institution. Consequently, no additional processing steps to inform the financial institution or internal accounting sub-divisions of the seller's account at the financial institution are necessary.
-
FIG. 6 illustrates aflowchart 600 of the operation of the adjustment management application in greater detail. First, the payment data and the order data are received at steps 601-602. Next, atstep 605, the payment data is received and batched by the financial institution. That is, the financial institution may accumulate a number of payments in a queue to form a batch. Then, a person at the seller may access the financial institution's records to process the batch of payments as a whole. - 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. Atstep 615, it is determined whether the payment includes an invoice number that matches an invoice number provided by the order data. If an 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, additional processing, such as human interaction by the seller may be required to match the received payment data with one or more invoices retrieved in the order data. Such further processing is further described in U.S. patent application Ser. No. ______ filed ______, entitled “System And Method For Seller-Assisted Automated Payment Processing and Exception Management”, which is incorporated herein by reference in its entirety. - Proceeding now to step 630, the received payment has been matched to a specific invoice number. 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. Atstep 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 invoiced amount by less than 1% or by 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 or in addition to 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 a discount 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, an adjustment document such as a G/L (General Ledger) write-off record is created to credit the difference between the invoiced 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 atstep 690. - If the invoice amount does not match after the application of the business rules, then the process proceeds to step 620 where further processing, such as human interaction by the seller may be required to match the received payment data with one or more invoices retrieved in the order data.
- The buyer-specific information may be originated for a buyer either by a pre-existing default, by direct programming by the seller, or by an automated analysis of the behaviors of a set of buyers. For example, the business data filter may be configured to dynamically increase the threshold percentage or other thresholds based on the size of the most recent invoice or the size of the payment. Additionally, for example, the threshold percentage or other thresholds may be dynamically changed based on the length of the relationship between the buyer and seller.
- Thus, the present system may provide for automated processing of payments from sellers when the sellers are claiming and adjustment such as a deduction. By automatically processing adjustments that fall within the pre-configured business rules, a large quantity of adjustments may be automatically handled by the system without requiring any human interaction. Instead, human interaction may only be required for the small number of adjustments that fall outside of the business rules. Consequently, because many adjustments/deductions may now be handled automatically, a significant cost reduction in worker-hours may be realized.
- Additionally, the present system automatically updates the seller's accounting system to include adjustment documentation such as a write-off record in the event of a deduction. Consequently, even though the buyer's adjustment is automatically processed, a record of the buyer's adjustments is included in the seller's accounting system if needed, for example for review or compliance purposes.
- Also, the present system may be directly integrated with the seller's financial institution. This allows for additional ease of implementation and speed of processing. However, the present system may also be hosted by a third party in communication with the financial institution and 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 adjustment management system of the present embodiments. Additionally, if the present automated adjustment management system is unable to automatically process the buyer's adjustment, an adjustment document may be created and routed to a human for approval or further processing. Such a system is described in U.S. patent application Ser. No. ______ filed ______, entitled “System And Method For Seller-Assisted Automated Payment Processing And Exception Management”, which is incorporated herein by reference in its entirety. Additionally, the present embodiment is preferably directly integrated with the seller's financial institution.
- While particular elements, embodiments and applications of the present invention have been shown and described, it is understood that the invention is not limited thereto since modifications may be made by those skilled in the art, particularly in light of the foregoing teaching. It is therefore contemplated by the appended claims to cover such modifications and incorporate those features that come within the spirit and scope of the invention.
Claims (26)
1. A method for automated adjustment processing, said method including:
receiving a payment from a buyer at a seller;
retrieving buyer-specific information for said buyer from said seller, said buyer-specific information including at least one outstanding invoice for said seller and at least one business rule;
applying said business rule of a comparison of said payment and said at least one invoice;
processing said payment when said payment matches said at least one outstanding invoice within the criteria of said business rule.
2. The method of claim 1 wherein said business rule is a buyer specific discount to said invoice.
3. The method of claim 1 wherein said business rule is a buyer specific numeric threshold difference in the amount of said payment and said invoice.
4. The method of claim 1 wherein said business rule is a buyer specific percentage threshold difference in the amount of said payment and said invoice.
5. The method of claim 1 wherein said business rule is a buyer specific decision to allow said buyer to pay less than the total amount of said invoice.
6. The method of claim 1 further including:
receiving an adjustment to said invoice before said receiving step; and
applying said adjustment to said invoice before applying said business rule
7. The method of claim 1 further including:
transmitting said payment to a sales adjustment document creator when said payment does not match said at least one outstanding invoice within the criteria of said business rule
8. The method of claim 7 further including:
transmitting posting data to said seller to notify said seller that said payment does not match at least one outstanding invoice.
9. A method for processing adjustments to a payment by a seller using seller-configurable business rules that may be varied for a plurality of buyers, said method including:
storing a first set of business rules at a seller for use in processing adjustments for a first buyer;
storing a second set of business rules at said seller for use in processing adjustments for a second buyer,
wherein said first set of business rules is not identical to said second set of business rules;
receiving a first payment from a first buyer at said seller;
receiving a second payment from a second buyer at said seller, both said first payment and said second payment requiring an adjustment;
processing an adjustment to said first payment using said first set of business rules; and
processing an adjustment to said second payment using said second set of business rules.
10. The method of claim 9 wherein at least one of said business rules in one of said first set of business rules and said second set of business rules is a buyer specific discount to said invoice.
11. The method of claim 9 wherein at least one of said business rules in one of said first set of business rules and said second set of business rules is a buyer specific numeric threshold difference in the amount of said payment and said invoice.
12. The method of claim 9 wherein at least one of said business rules in one of said first set of business rules and said second set of business rules is a buyer specific percentage threshold difference in the amount of said payment and said invoice.
13. The method of claim 9 wherein at least one of said business rules in one of said first set of business rules and said second set of business rules is a buyer specific decision to allow said buyer to pay less than the total amount of said invoice.
14. The method of claim 9 wherein said processing is performed by an Application Service Provider (ASP).
15. The method of claim 9 wherein said processing is performed at a financial institution.
16. The method of claim 9 wherein said processing is outsourced to a third party.
17. A system for automated processing of adjustments to payments submitted by a buyer to a seller, said system including:
a data source at a seller, said data source including a set of buyer-specific business rules configured for use in processing an adjustment to a payment by a buyer;
a business data filter receiving an outstanding invoice for said buyer from said seller and receiving a payment from a buyer, said payment requiring an adjustment,
wherein said business data filter receives said set of buyer-specific business rules from said data source and processes said payment by matching said payment to an outstanding invoice using said set of buyer-specific business rules.
18. The system of claim 17 wherein at least one of said business rules in one of said first set of business rules and said second set of business rules is a buyer specific discount to said invoice.
19. The system of claim 17 wherein at least one of said business rules is a buyer specific numeric threshold difference in the amount of said payment and said invoice.
20. The system of claim 17 wherein at least one of said business rules is a buyer specific percentage threshold difference in the amount of said payment and said invoice.
21. The system of claim 17 wherein at least one of said business rules is a buyer specific decision to allow said buyer to pay less than the total amount of said invoice.
22. A system for automated processing of adjustments to payments submitted by a buyer to a seller, said system including:
a data source at a seller, said data source including a set of buyer-specific business rules configured for use in processing an adjustment to a payment by a buyer;
a business data filter receiving an outstanding invoice for said buyer from said seller and receiving a payment from a buyer, said payment requiring an adjustment,
wherein said business data filter receives said set of buyer-specific business rules from said data source and processes said payment by matching said payment to an outstanding invoice using said set of buyer-specific business rules,
wherein said business data filter is an Application Service Provider (ASP).
23. A system for automated processing of adjustments to payments submitted by a buyer to a seller, said system including:
a data source at a seller, said data source including a set of buyer-specific business rules configured for use in processing an adjustment to a payment by a buyer;
a business data filter receiving an outstanding invoice for said buyer from said seller and receiving a payment from a buyer, said payment requiring an adjustment,
wherein said business data filter receives said set of buyer-specific business rules from said data source and processes said payment by matching said payment to an outstanding invoice using said set of buyer-specific business rules,
wherein said business data filter is a software application at a financial institution.
24. A method for automated adjustment processing, said method including:
receiving a payment from a buyer at a seller;
retrieving buyer-specific information for said buyer from said seller, said buyer-specific information including at least one outstanding invoice for said seller and at least one business rule;
applying said business rule of a comparison of said payment and said at least one invoice;
processing said payment when said payment matches said at least one outstanding invoice within the criteria of said business rule,
wherein said processing is performed by an Application Service Provider (ASP).
25. A method for automated adjustment processing, said method including:
receiving a payment from a buyer at a seller;
retrieving buyer-specific information for said buyer from said seller, said buyer-specific information including at least one outstanding invoice for said seller and at least one business rule;
applying said business rule of a comparison of said payment and said at least one invoice;
processing said payment when said payment matches said at least one outstanding invoice within the criteria of said business rule,
wherein said processing is performed by a software application at a financial institution.
26. A method for automated adjustment processing, said method including:
receiving a payment from a buyer at a seller;
retrieving buyer-specific information for said buyer from said seller, said buyer-specific information including at least one outstanding invoice for said seller and at least one business rule;
applying said business rule of a comparison of said payment and said at least one invoice;
processing said payment when said payment matches said at least one outstanding invoice within the criteria of said business rule,
wherein said processing is performed by a software application that has been outsourced to a third party.
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/865,076 US20050075978A1 (en) | 2003-10-02 | 2004-06-10 | System and method for automated payment and adjustment processing |
US11/327,802 US20060112010A1 (en) | 2003-10-02 | 2006-01-06 | System and method for automated payment and adjustment processing |
US11/326,950 US20060116956A1 (en) | 2003-10-02 | 2006-01-06 | System and method for automated payment and adjustment processing |
US11/544,353 US8498935B2 (en) | 2003-10-02 | 2006-10-04 | System and method for automated payment and adjustment processing |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US50822103P | 2003-10-02 | 2003-10-02 | |
US10/865,076 US20050075978A1 (en) | 2003-10-02 | 2004-06-10 | System and method for automated payment and adjustment processing |
Related Child Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/327,802 Division US20060112010A1 (en) | 2003-10-02 | 2006-01-06 | System and method for automated payment and adjustment processing |
US11/326,950 Division US20060116956A1 (en) | 2003-10-02 | 2006-01-06 | System and method for automated payment and adjustment processing |
US11/544,353 Continuation US8498935B2 (en) | 2003-10-02 | 2006-10-04 | System and method for automated payment and adjustment processing |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050075978A1 true US20050075978A1 (en) | 2005-04-07 |
Family
ID=34465079
Family Applications (6)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/865,076 Abandoned US20050075978A1 (en) | 2003-10-02 | 2004-06-10 | System and method for automated payment and adjustment processing |
US10/866,015 Abandoned US20050075960A1 (en) | 2003-10-02 | 2004-06-10 | System and method for automated incoming payment and invoice reconciliation |
US10/865,997 Abandoned US20050075979A1 (en) | 2003-10-02 | 2004-06-10 | System and method for seller-assisted automated payment processing and exception management |
US11/326,950 Abandoned US20060116956A1 (en) | 2003-10-02 | 2006-01-06 | System and method for automated payment and adjustment processing |
US11/327,802 Abandoned US20060112010A1 (en) | 2003-10-02 | 2006-01-06 | System and method for automated payment and adjustment processing |
US11/544,353 Expired - Fee Related US8498935B2 (en) | 2003-10-02 | 2006-10-04 | System and method for automated payment and adjustment processing |
Family Applications After (5)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/866,015 Abandoned US20050075960A1 (en) | 2003-10-02 | 2004-06-10 | System and method for automated incoming payment and invoice reconciliation |
US10/865,997 Abandoned US20050075979A1 (en) | 2003-10-02 | 2004-06-10 | System and method for seller-assisted automated payment processing and exception management |
US11/326,950 Abandoned US20060116956A1 (en) | 2003-10-02 | 2006-01-06 | System and method for automated payment and adjustment processing |
US11/327,802 Abandoned US20060112010A1 (en) | 2003-10-02 | 2006-01-06 | System and method for automated payment and adjustment processing |
US11/544,353 Expired - Fee Related US8498935B2 (en) | 2003-10-02 | 2006-10-04 | System and method for automated payment and adjustment processing |
Country Status (6)
Country | Link |
---|---|
US (6) | US20050075978A1 (en) |
EP (2) | EP1668453A2 (en) |
JP (2) | JP2007507800A (en) |
CN (2) | CN1926568A (en) |
CA (2) | CA2540702A1 (en) |
WO (3) | WO2005038557A2 (en) |
Cited By (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060059026A1 (en) * | 2004-08-24 | 2006-03-16 | Oracle International Corporation | Compliance workbench |
US20060112010A1 (en) * | 2003-10-02 | 2006-05-25 | Old World Industries, Inc. | System and method for automated payment and adjustment processing |
US20070185810A1 (en) * | 2005-09-30 | 2007-08-09 | American Express Travel Related Services Company Inc. | System, method, and computer program product for saving and investing through use of transaction cards |
US20070208451A1 (en) * | 2006-03-02 | 2007-09-06 | Wolfgang Jacobi | Part of an electrical connecting device |
US20080183519A1 (en) * | 2006-08-03 | 2008-07-31 | Oracle International Corporation | Business process for ultra vires transactions |
US20090248467A1 (en) * | 2002-12-06 | 2009-10-01 | Ocwen Financial Corporation | Expense tracking, electronic ordering, invoice presentment, and payment system and method |
US7680737B2 (en) | 2006-07-06 | 2010-03-16 | Moneygram International, Inc. | Systems and methods for processing payments with payment review features |
US20110010278A1 (en) * | 2002-12-06 | 2011-01-13 | Altisource Portfolio Solutions | Expense tracking, electronic ordering, invoice presentment, and payment system and method |
US20110184843A1 (en) * | 2008-01-31 | 2011-07-28 | Bill.Com, Inc. | Enhanced electronic anonymous payment system |
US20110184868A1 (en) * | 2008-01-31 | 2011-07-28 | Bill.Com, Inc. | Enhanced invitation process for electronic billing and payment system |
US20110196786A1 (en) * | 2008-01-31 | 2011-08-11 | Rene Lacerte | Determining trustworthiness and familiarity of users of an electronic billing and payment system |
US20110270749A1 (en) * | 2010-04-30 | 2011-11-03 | Robert Bennett | Electronic invoice presentation and payment system |
US8521613B2 (en) | 2002-12-06 | 2013-08-27 | Altisource Solutions S.à r.l. | Expense tracking, electronic ordering, invoice presentment, and payment system and method |
US20140222669A1 (en) * | 2013-02-07 | 2014-08-07 | Jpmorgan Chase Bank, N.A. | Integrated Electronic Cash Flow Management System and Method |
US8819789B2 (en) | 2012-03-07 | 2014-08-26 | Bill.Com, Inc. | Method and system for using social networks to verify entity affiliations and identities |
US9141991B2 (en) | 2008-01-31 | 2015-09-22 | Bill.Com, Inc. | Enhanced electronic data and metadata interchange system and process for electronic billing and payment system |
US10019743B1 (en) | 2014-09-19 | 2018-07-10 | Altisource S.á r.l. | Methods and systems for auto expanding vendor selection |
US10068243B2 (en) | 2013-11-20 | 2018-09-04 | Mastercard International Incorporated | Method and system for processing a discount |
US10115137B2 (en) | 2013-03-14 | 2018-10-30 | Bill.Com, Inc. | System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network |
US20190095915A1 (en) * | 2017-09-28 | 2019-03-28 | Mastercard International Incorporated | System and method for managing recurring payments |
US10410191B2 (en) | 2013-03-14 | 2019-09-10 | Bill.Com, Llc | System and method for scanning and processing of payment documentation in an integrated partner platform |
US10417674B2 (en) | 2013-03-14 | 2019-09-17 | Bill.Com, Llc | System and method for sharing transaction information by object tracking of inter-entity transactions and news streams |
US10572921B2 (en) | 2013-07-03 | 2020-02-25 | Bill.Com, Llc | System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network |
US10769686B2 (en) | 2008-01-31 | 2020-09-08 | Bill.Com Llc | Enhanced invitation process for electronic billing and payment system |
Families Citing this family (80)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050049964A1 (en) * | 2003-01-14 | 2005-03-03 | Winterer Mary Jo | Financial transaction card with automatic payment feature |
US8799153B2 (en) | 1998-08-31 | 2014-08-05 | Mastercard International Incorporated | Systems and methods for appending supplemental payment data to a transaction message |
US6315193B1 (en) * | 1998-08-31 | 2001-11-13 | Mastercard International Incorporated | Financial transaction card with installment loan feature |
CA2404221C (en) | 2000-03-29 | 2013-12-17 | Mastercard International Incorporated | Method and system for processing messages in a bill payment and presentment system over a communications network |
US7146338B2 (en) | 2001-06-28 | 2006-12-05 | Checkfree Services Corporation | Inter-network financial service |
US20080015982A1 (en) * | 2000-09-20 | 2008-01-17 | Jeremy Sokolic | Funds transfer method and system including payment enabled invoices |
US20040128227A1 (en) * | 2002-12-30 | 2004-07-01 | Fannie Mae | Cash flow system and method |
US20040128235A1 (en) | 2002-12-30 | 2004-07-01 | Fannie Mae | Cash flow aggregation system and method |
WO2004061735A1 (en) * | 2002-12-30 | 2004-07-22 | Fannie Mae | System and method for creating financial assets |
US20040128228A1 (en) * | 2002-12-30 | 2004-07-01 | Fannie Mae | Servicer compensation system and method |
US8175938B2 (en) | 2004-04-13 | 2012-05-08 | Ebay Inc. | Method and system for facilitating merchant-initiated online payments |
US8682784B2 (en) * | 2004-07-16 | 2014-03-25 | Ebay, Inc. | Method and system to process credit card payment transactions initiated by a merchant |
US20070094136A1 (en) * | 2005-10-24 | 2007-04-26 | Robert Reiner | Method of selecting line item kind for invoice database |
US7596519B2 (en) * | 2005-11-14 | 2009-09-29 | Sap Ag | System and method for facilitating open item clearance |
US7664704B2 (en) * | 2005-12-30 | 2010-02-16 | Sap Ag | Clearing receivables with improved search |
US7885891B1 (en) | 2006-03-22 | 2011-02-08 | Fannie Mae | Portal tool and method for securitizing excess servicing fees |
US8732044B2 (en) | 2006-05-23 | 2014-05-20 | Mastercard International Incorporated | Electronic transaction apparatus and method |
US20080021822A1 (en) * | 2006-07-18 | 2008-01-24 | Jpmorgan Chase Bank, N.A. | Method and system for receivables management |
US20100094735A1 (en) * | 2006-11-15 | 2010-04-15 | Charles Reynolds | Methods and systems for automated payments |
US20080133388A1 (en) * | 2006-12-01 | 2008-06-05 | Sergey Alekseev | Invoice exception management |
US20090083179A1 (en) * | 2007-04-18 | 2009-03-26 | Jonathan Gustave | Web-accessible payment processing system |
WO2008094904A1 (en) * | 2007-01-29 | 2008-08-07 | Ipp Of America, Inc. | Cross-border remittance |
US20080255972A1 (en) * | 2007-04-10 | 2008-10-16 | Invoice Compliance Experts | Legal billing enhancement method and apparatus |
US20080288376A1 (en) | 2007-04-27 | 2008-11-20 | Cashedge, Inc. | Centralized payment hub method and system |
US20100262538A1 (en) * | 2007-06-16 | 2010-10-14 | Ronald John Rosenberger | Methods and systems for check or electronic bill payment using portional crediting from additional available cash and credit balances |
US7974922B1 (en) | 2007-09-24 | 2011-07-05 | Wells Fargo Bank, N.A. | Computer-driven exception processing system |
US8065189B1 (en) | 2008-01-15 | 2011-11-22 | SciQuest Inc. | Method, medium, and system for automatically moving items from a first shopping cart to a second shopping cart |
US8694429B1 (en) | 2008-01-15 | 2014-04-08 | Sciquest, Inc. | Identifying and resolving discrepancies between purchase documents and invoices |
US8065202B1 (en) | 2008-01-15 | 2011-11-22 | SciQuest Inc. | Form management in an electronic procurement system |
US8359245B1 (en) | 2008-01-15 | 2013-01-22 | SciQuest Inc. | Taxonomy and data structure for an electronic procurement system |
US8930244B2 (en) * | 2008-01-15 | 2015-01-06 | Sciquest, Inc. | Method, medium, and system for processing requisitions |
US8112317B1 (en) | 2008-01-15 | 2012-02-07 | SciQuest Inc. | Providing substitute items when ordered item is unavailable |
US8285573B1 (en) | 2008-01-15 | 2012-10-09 | SciQuest Inc. | Prioritizing orders/receipt of items between users |
US20140129431A1 (en) * | 2008-01-31 | 2014-05-08 | Bill.Com, Inc. | Enhanced System and Method For Private Interbank Clearing System |
JP2009238100A (en) * | 2008-03-28 | 2009-10-15 | Fujitsu Ltd | Sales support apparatus, sales support program, and sales support method |
US9245291B1 (en) | 2008-05-27 | 2016-01-26 | SciQuest Inc. | Method, medium, and system for purchase requisition importation |
US8069096B1 (en) | 2008-05-27 | 2011-11-29 | SciQuest Inc. | Multi-constituent attribution of a vendor's product catalog |
US8756117B1 (en) | 2008-05-27 | 2014-06-17 | Sciquest, Inc. | Sku based contract management in an electronic procurement system |
US10970777B2 (en) | 2008-09-15 | 2021-04-06 | Mastercard International Incorporated | Apparatus and method for bill payment card enrollment |
US8595134B2 (en) | 2010-02-12 | 2013-11-26 | Mastercard International Incorporated | Apparatus and method for bill presentment and payment |
CN102368341A (en) * | 2011-10-31 | 2012-03-07 | 浪潮齐鲁软件产业有限公司 | Self-service method for writing value added tax invoices |
US10482396B2 (en) * | 2012-03-16 | 2019-11-19 | Refinitiv Us Organization Llc | System and method for automated compliance verification |
US20140032427A1 (en) * | 2012-05-16 | 2014-01-30 | Inttra Inc. | Invoice and Freight Statement Matching and Dispute Resolution |
US8660866B1 (en) * | 2012-06-08 | 2014-02-25 | Atlas Financial Partners LLC | Methods and systems for administering life insurance products through classifying insured lives to allocate costs |
CN103595613B (en) * | 2012-08-13 | 2017-06-06 | 阿里巴巴集团控股有限公司 | Instant communication client, instant communication server and instant communication method |
US10282712B2 (en) * | 2013-02-07 | 2019-05-07 | Jpmorgan Chase Bank, N.A. | Integrated electronic disbursement and cash flow management system and method |
US10417622B2 (en) * | 2013-11-19 | 2019-09-17 | Oracle International Corporation | Configurable invoice matching optimization system |
GB2525191A (en) * | 2014-04-14 | 2015-10-21 | Mastercard International Inc | Transaction identification and recognition |
US20150324872A1 (en) * | 2014-05-09 | 2015-11-12 | Bank Of America Corporation | Matching Data From Various Channels |
US10241989B2 (en) * | 2014-05-21 | 2019-03-26 | Adobe Inc. | Displaying document modifications using a timeline |
CN105630785A (en) * | 2014-10-27 | 2016-06-01 | 航天信息股份有限公司 | Invoice use abnormity early-warning method and system |
US11170019B1 (en) | 2015-10-06 | 2021-11-09 | Wells Fargo Bank, N.A. | Data field transaction repair interface |
US10127209B2 (en) | 2015-11-24 | 2018-11-13 | Bank Of America Corporation | Transforming unstructured documents |
US10410168B2 (en) | 2015-11-24 | 2019-09-10 | Bank Of America Corporation | Preventing restricted trades using physical documents |
US10430760B2 (en) | 2015-11-24 | 2019-10-01 | Bank Of America Corporation | Enhancing communications based on physical trade documents |
US10319025B2 (en) | 2015-11-24 | 2019-06-11 | Bank Of America Corporation | Executing terms of physical trade documents |
US20180047076A1 (en) * | 2016-08-09 | 2018-02-15 | Kathlynn Fekete | Sale service process assistance |
US11646114B2 (en) * | 2016-08-26 | 2023-05-09 | Sap Se | Method and system for processing of electronic medical invoices |
US11087296B1 (en) * | 2016-09-06 | 2021-08-10 | Wells Fargo Bank, N.A. | Programmatic reconciliation of electronic receivables |
CN106651396A (en) * | 2016-12-21 | 2017-05-10 | 世纪禾光科技发展(北京)有限公司 | Client identification method and device |
CN108830664A (en) * | 2017-05-05 | 2018-11-16 | 平安科技(深圳)有限公司 | Difference electronics indigo plant ticket generation method, equipment and computer readable storage medium |
FR3069083A1 (en) * | 2017-07-12 | 2019-01-18 | Compagnie De L'arc Atlantique | METHOD FOR INCREASING THE ROBUSTNESS OF A PAYMENT |
CN107180345A (en) * | 2017-07-20 | 2017-09-19 | 东莞市盟大塑化科技有限公司 | A kind of method of commerce paid under online trading line |
WO2019022716A1 (en) * | 2017-07-25 | 2019-01-31 | Visa International Service Association | Real time cross-matching data |
CN110019967B (en) * | 2017-12-07 | 2022-04-29 | 航天信息股份有限公司 | Method and system for acquiring abnormal invoice information of enterprise |
WO2019186935A1 (en) * | 2018-03-29 | 2019-10-03 | Bank Invoice株式会社 | Information processing device, information processing method and program |
US11645686B2 (en) | 2018-12-05 | 2023-05-09 | Sap Se | Graphical approach to multi-matching |
JP7056930B2 (en) * | 2018-12-21 | 2022-04-19 | 株式会社アライ | Business management system |
US11100409B2 (en) * | 2019-02-15 | 2021-08-24 | Highradius Corporation | Machine learning assisted transaction component settlement |
US11587093B2 (en) * | 2019-03-13 | 2023-02-21 | Stripe, Inc. | Optimized dunning using machine-learned model |
US11521249B2 (en) * | 2019-03-13 | 2022-12-06 | Stripe, Inc. | Auto-reconciliation |
US11410246B2 (en) * | 2019-06-06 | 2022-08-09 | Salus Finance, LLC | System and method for consolidation, reconciliation and payment management |
US11341547B1 (en) * | 2019-06-19 | 2022-05-24 | Amazon Technologies, Inc. | Real-time detection of duplicate data records |
CN110969408B (en) * | 2019-11-08 | 2024-04-05 | 国网辽宁省电力有限公司 | Material settlement whole-flow integrated management platform generation system and method |
LU101595B1 (en) * | 2020-01-07 | 2021-07-07 | Creopay S A R L | System and method for managing unpaid debts |
AU2021428224A1 (en) * | 2021-02-18 | 2023-09-21 | Xero Limited | Systems and method for generating labelled datasets |
US11616744B2 (en) | 2021-07-29 | 2023-03-28 | Intuit Inc. | Context-dependent message extraction and transformation |
US11809390B2 (en) | 2021-07-29 | 2023-11-07 | Intuit Inc. | Context-dependent event cleaning and publication |
US20230035551A1 (en) * | 2021-07-29 | 2023-02-02 | Intuit Inc. | Multiple source audit log generation |
US11704669B1 (en) | 2022-01-03 | 2023-07-18 | Bank Of America Corporation | Dynamic contactless payment processing based on real-time contextual information |
Citations (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3363362A (en) * | 1965-07-09 | 1968-01-16 | Paul L. Jolley | Self-loading transporter for composite toy vehicles |
US5121945A (en) * | 1988-04-20 | 1992-06-16 | Remittance Technology Corporation | Financial data processing system |
US5920847A (en) * | 1993-11-01 | 1999-07-06 | Visa International Service Association | Electronic bill pay system |
US5940813A (en) * | 1996-07-26 | 1999-08-17 | Citibank, N.A. | Process facility management matrix and system and method for performing batch, processing in an on-line environment |
US6070150A (en) * | 1996-10-18 | 2000-05-30 | Microsoft Corporation | Electronic bill presentment and payment system |
US20020007302A1 (en) * | 2000-03-06 | 2002-01-17 | Work Bruce V. | Method and apparatus for tracking vendor compliance with purchaser guidelines and related method for the commercial distribution of software and hardware implementing same |
US20020038305A1 (en) * | 2000-08-04 | 2002-03-28 | Bottomline Technologies (De) Inc. | Automated invoice receipt and management system |
US20020052846A1 (en) * | 2000-10-18 | 2002-05-02 | Webmoney Corporation | Electronic account settlement apparatus electronic settlement method, storage medium and computer data signal |
US20020107794A1 (en) * | 2001-02-05 | 2002-08-08 | Furphy Thomas W. | Method and system for processing transactions |
US20020111906A1 (en) * | 1997-12-19 | 2002-08-15 | Checkfree Corporation | Remittance payment processing with account scheming and/or validation |
US20020116334A1 (en) * | 2001-02-22 | 2002-08-22 | International Business Machines Corporation | Invoice processing system |
US20020138426A1 (en) * | 2001-03-26 | 2002-09-26 | Streamtrans, Inc. | Concentration of electronic payments |
US20020194125A1 (en) * | 1998-07-01 | 2002-12-19 | Michael F.Krieger | Method and software article for selecting electronic payment of vendors in an automated payment environment |
US20030018550A1 (en) * | 2000-02-22 | 2003-01-23 | Rotman Frank Lewis | Methods and systems for providing transaction data |
US20030158811A1 (en) * | 2001-07-18 | 2003-08-21 | Ventanex | System and method for rules based electronic funds transaction processing |
US20040010465A1 (en) * | 2002-05-20 | 2004-01-15 | Cliff Michalski | Method and apparatus for exception based payment posting |
US20040093278A1 (en) * | 1998-08-06 | 2004-05-13 | Burchetta James D. | Computerized dispute resolution system and method |
US20040148234A1 (en) * | 2000-02-18 | 2004-07-29 | Oracle Corporation | Methods and systems for online self-service receivables management and automated online receivables dispute resolution |
US6832212B1 (en) * | 1997-09-30 | 2004-12-14 | Ncr Corporation | Method and apparatus for manipulating billing and payment information within a browser interface system |
US6856970B1 (en) * | 2000-09-26 | 2005-02-15 | Bottomline Technologies | Electronic financial transaction system |
US20050125340A1 (en) * | 2003-06-06 | 2005-06-09 | Huey Lin | Automatic dispute resolution |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6223168B1 (en) * | 1995-07-25 | 2001-04-24 | Bottomline Technologies, Inc. | Automatic remittance delivery system |
WO1997029445A1 (en) * | 1996-02-09 | 1997-08-14 | Citibank, N.A. | Invoice purchase order system |
US6363362B1 (en) * | 1999-04-07 | 2002-03-26 | Checkfree Services Corporation | Technique for integrating electronic accounting systems with an electronic payment system |
US7340433B1 (en) * | 1999-07-30 | 2008-03-04 | Orbian Management Limited | System and method of transaction settlement using trade credit |
CA2310589A1 (en) * | 2000-02-06 | 2001-12-02 | Jason Frank Saxon | System and method for ordering products or services |
US7181422B1 (en) * | 2000-10-20 | 2007-02-20 | Tranquilmoney, Inc. | Segregation and management of financial assets by rules |
US8326754B2 (en) * | 2001-02-05 | 2012-12-04 | Oracle International Corporation | Method and system for processing transactions |
US6662588B2 (en) * | 2001-05-14 | 2003-12-16 | Vantage Equipment Corp. | Modular liquid-cooled air conditioning system |
US7229811B2 (en) * | 2001-08-03 | 2007-06-12 | Genencor International, Inc. | 2,5-diketo-D-gluconic acid (2,5-DKG) permeases |
US20040034596A1 (en) * | 2002-08-19 | 2004-02-19 | Jeremy Light | Electronic payment management |
US7089275B2 (en) * | 2003-01-29 | 2006-08-08 | Sun Microsystems, Inc. | Block-partitioned technique for solving a system of linear equations represented by a matrix with static and dynamic entries |
US20060010016A1 (en) * | 2003-05-01 | 2006-01-12 | Kossol Joyce L | System and method for reconciling an insurance payment with an insurance claim |
US20050075978A1 (en) * | 2003-10-02 | 2005-04-07 | Old World Industries | System and method for automated payment and adjustment processing |
-
2004
- 2004-06-10 US US10/865,076 patent/US20050075978A1/en not_active Abandoned
- 2004-06-10 US US10/866,015 patent/US20050075960A1/en not_active Abandoned
- 2004-06-10 US US10/865,997 patent/US20050075979A1/en not_active Abandoned
- 2004-09-14 EP EP04784087A patent/EP1668453A2/en not_active Withdrawn
- 2004-09-14 JP JP2006533920A patent/JP2007507800A/en active Pending
- 2004-09-14 CA CA002540702A patent/CA2540702A1/en not_active Abandoned
- 2004-09-14 EP EP04784086A patent/EP1668452A4/en not_active Withdrawn
- 2004-09-14 JP JP2006533919A patent/JP2007507799A/en active Pending
- 2004-09-14 WO PCT/US2004/030255 patent/WO2005038557A2/en active Application Filing
- 2004-09-14 CN CNA2004800357579A patent/CN1926568A/en active Pending
- 2004-09-14 WO PCT/US2004/030112 patent/WO2005038556A2/en active Application Filing
- 2004-09-14 WO PCT/US2004/030113 patent/WO2005040973A2/en active Application Filing
- 2004-09-14 CA CA002540654A patent/CA2540654A1/en not_active Abandoned
- 2004-09-14 CN CNA2004800347257A patent/CN1942890A/en active Pending
-
2006
- 2006-01-06 US US11/326,950 patent/US20060116956A1/en not_active Abandoned
- 2006-01-06 US US11/327,802 patent/US20060112010A1/en not_active Abandoned
- 2006-10-04 US US11/544,353 patent/US8498935B2/en not_active Expired - Fee Related
Patent Citations (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3363362A (en) * | 1965-07-09 | 1968-01-16 | Paul L. Jolley | Self-loading transporter for composite toy vehicles |
US5121945A (en) * | 1988-04-20 | 1992-06-16 | Remittance Technology Corporation | Financial data processing system |
US5920847A (en) * | 1993-11-01 | 1999-07-06 | Visa International Service Association | Electronic bill pay system |
US5940813A (en) * | 1996-07-26 | 1999-08-17 | Citibank, N.A. | Process facility management matrix and system and method for performing batch, processing in an on-line environment |
US6070150A (en) * | 1996-10-18 | 2000-05-30 | Microsoft Corporation | Electronic bill presentment and payment system |
US6832212B1 (en) * | 1997-09-30 | 2004-12-14 | Ncr Corporation | Method and apparatus for manipulating billing and payment information within a browser interface system |
US20020111906A1 (en) * | 1997-12-19 | 2002-08-15 | Checkfree Corporation | Remittance payment processing with account scheming and/or validation |
US20020194125A1 (en) * | 1998-07-01 | 2002-12-19 | Michael F.Krieger | Method and software article for selecting electronic payment of vendors in an automated payment environment |
US20040093278A1 (en) * | 1998-08-06 | 2004-05-13 | Burchetta James D. | Computerized dispute resolution system and method |
US20040148234A1 (en) * | 2000-02-18 | 2004-07-29 | Oracle Corporation | Methods and systems for online self-service receivables management and automated online receivables dispute resolution |
US20030018550A1 (en) * | 2000-02-22 | 2003-01-23 | Rotman Frank Lewis | Methods and systems for providing transaction data |
US20020007302A1 (en) * | 2000-03-06 | 2002-01-17 | Work Bruce V. | Method and apparatus for tracking vendor compliance with purchaser guidelines and related method for the commercial distribution of software and hardware implementing same |
US20020038305A1 (en) * | 2000-08-04 | 2002-03-28 | Bottomline Technologies (De) Inc. | Automated invoice receipt and management system |
US6856970B1 (en) * | 2000-09-26 | 2005-02-15 | Bottomline Technologies | Electronic financial transaction system |
US20020052846A1 (en) * | 2000-10-18 | 2002-05-02 | Webmoney Corporation | Electronic account settlement apparatus electronic settlement method, storage medium and computer data signal |
US20020107794A1 (en) * | 2001-02-05 | 2002-08-08 | Furphy Thomas W. | Method and system for processing transactions |
US20020116334A1 (en) * | 2001-02-22 | 2002-08-22 | International Business Machines Corporation | Invoice processing system |
US20020138426A1 (en) * | 2001-03-26 | 2002-09-26 | Streamtrans, Inc. | Concentration of electronic payments |
US20030158811A1 (en) * | 2001-07-18 | 2003-08-21 | Ventanex | System and method for rules based electronic funds transaction processing |
US20040010465A1 (en) * | 2002-05-20 | 2004-01-15 | Cliff Michalski | Method and apparatus for exception based payment posting |
US20050125340A1 (en) * | 2003-06-06 | 2005-06-09 | Huey Lin | Automatic dispute resolution |
Cited By (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110010278A1 (en) * | 2002-12-06 | 2011-01-13 | Altisource Portfolio Solutions | Expense tracking, electronic ordering, invoice presentment, and payment system and method |
US10127558B2 (en) * | 2002-12-06 | 2018-11-13 | Altisource S.À R.L. | Expense tracking, electronic ordering, invoice presentment, and payment system and method |
US8521613B2 (en) | 2002-12-06 | 2013-08-27 | Altisource Solutions S.à r.l. | Expense tracking, electronic ordering, invoice presentment, and payment system and method |
US8266028B2 (en) | 2002-12-06 | 2012-09-11 | Altisource Solutions S.à r.l. | Expense tracking, electronic ordering, invoice presentment, and payment system and method |
US20090248467A1 (en) * | 2002-12-06 | 2009-10-01 | Ocwen Financial Corporation | Expense tracking, electronic ordering, invoice presentment, and payment system and method |
US8548877B2 (en) | 2002-12-06 | 2013-10-01 | Altisource Solutions S.à r.l. | Expense tracking, electronic ordering, invoice presentment, and payment system and method |
US8498935B2 (en) * | 2003-10-02 | 2013-07-30 | Stacy A. Leavitt | System and method for automated payment and adjustment processing |
US20070038564A1 (en) * | 2003-10-02 | 2007-02-15 | Leavitt Stacy A | System and method for automated payment and adjustment processing |
US20060112010A1 (en) * | 2003-10-02 | 2006-05-25 | Old World Industries, Inc. | System and method for automated payment and adjustment processing |
US20060059026A1 (en) * | 2004-08-24 | 2006-03-16 | Oracle International Corporation | Compliance workbench |
US7904386B2 (en) * | 2005-09-30 | 2011-03-08 | American Express Travel Related Services Company, Inc. | System, method, and computer program product for saving and investing through use of transaction cards |
US20110125637A1 (en) * | 2005-09-30 | 2011-05-26 | American Express Travel Related Services Company, Inc. | System, method, and computer program product for saving and investing through use of transaction cards |
US8417635B2 (en) * | 2005-09-30 | 2013-04-09 | American Express Travel Related Services Company, Inc. | System, method, and computer program product for saving and investing through use of transaction cards |
US20070185810A1 (en) * | 2005-09-30 | 2007-08-09 | American Express Travel Related Services Company Inc. | System, method, and computer program product for saving and investing through use of transaction cards |
US20070208451A1 (en) * | 2006-03-02 | 2007-09-06 | Wolfgang Jacobi | Part of an electrical connecting device |
US8655778B2 (en) | 2006-07-06 | 2014-02-18 | Moneygram International, Inc. | Systems and methods for processing payments with payment review features |
US20100169216A1 (en) * | 2006-07-06 | 2010-07-01 | Moneygram International, Inc. | Systems and methods for processing payments with payment review features |
US7680737B2 (en) | 2006-07-06 | 2010-03-16 | Moneygram International, Inc. | Systems and methods for processing payments with payment review features |
US10453029B2 (en) * | 2006-08-03 | 2019-10-22 | Oracle International Corporation | Business process for ultra transactions |
US20080183519A1 (en) * | 2006-08-03 | 2008-07-31 | Oracle International Corporation | Business process for ultra vires transactions |
US8738483B2 (en) | 2008-01-31 | 2014-05-27 | Bill.Com, Inc. | Enhanced invitation process for electronic billing and payment system |
US20110196786A1 (en) * | 2008-01-31 | 2011-08-11 | Rene Lacerte | Determining trustworthiness and familiarity of users of an electronic billing and payment system |
US9141991B2 (en) | 2008-01-31 | 2015-09-22 | Bill.Com, Inc. | Enhanced electronic data and metadata interchange system and process for electronic billing and payment system |
US10769686B2 (en) | 2008-01-31 | 2020-09-08 | Bill.Com Llc | Enhanced invitation process for electronic billing and payment system |
US10043201B2 (en) | 2008-01-31 | 2018-08-07 | Bill.Com, Inc. | Enhanced invitation process for electronic billing and payment system |
US20110184843A1 (en) * | 2008-01-31 | 2011-07-28 | Bill.Com, Inc. | Enhanced electronic anonymous payment system |
US20110184868A1 (en) * | 2008-01-31 | 2011-07-28 | Bill.Com, Inc. | Enhanced invitation process for electronic billing and payment system |
US20110270749A1 (en) * | 2010-04-30 | 2011-11-03 | Robert Bennett | Electronic invoice presentation and payment system |
US8819789B2 (en) | 2012-03-07 | 2014-08-26 | Bill.Com, Inc. | Method and system for using social networks to verify entity affiliations and identities |
US9413737B2 (en) | 2012-03-07 | 2016-08-09 | Bill.Com, Inc. | Method and system for using social networks to verify entity affiliations and identities |
US9633353B2 (en) | 2012-03-07 | 2017-04-25 | Bill.Com, Inc. | Method and system for using social networks to verify entity affiliations and identities |
US10387858B2 (en) * | 2013-02-07 | 2019-08-20 | Jpmorgan Chase Bank, N.A. | Integrated electronic cash flow management system and method |
US20140222669A1 (en) * | 2013-02-07 | 2014-08-07 | Jpmorgan Chase Bank, N.A. | Integrated Electronic Cash Flow Management System and Method |
US10115137B2 (en) | 2013-03-14 | 2018-10-30 | Bill.Com, Inc. | System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network |
US10410191B2 (en) | 2013-03-14 | 2019-09-10 | Bill.Com, Llc | System and method for scanning and processing of payment documentation in an integrated partner platform |
US10417674B2 (en) | 2013-03-14 | 2019-09-17 | Bill.Com, Llc | System and method for sharing transaction information by object tracking of inter-entity transactions and news streams |
US10572921B2 (en) | 2013-07-03 | 2020-02-25 | Bill.Com, Llc | System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network |
US11080668B2 (en) | 2013-07-03 | 2021-08-03 | Bill.Com, Llc | System and method for scanning and processing of payment documentation in an integrated partner platform |
US11176583B2 (en) | 2013-07-03 | 2021-11-16 | Bill.Com, Llc | System and method for sharing transaction information by object |
US11367114B2 (en) | 2013-07-03 | 2022-06-21 | Bill.Com, Llc | System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network |
US11803886B2 (en) | 2013-07-03 | 2023-10-31 | Bill.Com, Llc | System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network |
US10068243B2 (en) | 2013-11-20 | 2018-09-04 | Mastercard International Incorporated | Method and system for processing a discount |
US10019743B1 (en) | 2014-09-19 | 2018-07-10 | Altisource S.á r.l. | Methods and systems for auto expanding vendor selection |
US20190095915A1 (en) * | 2017-09-28 | 2019-03-28 | Mastercard International Incorporated | System and method for managing recurring payments |
Also Published As
Publication number | Publication date |
---|---|
CN1926568A (en) | 2007-03-07 |
US20070038564A1 (en) | 2007-02-15 |
WO2005040973A3 (en) | 2006-09-14 |
WO2005038556A3 (en) | 2006-08-10 |
US20060116956A1 (en) | 2006-06-01 |
CN1942890A (en) | 2007-04-04 |
WO2005038556A9 (en) | 2005-08-11 |
WO2005038557A2 (en) | 2005-04-28 |
US20060112010A1 (en) | 2006-05-25 |
EP1668452A4 (en) | 2007-02-28 |
CA2540702A1 (en) | 2005-05-06 |
CA2540654A1 (en) | 2005-04-28 |
WO2005038557A3 (en) | 2006-08-10 |
EP1668452A2 (en) | 2006-06-14 |
EP1668453A2 (en) | 2006-06-14 |
JP2007507800A (en) | 2007-03-29 |
JP2007507799A (en) | 2007-03-29 |
WO2005038556A2 (en) | 2005-04-28 |
US20050075960A1 (en) | 2005-04-07 |
WO2005040973A2 (en) | 2005-05-06 |
US8498935B2 (en) | 2013-07-30 |
US20050075979A1 (en) | 2005-04-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8498935B2 (en) | System and method for automated payment and adjustment processing | |
US20200294159A1 (en) | Methods, Systems, and Computer Program Products for Processing and/or Preparing a Tax Return and Initiating Certain Financial Transactions | |
EP0789884B1 (en) | Full service trade system | |
US7680735B1 (en) | Trade receivable processing method and apparatus | |
US5875435A (en) | Automated accounting system | |
US8521613B2 (en) | Expense tracking, electronic ordering, invoice presentment, and payment system and method | |
US7437327B2 (en) | Method and system for buyer centric dispute resolution in electronic payment system | |
US7865413B2 (en) | Method and system for processing transactions by a third party using a central database to facilitate remittance | |
US8566237B2 (en) | Internet payment system and method | |
US20070282724A1 (en) | Asset based lending (abl) systems and methods | |
WO2008045947A2 (en) | Systems and methods for collaborative payment strategies | |
US7020639B1 (en) | Check verification system and method | |
KR100407397B1 (en) | Trade form electronic filing document and trade automation system by electronic data interchange | |
US20030004864A1 (en) | Receivables management method | |
Michele et al. | Essentials of managing corporate cash | |
EP1096437A2 (en) | Check verification system and method | |
KR20020025546A (en) | integrated Purchasing information system | |
Coven | Moving to e-payments: Best practices for US middle-market companies |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: OLD WORLD INDUSTRIES, INC., ILLINOIS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KONG, XIANG;LEAVITT, STACY A.;MALLOY, STEPHEN LOUIS;AND OTHERS;REEL/FRAME:015459/0537;SIGNING DATES FROM 20040609 TO 20040610 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |