Nothing Special   »   [go: up one dir, main page]

US20130268339A1 - System and Method for Varying Electronic Settlements Between Buyers and Suppliers with Dynamic Discount Terms - Google Patents

System and Method for Varying Electronic Settlements Between Buyers and Suppliers with Dynamic Discount Terms Download PDF

Info

Publication number
US20130268339A1
US20130268339A1 US13/893,769 US201313893769A US2013268339A1 US 20130268339 A1 US20130268339 A1 US 20130268339A1 US 201313893769 A US201313893769 A US 201313893769A US 2013268339 A1 US2013268339 A1 US 2013268339A1
Authority
US
United States
Prior art keywords
payment
logic
buyer
terms
invoice
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
Application number
US13/893,769
Inventor
Don Holm
Duc Lam
Xuan (Sunny) McRae
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
JPMorgan Chase Bank NA
Original Assignee
JPMorgan Chase Bank NA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by JPMorgan Chase Bank NA filed Critical JPMorgan Chase Bank NA
Priority to US13/893,769 priority Critical patent/US20130268339A1/en
Assigned to JPMORGAN CHASE BANK, N.A. reassignment JPMORGAN CHASE BANK, N.A. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: JPMORGAN XIGN CORPORATION
Publication of US20130268339A1 publication Critical patent/US20130268339A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0222During e-commerce, i.e. online transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/387Payment using discounts or coupons
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/08Auctions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • G06Q50/18Legal services
    • G06Q50/188Electronic negotiation

Definitions

  • This invention relates to the field of software and computer network systems.
  • the invention relates to electronic systems associated with financial transactions.
  • an organization or an individual initiates payment by sending a physical check to the party to whom a debt is owed.
  • the check may be sent in response to an invoice from the party to whom the debt is owed.
  • a newer approach is electronic payment. For example, in the consumer context, individuals may be able to make, payment by way of electronic banking. Payment instructions are sent electronically from the individual's computer system to the individual's bank. Payment is then effected by the bank.
  • Payments may be made by wire transfer, with instructions requesting funds of the payer in one financial institution to be transferred to an account of the party to whom payment is to be effected.
  • ERP Enterprise resource planning
  • Such systems may have databases of complex and extensive sets of information, such as addresses of various suppliers and similar information related to purchasing.
  • Sellers also use electronic accounting and record keeping systems which may assist in the receipt and tracking receipt of payment for goods and services.
  • Prior systems require considerable amounts of effort to update and maintain, and may lack compatibility with the systems used by parties with whom an organization wishes to engage in transactions. There is thus a need for improved systems to facilitate transactions between buyers and sellers.
  • An embodiment of the invention is directed to a method of making payment.
  • a request is received to effect payment between a buyer and a seller for a transaction having established terms.
  • the terms include a payment amount and a settlement date.
  • Messages are exchanged between the buyer and the seller that include an offer and acceptance of new terms for payment other than the established terms.
  • the new terms include an adjusted amount of payment to be made at a particular time after an event associated with the transaction.
  • An electronic notification that the event has occurred is received, and after the notification, payment between the buyer and seller is effected under the new terms.
  • a digital signature indicating acceptance of the new terms is receive.
  • a system may verify such signature before proceeding under the new terms.
  • the event may include different forms of electronic notifications.
  • the event includes an electronic indication of approval of the seller's invoice by the buyer.
  • the event includes an electronic indication that the seller has shipped the goods ordered in the transaction, the buyer has received goods ordered in the transaction or the buyer has authorized payment for the transaction.
  • the different terms may take different forms.
  • the different terms comprise a discount in exchange for payment a particular time between the settlement date and the event.
  • the established terms include a discount date before which the seller is willing to offer a particular discount
  • the new terms comprise a discount different from the discount provided in the established terms in exchange for payment a particular time earlier than the discount date.
  • the new terms comprise a discount different from the discount provided in the established terms in exchange for a payment a particular time later than the discount date.
  • Another embodiment of the invention is directed to a method of making payment according to new terms, where the new terms include an adjusted amount of payment to be made at a particular time after an event associated with an invoice for the transaction.
  • the invoice is received from the seller, and an electronic notification is received that the event associated with the invoice has occurred. After the notification, the payment is effected between the buyer and the seller under the new terms.
  • Another embodiment of the invention is directed to a method of effecting payment that includes receiving requests to effect a set of transactions with a set of entities.
  • the transactions have established terms.
  • a set of notifications of events associated with the transactions is received.
  • Requests for offers of terms different than the established terms are sent to the entities, and the different terms are to apply to payment made at a particular time after the event.
  • Offers are received in response to the requests, and a set of offers among the offers is selected based on a set of one or more criteria.
  • payment is effected to the respective entities associated with the selected offers under the terms in the respective offers.
  • the set of entities may comprise sellers, and the set of requests for offers may be sent by a buyer's system.
  • requests and/or offers may be made differently.
  • a series of requests to individual entities for offers of terms is made, and oilers are received from individual entities in response to the requests in the series.
  • the requests may be made over time and with terms that are incrementally more attractive to the individual entities.
  • a message is sent to individual entities with a series of different terms among which the entities may select to make the offers of terms.
  • the series of different terms may include sets of proposed amounts of payment and associated dates of the payment.
  • the sets may include multiple proposed amounts of payment associated with at least of some of the proposed dates of payment.
  • the offers may be selected based on a set of one or more criteria.
  • the set of one or more criteria includes a risk assessment of the respective entity according to one implementation.
  • the set of one or more criteria includes amount of savings per transaction, and in another implementation, it includes amount of time remaining before settlement date in the respective transaction.
  • Another embodiment of the invention is directed to a method of making payment involving a buyer, seller and a third party.
  • the third party is a financial institution, such as a bank.
  • Notification regarding the existence of a transaction between a buyer and a seller is received.
  • the transaction has established terms, which include a payment amount and a settlement date.
  • Messages are exchanged between the buyer, seller and a third party that include an offer and acceptance of new terms for payment other than the established terms.
  • the new terms include an amount of payment to be made by the third party to the seller at a particular time after an event associated with the transaction.
  • Electronic notification is received that the event has occurred. After the notification, payment of the adjusted amount is effected from the third party to the seller under the new terms.
  • the transaction binds both sellers and buyers.
  • the event includes, according to different embodiments, an electronic indication of approval of the seller's invoice by the buyer, electronic indication that the seller has shipped the goods ordered in the transaction, electronic indication that the buyer has received the goods ordered in the transaction, or electronic indication that the end user at the buyer's organization has received the goods ordered in the transaction.
  • the system includes a first system associated with a seller and a second system associated with a buyer.
  • the first system includes logic that generates an invoice and sends the invoice to a buyer.
  • the invoice has an associated set of terms.
  • the first system also includes logic that, in response to a request for an offer front the buyer, sends at least an offer to the buyer for a new set of terms other than the terms associated with the invoice.
  • the offer applies to payment after an event associated with processing of the invoice.
  • the second system associated with the buyer includes logic that receives the invoice from the seller and logic that generates and sends to the seller the request for an offer.
  • the second system also includes logic that receives the offer from the seller, logic that sends an electronic indication to the seller accepting the offer from the seller and logic that generates electronic indications of events associated with processing of the invoice.
  • the second system further includes logic that effects payment from the buyer to the seller according to the new terms after receipt of electronic indication of the event associated with the processing of the invoice.
  • the second system includes logic that sends requests for offers of new sets of terms to systems associated with a plurality of sellers.
  • the offers apply to payment after an event associated with processing of associated invoices, and the new terms are different from previously established terms associated with the invoice.
  • This logic also accepts a subset of the offers and effects payment under the new terms alter the respective events in response to the offers for new terms.
  • Another implementation of the invention includes logic that selects the subset of offers based on whether a goal has been met.
  • the goal may include an amount of sayings, duration of the goal, or combination of the amount and duration.
  • the goal may also include other criteria such as other financial goals or a combination of goals and tolerance for risk.
  • the first system includes logic that sends requests for offers of new sets of terms to systems associated with a plurality of buyers.
  • the offers apply to payment after an event associated with processing of associated invoices.
  • This logic also accepts a subset of the offers and accepts payment under the new terms after the respective events in response to offers for new terms.
  • FIG. 1 shows a block diagram of a system for payment with discounts according embodiment of the invention.
  • FIG. 2 shows a flow diagram for discounted payment according to an embodiment of the invention.
  • FIG. 3 shows a block diagram of a system for payment with logic to make offers to a set of entities according to an embodiment of the invention.
  • FIG. 4 shows a flow diagram for creation of a campaign for discounted payment according to an embodiment of the invention.
  • FIG. 6 shows a flow diagram for discounted payment involving a financial institution according to an embodiment of the invention.
  • FIG. 7 shows a timing, diagram for discounted payment according to an embodiment of the invention.
  • FIG. 8 shows a user interface for a banking system according to an embodiment of the invention.
  • FIG. 9 shows a user interface for a payer system according to an embodiment of the invention.
  • FIG. 10 shows a system for electronic payment according to an embodiment of the invention
  • An embodiment of the invention is directed to a system for dynamically adjusting the terms of payment in a transaction based on electronic notification of events associated with respective transactions. For example, early payments may be made after receipt of electronic notification of an event such as approval of the respective invoice or release of the payment for the invoice.
  • An offer is made for an adjustment of the terms that apply to payment at a time after the respective event.
  • one entity such as a buyer, sends requests to a set of entities, such as sellers, for offers of terms different than the established terms between such entity and the respective other entities.
  • the entity that sent the request selects among offers receive from the set of entities based on a goal. The entity that sent the request continues to evaluate offers of new terms until the goal have been reached. After acceptance of an offer, payment is then effected at a time after the respective event under the newly agreed upon terms.
  • An electronic notification of event may be made based on an action of an employee or other individual in the organization that is making the payment.
  • the event may be the approval by the responsible employee of the invoice associated with the transaction.
  • the response is made through a response to an email notification regarding the invoice received by an employee of the payer organization.
  • the employee is able to approve the invoice based on events regarding the status of the order.
  • the employee may approve the invoice when the employee determines that the goods ordered have been received. Approval of the invoice may alternatively occur automatically.
  • the invoice may be automatically approved when a procurement system sends a notification that the goods have been received and that the invoice data is accurate as compared to the corresponding purchase order.
  • One embodiment of the invention is directed to making payment at other than the agreed-upon time and on other than the agreed-upon terms at a time after electronic notification of an event regarding status of the respective order.
  • the electronic notification regarding status of the order includes, according to different implementation, electronic notification regarding events that provide different level of confidence that the respective goods or services will be received satisfactorily and that payment will be properly authorized. Such events include the following:
  • the buyer and seller may negotiate the new terms for payment based on different factors. For example, based on a simple time value of money based on a selected interest rate calculation, the change in the payment amount can be calculated based on the number of days earlier or later than the originally agreed-upon settlement date that payments occur.
  • An interest rate may be used that extrapolated from the discount provide in the seller's original terms, or the original terms in the original agreement between the buyer and the seller.
  • One embodiment of the invention is directed to requesting offers from multiple parties for a change or changes in payment terms to make payment on other than the agreed upon terms at a time after electronic notification regarding the status of the order.
  • request for offers may be made by a buyer to respect the seller, seller is to respect the buyer or a combination of seller to respective buyers.
  • Parties to whom such requests are sent may be selected based on the sizes of the transaction, potential savings to be received, potential amount of advanced cash flow to be obtained, reference standing at the party, the amount of term left in the transaction and other factors related to confidence with respect to other entities such as the credit rating or experience with the particular party.
  • the selection based on the size of the transaction may be made based on the size of the outstanding transaction with the party in aggregate and alternatively may be made based on the size of individual transactions. Offers may then be accepted based on a goal such as aggregate savings to be achieved or amount of advance in cash flow.
  • the request for offers may be made as the respective electronic notification of the event occurs.
  • a negotiation may take place between respective parties regarding the type of adjustment to the terms to take place after electronic notification of respective event will occur. For example, a buyer and seller may agree that after the buyer approves the invoice for an order, that the buyer may make early payment and receive an adjustment in the amount owed based on an interest rate and based on the number of days remaining before the originally required settlement date.
  • FIG. 1 shows a block diagram of a system for payment with discounts according to an embodiment of the invention
  • FIG. 1 includes payer system 101 and payee system 102 .
  • Payer system 101 includes computer electronics such as processor 110 and input/output (I/O) 109 .
  • Other electronics such as those found in a computer server may be included in payer system 101 according to an embodiment of the invention.
  • Payer system 101 includes routing logic 104 and approval logic 105 which is coupled thereto, Approval logic 105 is coupled with payment release logic 106 , term adjustment 107 and order status logic 111 , which are also included in payer system 101 .
  • Payer system also includes settlement logic 108 which is coupled to payment release logic 106 and settlement logic 123 of payee system 102 , and offer logic 130 , which is coupled to terms adjustment logic 107 and offer logic 131 of seller system 102 .
  • Routing logic 104 of payer system 101 is coupled with an invoice 103 received at payer system 101 .
  • Payee system 102 includes an invoice creation logic 120 which is coupled with invoice 103 of payer system 101 .
  • Payee system 102 also includes approval/notification logic 121 coupled with term adjustment 122 and settlement logic 123 , which are also included by payee system 102 .
  • payee system 102 includes offer logic 131 , which is coupled to discount logic 122 and offer logic 130 of payer system 101 .
  • Payee system creates an invoice using invoice creation logic 120 . The invoice is created based on art invoice definition provided by payer system 101 , according to one implementation.
  • Invoice 103 is received by payer system 101 from invoice creation logic 120 of payee system 102 .
  • Invoice 103 is routed to the appropriate personnel or mechanisms in order to have the invoice approved and verified for payment.
  • Approval is carried out by approval logic 105 , which is coupled with routing logic 104 .
  • Approval may be based on the status of the particular order, and such status may be obtained automatically by order status logic 111 .
  • Order status may include such items as whether the goods for which the invoice is received have been shipped or whether they have been received by the payer organization.
  • Order status logic 111 may obtain additional information regarding the order status, such as automatically available information regarding the quantity of equipment received based on a just in time (JIT) or other inventory management system.
  • JIT just in time
  • order status logic 111 may be coupled with an enterprise resource planning (ERP) system. After the respective order is approved, payment made, the payment is released. Such action is carried out by payment release logic 106 , which is coupled with approval logic 105 .
  • ERP enterprise resource planning
  • Offer logic 130 makes a request for an offer of different terms other than those established terms associated with a particular transaction. Upon acceptance of the respective offer, the transaction can be effected under the different accepted terms. Thus, offer logic 130 communicates with terms adjustment logic 107 to adjust the terms that will be applied to the particular transaction or transactions.
  • the request for an offer and receipt of the respective response may be made in advance of the event that will trigger payment, according to one embodiment of the invention. Alternatively, at least some portion of the interaction regarding the offer may be made upon receipt of electronic notification of the respective event, such as after receipt of electronic notification that an invoice for the transaction has been approved in payer system 101 .
  • Offer logic 130 may include criteria under which offers are accepted. In such an implementation, an offer is accepted only if it meets the configured criteria.
  • terms adjustment logic 107 calculates a new settlement date and payment amount. A notification is sent to seller system 102 to indicate acceptance of the offer of the newly defined terms.
  • Terms adjustment logic 107 implements the respective adjustment to the original payment amount (such as a discount) that is to be made in exchange for an adjusted payment date. Terms adjustment logic is coupled with payment release logic 106 and approval logic 105 so that an adjusted payment may be triggered upon an approval of the invoice or a release of the respective payment. Terms adjustment logic 107 is in communication with discount logic 122 of payee system 102 in order to reconcile the respective discount. Settlement logic 108 settles respective payment between payer system 101 and payee system 102 in communication with settlement logic 123 in payee system 102 . Such settlement settles payment of the respective amount minus any discount taken for early payment as determined by terms adjustment logic 107 .
  • the logic modules shown may be implemented in software processes in communication with each other. Some functionality may be shared between different respective modules for design, efficiency and other reasons. Alternatively, aspects of the respective logic modules may be implemented in hardware or a combination of hardware and software.
  • the functions shown may be implemented on a computer system with a processor input/output, such as shown here with processor 110 and input/output (I/O) 109 .
  • payer system 101 may be implemented on a computer server and payee system may be implemented on a different computer server.
  • functions of the payer system 101 and payee system 102 may be implemented on a common server. Functions of the various systems may also be distributed on different computer systems or servers. Such computer systems or servers may communicate through direct links or over a computer network, such as the internet.
  • FIG. 2 shows a flow diagram for discounted payment according to an embodiment of the invention.
  • An offer is made to adjust timing of payment in exchange for adjusting the amount of payment. If the offer is accepted, an invoice is paid according to the newly agreed payment terms.
  • a trigger event is an event after which payment is effected.
  • a trigger event is an event such as approval of the invoice before the original due date or release of payment for the invoice before the original due date.
  • First payment terms are established with the original due date (block 201 ).
  • an offer is made for the adjustment of terms program.
  • the seller offers the buyer a discount in the amount otherwise owed in exchange for early payment by the buyer (block 202 ).
  • the buyer offers the seller early payment in exchange for a discount from the amount that otherwise would he owed by the buyer (block 203 ).
  • Such process of offering a discount for early payment is, according to an embodiment of the invention, carried out automatically by a system sending requests to various buyers or sellers for the different terms. If assent from the other party to discount for early payment is not received (block 204 ), then effect payment according to the original terms (block 205 ).
  • the terms may also be adjusted by the respective party starting the negotiation making a request for offers of adjusted terms rather than making an offer of adjusted terms.
  • the party making such request decides to accept or not accept the offers that are received.
  • the exchange of such requests and resulting offers may be made after receipt of the trigger event, according to one implementation of the invention.
  • the actual times that payment may be made after the trigger event is established and the corresponding amounts of payment to be made on such date or possible dates are proposed.
  • the offering and campaign process definition/setup is independent of incoming invoices.
  • the trigger events occur when a business document is approved, received, or when other events regarding the document or order occur.
  • the invoice is received from the vendor in the vendor system (block 206 ). Such invoice may be created by the vendor based on a set of rules provided by the buyer, according to one embodiment of the invention.
  • the seller invoice is validated (block 207 ). Such validation may include checking various aspects of the data provided for the invoice. Such validation may be based on a set of rules provided by the buyer, according to one embodiment of the invention.
  • the completed invoice is then signed and encrypted (block 208 ).
  • the signing of the invoice is performed using a digital signature of the seller so that the recipient can verify that the invoice has been sent by the seller.
  • the invoice is encrypted to help provide security.
  • Encryption may be performed using a public key/private key scheme and the encryption would be performed using the public key of the recipient. Then the invoice can later be decrypted using the private key of the recipient according to the public key/private key scheme.
  • the invoice is sent to the buyer system (block 209 ). Such sending may be performed by placing the invoice into an e-mail format and sending that e-mail over an e-mail link between the buyer system and the seller system. Alternatively other forms of electronic communication may be used to send the invoice, such as http post, ftp, electronic data interchange (EDI).
  • EDI electronic data interchange
  • the invoice is received at the buyer system (block 210 ).
  • the invoice is decrypted and authenticated in the buyer system (block 211 ). Such decryption may be performed using the private key of the buyer, assuming that the invoice was encrypted using the public key of the buyer.
  • the invoice is authenticated by determining whether it was sent by the seller. Such authentication may involve a public key/private key scheme and, assuming that the invoice was digitally signed by the seller system, is performed using the public key of the seller.
  • the data of the invoice is validated to ensure that it meets certain characteristics preferred by the buyer (block 212 ). Such characteristics may include “such as the format of the data as well as whether the data in the invoice may have certain values.
  • the invoice is routed in the buyer system (block 213 ).
  • the invoice is routed to various recipients within the buyer system in order to receive their input regarding the invoice.
  • Their input may include approval of the invoice or acknowledgement of receipt of the invoice.
  • a trigger event may occur.
  • a trigger event may also be based on an automatic update regarding the order status. For example, in one implementation, the system automatically determines that the respective goods have been shipped or that the respective service has been commenced. Alternatively, the system automatically determines that the respective goods have been received or that the respective service has been completed. Such determination automatically updates the trigger event. Alternatively, such information may be obtained based on user input through the routing process.
  • a user receives, according to an embodiment of the invention, an electronic notification, such as an e-mail, regarding the respective invoice.
  • the user is then able to respond to the message and indicate a status of the order.
  • an e-mail may be routed to the respective end user of the product that was ordered.
  • the user then, according to one embodiment of the invention, provides an electronic notification to the system indicating that the user has received the goods ordered. In response to such indication from the user, the system may automatically cause the trigger event to occur. Alternatively, the user may indicate approval of the invoice.
  • a trigger event may be selected from among different type of events.
  • the system provides a trigger event of either invoice approval or release of payment scheduled (block 214 ).
  • the invoice approval may be determined based on a number of factors.
  • the invoice is posted into the enterprise resource planning (ERP) system (block 215 ).
  • the ERP system is notified to execute matching rules (block 216 ).
  • the system monitors the status of the invoice to determine the action taken upon the invoice, such as whether it is approved by the user (block 217 ), if the invoice is approved, or within a certain amount of time, not approved, the respective status is sent to the seller (block 218 ).
  • the adjusted payment is effected (block 220 ). If the approval of the invoice is not received before the original due date, assuming that such action is the trigger event, payment is effected according to the original terms (block 222 ).
  • the adjusted payment may take place upon, or shortly after the trigger event. Alternatively, the early payment takes place some time later after the trigger event but still before the original payment due date.
  • a request for an offer of a new set of terms with an adjusted payment is sent after receipt of the trigger event.
  • An offer is received from the seller in response to the request for an offer.
  • the buyer may have proposed the new terms that the seller is to offer.
  • the buyer may determine that it will reject the offer proposed by the seller and instead effect payment according to the original terms.
  • the trigger event is release of payment scheduled (block 214 )
  • FIG. 3 shows a block diagram of a system for payment with logic to make offers to a set of entities according to an embodiment of the invention.
  • FIG. 3 includes buyer system 301 , seller system A 302 , seller system B 303 , seller system C 304 , and seller system D 305 . Also shown in FIG. 3 are set of outcomes 306 and 307 as well as response 308 and 309 .
  • Buyer system 301 includes goal seeker logic 313 , payment logic 314 and event generation logic 315 .
  • event A 317 and event B 316 Also shown in buyer system 301 are event A 317 and event B 316 .
  • Goal seeker logic 313 includes rules 318 , selection logic 319 and stop logic 320 .
  • Event A 317 and event B 316 each include information regarding the event. For example, event A 317 includes event type 324 , identification of the vendor 321 , identification of the amount in the transaction 322 and the settlement date 323 . Offer request will be sent to proper seller based on vendor identification of the
  • a buyer through buyer system 301 , makes a set of request for offers of new terms based on electronic notification of events.
  • Buyer system 301 establishes a goal or set of goal to be achieved with the new terms.
  • the goal includes criteria under which the attempts to achieve different terms will stop, and the stopping of the seeking of different terms is controlled, based on such criteria, by stop logic 320 .
  • Selection logic 319 determines how often sets of offers with changes in terms are evaluated and selected.
  • Rules logic 318 determines whether an offer is sent to a seller or sellers based on a particular event. Such determination is made based on the identification of the vendor, the amount of payment in the transaction and settlement date.
  • Request for modified terms are sent to different sellers. As shown here, request 306 and request 307 are sent to seller system A 302 and seller system 8 303 respectively. Responses are received from sellers with offers for changes in the respective terms. For example, response 308 and response 309 are received from the seller system C 304 and seller system D 305 respectively.
  • the request for an offer for a different set of terms may be in the form of a set of outcomes.
  • request 306 includes a set of dates of 310 and corresponding adjusted payments to he made 311 .
  • Such a request may have an additional dimension as shown in additional sets of outcomes 312 .
  • Such additional sets of outcomes may represent payments based on different interest rate calculations, for example.
  • the seller responds with an offer with a selection of a subset of the set of outcomes. The buyer can then select among this subset and among such offers from varies other sellers.
  • the sellers may create their response oilers automatically based also on a goal seeking logic, as shown here with goal seeker logic 330 and seller system A 302 .
  • goal seeking logic may select among the outcomes to make offers based on various criteria. For example, such selection may be made based on credit rating, size of the payment, number of days that the payment is advanced, changed in date of payment versus interest rate or other criteria.
  • FIG. 4 shows a flow diagram for creation of a campaign or goal seeker for discounted payment according to an embodiment of the invention.
  • a campaign may be undertaken in order to change the terms with a set of buyers or suppliers in order to achieve an earlier payment, for improved cash flow, or, as a buyer, to achieve reduced overall payments in exchange for making payments on an earlier schedule.
  • a set of buyers or suppliers is determined according to the desired savings (block 401 ). Such determination may be made in view of the respective amounts owed to a set of suppliers and the time before such payment is due. If the remaining time left before such payments are due is great enough, there is a potential for negotiating a significant discount in such payments. Based on the prevailing interest rates, and amount of outstanding balances, a set of buyers or suppliers may be selected to achieve the desired savings. In the case of suppliers, a set of buyers having substantial enough amounts owed to the supplier may be selected as candidates for early payment. This set may be selected based on the amount of payments outstanding and the remaining time for such payments. Selection may be made based on first choosing the set of organizations haying the largest outstanding balances and the most time remaining on such balances.
  • one factor such as the amount of balances or time on such balances may be preferred over the other in various embodiments of the invention.
  • Different subsets of buyers or sellers may be established based on various factors such as credit ratings, size, length of relationship or other factors. Then different rules for response are established for each group of buyers or sellers depending on the nature of the group.
  • Trigger conditions are defined (block 402 ). Such trigger conditions may be approval of the invoice or release of payment. Other trigger conditions may be selected in alternative embodiments of the invention.
  • Negotiations are entered to achieve different payment terms in exchanging discounted payment for earlier payment. Such negotiations, according to an embodiment of the invention are performed in a step-wise manner (block 403 ). Such negotiations are performed by providing a series of offers for progressively better terms to the other party. For example, according to one embodiment of the invention, a buyer automatically offers successively earlier payments in exchange for a particular discount. Alternatively, a buyer oilers successively lesser discounts in exchange for a particular early payment. In one embodiment of the invention a seller offers successively greater discounts in exchange for a particular earlier payment schedule. In an alternative embodiment, the seller offers successively later payment schedule in exchange for a particular discount. Combinations of such offers may be used in alternative embodiments of the invention. In one implementation, the negotiation takes place after the trigger event (discussed below).
  • Such rules determine when the respective invoice is in a status such that it is sufficiently certain that the goods are received or the services have been rendered that the buyer can reliably guarantee payment (block 404 ). For example, depending on the rule, different trigger conditions may apply to different parties e.g. different sellers, or different buyers or different groups depending on the rules established.
  • notification and approval rules are defined (block 405 ). Such rules determine upon what conditions notification is provided regarding the status of the order. Examples of such rule include: wait for signed approval from particular individual (CFO, etc) if amount is greater than certain amount, auto approval if no approval action has not received in number of business days, or other rules. After such definition, the campaign can be enabled (block 406 ).
  • a trigger event occurs (block 407 ) and supplier approval, notification and confirmation rules are executed (block 408 ).
  • buyer approval, notification and confirmation rules are executed (block 409 ).
  • the final settlement date and amount are automatically adjusted (block 410 ).
  • FIG. 5 shows a block diagram of a system for discounted payment involving a third party such as financial institution according to an embodiment of the invention.
  • a financial institution is involved in order to allow a seller to receive early payment for its electronically invoiced accounts.
  • the seller system receives early payment upon or after a trigger event, such as approval of the invoice or release of payment by the buyer.
  • the seller receives this payment from a financial institution at this earlier date.
  • the buyer makes payment to the financial institution later.
  • the payment received by the seller from the financial institution is discounted, and the payment made by the buyer to the financial institution is at a higher amount than what the financial institution pays to the seller.
  • the system shown in FIG. 5 is one embodiment of the invention to effect such transactions.
  • the system shown includes a buyer system 501 , seller system 502 and financial institution system 503 .
  • Buyer system includes payment terms setup logic 504 , invoice 505 , approval logic 506 , payment and release logic 507 , events logic 508 and payment with dates payable outstanding (DPO) logic 509 .
  • Payment terms setup logic 504 is coupled with buyer terms 513 of financial institution 503 .
  • Invoice 505 on buyer system 501 is coupled into approval logic 506 and payment release logic 507 .
  • Approval logic 506 is coupled with payment and release logic 507 and events logic 508 .
  • Approval logic 506 , payment and release logic 507 and events logic 508 are coupled into event notices logic 520 which is coupled with event notification logic 523 of seller system 502 . Approval logic 506 , payment release logic 507 and events logic 508 are also coupled with event notification logic 514 of financial institution 503 . Payment with dates payable outstanding logic 509 is coupled with payment and release logic 507 and approval logic 506 . Logic 509 is also coupled with payment receipt logic 515 of financial institution 503 .
  • Financial institution 503 includes buyer terms logic 513 , event notification logic 514 , payment receipt logic 515 , seller terms logic 516 , payment release logic 517 , remittance information logic 518 and debit memo logic 519 .
  • Seller terms logic 516 is coupled with payment terms setup logic 521 of seller system 502 .
  • Payment release logic 517 is coupled with payment receipt logic 524 of seller system 502 .
  • Remittance information logic 518 is coupled, along with debit memo 519 , to reconciliation logic 525 of seller system 502 .
  • Seller system 502 includes payment terms setup logic 521 , invoice generation logic 522 , event notification receipt logic 523 , payment receipt logic 524 and reconciliation logic 525 .
  • Payment terms set up logic 521 includes business events logic 526 , fees logic 527 and terms logic 528 .
  • Payment terms are set up between a buyer and a financial institution.
  • the system facilitates such negotiation and set up with payment terms setup logic 504 and buyer terms logic 513 .
  • Payment terms setup logic determines the set of business events, days payable outstanding and percentage rebate provided under the agreed upon terms. Such setup is performed respectively by business events logic 510 , additional DPOs logic 511 and percent rebate logic 512 respectively. After such terms are set up, they are stored by buyer terms: logic 513 to be available to automatically set the respective terms in future financial transactions.
  • Seller terms logic 516 and payment terms setup logic 521 facilitates such negotiation and sets up the respective terms between the financial institution and the seller.
  • the setup of the payment terms includes determination of the respective business events giving rise to the early payment, the fees charged by the financial institution to the seller for the early payment and the terms under which such payment is made. Such setup is performed by business events logic 526 , fees logic 527 and terms logic 528 respectively.
  • the tasks performed by the logic shown in the systems shown may be performed by software programs.
  • the software programs may run in modules in the organization shown.
  • Such software may, according to various embodiments of the invention, be implemented as different schemes of software modules and/or classes or processes according to different system and communication requirements.
  • buyer system and seller system are implemented on separate servers each with respective computer processor or processors.
  • the respective systems may be implemented on a common server or a distributed set of servers.
  • Other implementations are possible such as in a distributed network environment.
  • transactions may be performed using the new terms.
  • only one of either the buyer or seller enters into an arrangement with the financial institution.
  • both buyer and seller enter into arrangements with the financial institution to change the payment terms from the original payment terms.
  • invoice 522 is created. Such invoice may be created and validated based on a definition of the invoice and rules for the invoice provided by a buyer or buyer system.
  • the invoice is transmitted to the buyer system and received, as shown here as invoice 505 .
  • the invoice is subject to approval and other factors such as validation. Approval is performed by approval logic 506 .
  • approval logic 506 When the invoice reaches the appropriate status payment may be released as performed by payment release logic 507 .
  • the event for which payment is released may be indications received from the users that the goods have been received and that appropriate management has approved the expenditure. Other events regarding the status of the invoice and order are recorded and transmitted by events logic 508 .
  • Event notification logic 514 in financial institution 503 This allows financial institution to base payment to the seller system on the appropriate event the buyer system. Event notices are also transmitted as event notices 520 to event notification logic 523 of seller system. Payment is made from buyer system 501 to financial institution 503 by payment with DPO logic 509 . This logic makes payment to the financial institution instead of the seller system because the seller is paid directly by the financial institution. Payment is made at the full amount of the invoice or some amount greater than the amount paid by the financial institution to the seller.
  • Seller system 502 receives payment in payment receipt logic 524 from payment release logic 517 of financial institution 503 . Assuming the proper trigger event has occurred before the expiration date of such event, this payment is made at a time earlier than originally scheduled under the original terms between the buyer and the seller. The payment however is made at a discounted amount to account for the time value of money in having the payment made at an earlier time.
  • Reconciliation logic 525 of seller system 502 reconciles the various records of payment including the original invoice records and other payment records with respect to remittance information transmitted from remittance info logic 518 and debit memo logic 519 of financial institution 503 .
  • FIG. 6 shows a flow diagram for discounted payment involving a financial institution according to an embodiment of the invention.
  • Terms are set up between a buyer and a financial institution allowing the buyer to make payment to the financial institution according to the normal payment schedule or later.
  • Terms are set up between the seller and the financial institution allowing for the seller to receive payment earlier than the normal scheduled payment time in exchange for the financial institution paying the seller only a discounted amount of the original agreed upon payment amount.
  • the system facilitates negotiation of terms between the buyer and the financial institution (block 601 ).
  • An association is established between an incentive program providing such payment terms and a buyer for the financial institution (block 602 ); this includes type of trigger events (invoice approval, good received, etc.), additional days payable outstanding (DPO) rebate percentage and/or other terms.
  • the system receives a designated payment type for the buyer from the financial institution (block 603 ).
  • the payment type defines how the financial institution will collect payment on behalf of the seller (e.g., credit to financial institution is sent by buyer, or financial institution will automatic debit from buyer's account according to different optional approaches).
  • the financial institution has various payment types that are available for use by the buyer and a selection of the type agreed upon between the buyer and the financial institution is received.
  • a credit limit is established for the buyer (block 604 ). Such credit limit may be determined based on a number of standard factors for determining credit. Additionally, the credit limit is established based on an analysis of the security of allowing for payment to the seller based on certain trigger events such as approval of the respective invoice by the buyer. Such events present a different risk profile than other types of events more typical of bank financing.
  • the following relate to setting up the vendor for financing.
  • the normal vendor terms and conditions are received (block 605 ).
  • Enrollment is received from the vendor for the additional terms and conditions with the financial institution (block 606 ). These additional conditions may include event type, discount rate, new term/due, and/or whether fixed or interpolated.
  • the approval is received from the financial institution of the vendor and the additional terms and conditions (block 607 ). Such approval may be based on various financial criteria regarding the vendor and the terms and conditions. Additionally, the approval may be based on an analysis of the security of basing payment to the vendor on particular events such as electronic approval of the invoice by the buyer or electronic notification of release of payment by the buyer. Based on the particular events selected and the type of notification, an analysis is made of the credit risk and appropriate financing terms are provided.
  • Payment may be effected using the system, Payment is effected between the financial institution and the seller and between the buyer and the financial institution.
  • An invoice is prepared and validated in the vendor system (block 608 ).
  • the prepared invoice is received and validated in the buyer system (block 609 ).
  • the approval of the invoice is received in the buyer system (block 610 ). Such approval may be made based on a selected set of factors such as approval by respective employees of the buyer system as described herein.
  • the status is sent to the vendor and financial institutions (block 611 ). Such status may include the status of approval, release of payment or other events regarding the invoice and the respective order based on events received by and generated in the buyer system. In particular, notification of the trigger event upon which adjusted payment terms are based is sent to the vendor and financial institution.
  • Remittance format is the format of remittance information provided by the buyer with respect to the payment.
  • Reconciliation is then performed for the seller account receivable (A/R) system (block 618 ).
  • Fund redirection instruction is received in the buyer system (block 619 ).
  • the reconciliation then occurs in the buyer system (block 620 ).
  • a rebate is executed according to one implementation (block 618 ).
  • Such rebate is based on the collective savings incurred by the financial institution in receiving larger amounts of payment from buyer and making lesser amounts of payments to the respective sellers for the respective transactions taking into account the discounted value of the amounts paid later by the buyer and a profit for the financial institution.
  • Providing, a rebate may be an optioned feature.
  • Payment of the funds will be transferred based on seller's preferences, which may preferably include single or combination of mechanism ranging from paper check to electronic clearing house centers (ACH, VISA, credit card, etc). Fund availability will notified by email to suppliers. Remittance information will be available to the seller in multiple media (paper, email, or online) as well as different A/R formats that are defined by suppliers (EDI, PeopleSoft, SAP, Oracle Financials, etc). These remittance files can be used by suppliers to reconcile with various Enterprise Resources Process (ERP) systems.
  • ERP Enterprise Resources Process
  • FIG. 7 shows a timing diagram for discounted payment according to an embodiment of the invention.
  • FIG. 7 shows two timelines for transactions between buyer and seller.
  • the first timeline includes seller 701 and buyer 702 .
  • the second timeline includes seller 703 , financial institution 704 and buyer 705 .
  • the timeline for seller 701 includes the following seller actions: goods shipped 706 and invoice issued 707 .
  • the timeline for buyer 702 includes the following buyer actions: invoice approved 708 , release for payment 709 , send discounted payment and full payment due date 711 .
  • First goods are shipped (action 706 ).
  • Similar actions may be taken based on other actions of the seller, such as performance of a service.
  • Other actions such as receipt of goods approval and inspection of the goods or other actions related to the goods or services may trigger events according to this scheme.
  • An invoice is then issued by the seller (action 707 ).
  • a buyer later approves the invoice (action 708 ).
  • the buyer releases payment (action 709 ).
  • the buyer provides a discounted payment (action 710 ) which is less than the full payment that would otherwise be due at a later point in time.
  • Such full payment that otherwise would be due is shown as full payment due date 711 .
  • an invoice is submitted to the buyer on day 0.
  • the supplier's terms for payment on this invoice are 2%, 10, net 30, meaning the supplier is willing to offer the buyer a 2% discount if the buyer pays within 10 days, else pay the full amount in 30 days.
  • the buyer's terms for this supplier match the suppliers terms.
  • the trigger event in this example is invoice approval, whereby notification regarding the trigger event occurs on the 12 th day relative to the date of invoice submission. Note this is two days past the early pay date as defined by the agreed upon terms.
  • an invoice is submitted to the buyer on day 0.
  • the supplier's terms for payment on this invoice are 1.5%, 10, net 30, meaning the supplier is willing to offer the buyer a 1.5% discount if they pay within 10 days, else pay the full amount in 30 days.
  • the buyers terms for this supplier are higher in that the buyer is “offerings” 2%10, Net 30.
  • the trigger event in this example is invoice approval, whereby notification regarding the trigger event occurs on the 2nd day relative to the date of invoice submission. Recognizing the disparity in terms, the supplier enters a new term to “meet the buyer halfway”, at 1.75%10, net 30.
  • the buyer responds to this “offer” or “adjustment” in the supplier's term on day 4 by adjusting his own term to meet the 1.75%10, net 30.
  • the buyer also indicates in his discount logic preferences to use this new rate going forward for this supplier. Note a payment method delay as was presented in Example 1 may be avoided. Note that extrapolation logic can be applied for days prior to the early payment due term or “early payment threshold” depending upon the specific deployment of the invention with respect to “extrapolation” preferences resident in the discount logic.
  • Example 3 discount terms are represented as an annualized rate of return, or interest rate, or, as businesses commonly refer to them, internal hurdle rates. In conjunction with this interest rate is the net due date of the invoice. Using these two numerical data points the system can extrapolate the appropriate discount depending upon the timing of a valid trigger event relative to the invoice due date. As with the other methods, we can use a variety of calculation methods, like simple interest or net present value. Example 3 utilizes Net Present Value in the calculation. Example 3 illustrates that both buyer and supplier have agreed upon the same set of terms, which is a 14% annual percentage rate and a invoice due date at day 30. In this example, the invoice is approved on day 14, or 16 days before the actual due date.
  • Example 3 employs the use of the payment method factor, which is 2 days, effectively adjusting the early pay date to 16 days after submission of the invoice, and 14 days before it is due. This 14 days becomes the basis of our discount calculation.
  • the APR of 14% we can generate an effective daily rate of 0.0384% (14/365). Applying this rate over a 14 day period translates to 0.537% (14*0.00384).
  • the net present value of the calculation, given a future value of $100,000 on day 30, using 0.537% as the rate of discount over 1 period yields a present value of $99,465.88, or a discount amount of $534.12
  • the second timeline shows interaction between the parties including a financial institution 704 .
  • Goods are shipped from the seller 709 to buyer 705 (action 712 ).
  • an invoice is issued by the seller (action 713 ).
  • Invoice is approved by buyer 705 in event invoice approved (action 714 ).
  • the invoice approval notice event is provided to financial institution 704 as well as seller 709 so that financial institution can base payment to seller on the approval of the invoice.
  • payment is released (action 715 ).
  • a notification of such release is provided to seller 709 as well as financial institution 704 .
  • Such notice is provided to financial institution 704 so that financial institutional may optionally trigger payment to the seller based on the release of payment by the buyer.
  • a discounted payment is made from financial institution 704 to seller 709 (action 716 ).
  • a full payment is made between buyer 705 and financial institution 704 (action 718 ).
  • Such payment may, in an alternative embodiment of the invention, equal the payment less than the full amount but larger than the amount made by the financial institution to the seller.
  • Such payment may also be made at a time (action 718 ) that is later than the original payment due date (action 717 ).
  • a bank is paying the supplier on behalf of two buyers who have received and processed invoices from this supplier.
  • the financial institution receives $100,000 from buyer I on day 60, and $200,000 from buyer 2 on day 50 in addition, note that buyer 1 is not subject to receiving a rebate from the financial institution. Buyer 2 in this instance will receive a rebate in the amount of $460, or 10% of the discount capture rate.
  • the bank can apply different methods to the calculation such as adjusting the $460 down based on cost of capital and duration the credit is outstanding, which in this case could be 20 days (50 days ⁇ 30 days (original due date of invoice). Also note that the numerical or lookup methods discussed in Examples 1-4 can also apply to the banking oriented embodiment of the system.
  • FIG. 8 shows a user interface for a banking system according to an embodiment of the invention.
  • the bank interface includes top level navigation inputs 801 and low level navigation/views, filters or functions 802 .
  • the major actions that the bank is able to take according to this interface include those associated with task list 803 , buyers 804 , suppliers 805 , activity $06 and credit analysis 807 .
  • the following actions are included under suppliers 805 discount program 810 , supplier directory 830 and participation statistics 832 .
  • Under discount program 810 is included rate 827 , term/due 828 and fixed/interpolated 829 .
  • Under supplier directory 830 is included discount program 831 .
  • Under category activity 806 is included current 811 , paid 833 and closed 834 .
  • Under closed 834 is included approved date 835 , buyer 836 , invoice number 837 , supplier 838 , original amount 839 , payable amount 840 and payable date 841 .
  • Under category credit analysis 807 is included credit limit summary by buyer 812 , dollars proved 842 discounts captured 843 and net benefit 844 .
  • Under net benefit is included trend analysis 845 , cumulative summary 846 and receivables 847 .
  • Under receivables is included summary 848 and by buyer 851 .
  • Under summary 848 is included amount 849 and age 850 .
  • Under buyer 851 is included amount 852 and age 853 .
  • Bank interface includes various options that allow the bank to manage and analyze its program of making payments for sellers and receiving payments from buyers.
  • buyers 804 allows for the bank to analyze the various programs that are set up for respective buyers.
  • the programs shown may be available in various combinations in various embodiments of the invention.
  • category suppliers 805 allows for the bank to analyze its programs offered for various suppliers. Such analysis may be provided for each respective supplier and also for the programs that are available in general to the bank with respect to suppliers.
  • Category activity 806 allows for the bank to analyze various pending activities with respect to the discount programs offered and managed by the bank.
  • Credit analysis category 807 allows for the bank to conduct various forms of analysis on these programs. The analysis may take the form of the types shown or other combinations, sub combinations or super combinations of these elements.
  • FIG. 9 shows a user interface for a payer system according to an embodiment of the invention.
  • Payer administration interface includes top level navigation actions 901 and low level navigation/views, filters, or functions 902 .
  • Top level navigation 901 includes the following categories: task lists 903 , supplier 905 , activity 906 and credit analysis 907 .
  • Task list 903 includes supplier targets 904 .
  • Suppliers 905 includes same as current GSD 908 . Same as current GSD 908 includes new flag for payables financing 909 and filter and view 910 .
  • Category activity 906 includes current 911 , paid 912 and closed 913 . Closed 913 includes approve date 914 , buyer 913 , invoice number 916 , supplier 917 , original amount 918 , payable amount 919 and payable date 920 .
  • Category credit analysis 907 includes credit limit summary by buyer 921 , dollars moved 922 , discounts captured 923 and net benefit 924 .
  • Category net benefit 924 includes trend analysis 925 , cumulative analysis 926 and receivables analysis 927 .
  • Receivables analysis includes summary 92$ and by buyer 931
  • Summary 928 includes amount 929 and 930 .
  • buyer 931 includes amount 932 and age 933 .
  • Payer administration may be used by a buyer to display potential candidates suppliers with whom a program of discounts may be engaged.
  • the various actions shown allow for the buyer to filter among the set of suppliers that the buyer works with to find potential suppliers for whom various levels of savings may be achieved through earlier payment and reciprocal discounts.
  • filter and view 910 allows for identification of suppliers selected by various filters. Such filters may be based on the potential savings for the respective suppliers.
  • Activity 906 allows for analysis of current payment activity.
  • Credit analysis 907 allows for analysis of the use of discounts to achieve savings. Such savings may be displayed in various forms as shown.
  • This interface shows current on-going activity and balance with regarding to buyer and suppliers.
  • the current section displays invoices that match defined criteria awaiting approval to be executed.
  • the paid section displays invoices that currently has been paid to suppliers and awaiting buyer re-embursements.
  • the close section displays all completed transactions.
  • FIG. 10 is a block diagram of a system according to an embodiment of the invention.
  • the system allows a paying entity to define the invoice format for invoices it wishes to receive.
  • the system facilitates routing, editing, dispute resolution, and disbursement of payment.
  • the system includes payer (buyer) shown as 1001 , payee (vendor) shown as 1002 , and financial institutions shown as 1050 .
  • the system has the following characteristics according to one implementation: collaborative network model, A/P (buyer) centric enterprise software, plugging into existing ERP systems, full cycle bill-to-pay functionality, web-based A/R (vendor) software, and co-existence with the customer existing bank relationships.
  • the reconciliation engine provides methods of matching existing vendor name/address with self enrolled vendor information in the global directory. These methods include: fuzzy attributed weight based matching shown as 1030 , previous vendor histories of matching in the knowledge based shown as 1031 , third party outsourced recommended matching proposal shown as 1032 , and manual interactive selection from buyers shown as 1033 .
  • Each vendor is represented by several critical attributes in the global directory: addresses shown as 1038 , real and alias accounts shown as 1039 , and keys shown as 1040 . Vendor entries are pre-populated with information uploaded from the buyer ERP system. The vendor enrolls via the online self-service enrollments 1035 . Vendor also provides additional rules to match 1034 , A/R remittance format attributes 1036 , and notification rules/addresses 1037 .
  • Accounts payable (A/P) buyer-centric enterprise software associated with payer system 1001 includes several key unique functions. These functions include buyer defined electronic invoice exchange, routing/editing and approval, and dispute resolution.
  • Payer system 1001 includes invoice definition engine 1003 , invoice 1004 , HR organization data 1008 , routing/editing logic 1005 , dispute logic 1009 , notifications logic 1012 , disbursement logic 1013 , dynamic terms logics/offers 1060 , discount logic 1016 and settlement logic 1017 .
  • Also included on payer system 1001 are input output (I/O) 1010 , processor 1011 , entity key 1015 , and payer central repository database 1027 .
  • I/O input output
  • the invoice definition engine 1003 includes validation logic 1053 , tolerance/replacement items 1055 , interaction severity 1054 , and several presentation forms 1056 . This definition engine is controlled by payer helps provide clean invoice data from payees.
  • the definition logics 1053 , 1054 , 1055 , and 1056 ) can be configured to specific payee or a specific group of payees.
  • Invoice definition engine 1003 and its definition logics are exposed to payee via global directory and are operative with invoice definition generation/validation 1018 of payee system 1002 .
  • the routing/editing logic 1005 includes business logic that governs how an invoice will be processed by AP clerks, and what data entry information will be required to complete the transaction. Routing/editing logic 1005 can operate differently based on multiple attributes: document type, document value, discount value, etc. Routing/editing logic 1005 acts on HR organization database 1008 to define routing/editing/approval work flow based on employee information 1007 and role values 1006 .
  • Invoice 1004 is coupled into routing logic 1005 /Routing logic 1005 is coupled with employee logic 1007 and role assignment 1006 .
  • Routing logic 1005 is coupled with HR data 1008 and with dispute logic 1009 , notifications logic 1012 and disbursement logic 1013 of payer system 1001 .
  • Notification logic 1012 is configured by the payer, and includes collaborative filtering, and mappings status and notification definitions between internal o external payees. These collaborative filtering and mappings can be designated to a payee or a group of payees.
  • Dispute logic 1009 is set of payer defined centric collaboration rules and interactions between payer and payee to resolve issues related to invoice or other exchanged documents. Some disputes are simple (e.g., number of items is received, etc.) while others are more complex (e.g., replacement items do not meet part specification and price). The outcomes of a dispute are partial payments, partial invoices, new invoices, or other outcomes. According to one implementation, a dispute can only he finalized by payer and its members, and some finalized exchanges will require digital signature to ensure non-repudiation.
  • the payer dispute logic 1009 orchestrates with payee dispute logic 1022 . Payer dispute logic, references, and history are stored in payer central repository 1027 .
  • Payee system 702 includes a processor 1052 and input/output (I/O) 1051 .
  • processor 1052 and input/output 1051 allow for communication with other entities such as payer system 1001 , financial institutions 1050 and global database 1028 .
  • Processor 1052 and processor 1011 of payee 1002 and payer 1001 respectively may run various software processes to implement the logic shown. The processes may be implemented as software objects, routines or other software processes, programs or implementations. Alternatively, portions of such logic may be implemented in hardware logic or other forms of logic.
  • Data and information such as for global database 1028 may be stored in data structures or other data format and stored in computer memory, fixed storage or other data storage or archived in various implementations of the invention.
  • Payee system 1002 includes invoice generation/validation logic 1018 , invoice send logic 1021 , dispute logic 1022 , notifications logic 1023 , receipt/validation logic 1024 , discount logic 1025 and settlement logic 1026 .
  • Invoices or other documents can be submitted to payer via multiple mechanism. Three sample mechanisms are shown here: Web forms shown 1057, purchase order pre-populated invoice (PO flip) 1058 , and electronic file submission via file mapping 1019 .
  • the Web forms 1057 are a set of payer defined presentations that can be selected and/or authorized to be used by payee(s). Payee can also define additional payee private attributes and fields to be used during A/R matching as well as graphic materials (such as company logo, etc,).
  • the PO flip 1058 uses information from purchase orders which are transmitted to payee from payer to pre-populate the invoice data. The status of each purchase order is maintained within the payee central repository to support blanket purchase orders.
  • File mapping 1019 is used by the payee to automate the bulk invoice submission process. Normally, these file are exported from payee's A/R system. The mapping defines bow payee's data will be mapped into payer, as well as default/validation/transformation rules.
  • the documents are validated based on the payer definition engine 1018 .
  • This definition engine 1018 includes payer definition engine 1003 and its components: validation 1053 , severity 1054 , tolerance 1055 and presentation 1056 .
  • Invoice generation/validation logic 1018 is coupled with mapping logic 1019 in communication with the data 1020 . Invoice generation/validation logic 1018 is coupled into invoice send logic 1021 . Dispute logic 1022 is coupled with dispute logic 1009 of payer system 1001 . Notifications logic 1023 is in communication with notifications logic 1012 of payer system 1001 and discount logic 1025 of payee system 1002 . Receipt/validation 1024 of payee system 1002 is in communication with disbursement module 1013 of payer system 1001 . Settlement logic 1026 is operative with discount logic 1025 of payee system 1002 and receipt/validation logic 1024 .
  • Global database 1028 is available to notifications logic 1012 and 1023 , disbursement logic 1013 , settlement logic 1017 and 1026 , invoice send logic 1021 , receipt 1021 and receipt/validation logic 1024 .
  • Global database 1028 is in communication with payer database 1027 through attribute match rules 1030 , knowledge based history matching samples 1031 , third party recommendation/proposal 1032 and manual interactive matching by payers 1033 .
  • Global database 1028 is in communication with payee database 1029 through match rules 1034 , enrollment logic 1035 , remittance formats 1036 and notification preferences 1037 .
  • Global database includes items such as address 1038 , accounts 1039 and public keys 1040 .
  • Payer database 1027 is located with payer system 1001 and payee database 1029 is located with payee system 1002 .
  • Global database 1028 is also available to financial institutions 1050 .
  • invoice definition engine 1003 a payer uses payer system 1001 to define the invoice that the payer wishes to receive. Such definition helps to increase efficiency in the payer system because the resulting invoice from the payee, such as a seller, is more likely then in the proper data format when it is received.
  • Payee system 1002 generates an invoice based on the defined invoice in invoice generation/validation logic 1018 .
  • the input data for the invoice is validated based on the invoice definition rules defined in payer system 1001 . If file data is used to automatically map into an invoice, such mapping is performed in one embodiment of the invention by mapping logic 1019 .
  • Mapping logic 1019 receives the file data 1020 with information to be populated into respective invoices.
  • File data 1020 may contain files with data for invoices for various payers who have purchased good or services from the payee. When an invoice is completed it is sent through invoice send logic 1021 to payer system 1001 . Additional information regarding definition of invoice by the buyer and use of related invoice rules is contained in United States patent application entitled System and Method for Electronic Payer (Buyer) Defined Invoice Exchange, U.S. patent application Ser. No. 10/155,840, invented by Duc Lam, Ramnath Shanbhogue, Immanuel Kan, Bob Moore and Xuan (Sunny) McRae, which is incorporated herein by reference in its entirety.
  • invoice 1004 An invoice is received at payer system 1001 as shown here with invoice 1004 .
  • the invoice is routed to the respective employees or other agents for its review and approval. Some approval may require additional signatures according to one embodiment of the invention.
  • employee logic 1007 is in communication with routing logic 1005 to allow an employee to authorize, audit or view respective invoice car check information.
  • Routing logic 1005 is also used to route checks or other documents to various employees for signature or approval using HR data 1008 .
  • Routing logic 1005 uses HR data 1008 to determine the correct employees to whom to route the respective document, such as in an invoice or check. Routing may be made to the manager of a respective employee if the employee has not responded in a certain time to the document. Such the choice of such manager to whom to route is made based on the management hierarchy in the organization stored in HR database 1008 .
  • HR database is extracted from a human resource management system (HRMS), in one implementation of the invention. Additional information regarding routing of documents in the system is described in United States patent application entitled Method and System for Invoice Routing and Approval in Electronic Payment System, U.S. patent application Ser. No. 10/155,853, invented by Bob Moore and Xuan (Sunny) McRae, which is incorporated herein h reference in its entirety.
  • a user of payer system 1001 may dispute an invoice or other payment request through dispute logic 1009 .
  • Dispute logic 1009 is in communication with dispute logic 1022 of payee system 1002 . This allows for communication regarding a dispute between a payer and a payee.
  • the dispute may be only initiated and finalized by a payer. According to one embodiment of the invention, the dispute may be finalized only by the buyer, or the payer system.
  • the dispute includes the capability to indicate that particular items in an invoice are disputed, such as the tax.
  • the dispute logic 1009 and 1022 include the capability for individuals using the payer system 1001 using payee system 1002 to engage in a chat dialog.
  • Notifications logic 1012 communicates completion of various stages of approval or other issues of status regarding invoices and disbursement. For example, when an invoice is approved notifications logic 1012 communicates a notification to notifications logic 1023 of payee system 1002 . Based on such notifications, a discount may be enabled through discount logic 1016 , which is in communication with discount logic 1025 of payee system 1002 . For example, where an invoice is approved, a discount may be enabled based on an agreement or outstanding dynamic terms offers shown as 1060 that the corresponding payment is made earlier than required under the original terms and conditions. Dynamic terms are additional real-time terms, a set of rules, and/or goal seeker that are established by payer 1060 or payee 1061 .
  • dynamic terms rules 1060 and 1061 are based on business event types (invoice approval, purchase order approval, etc. ⁇ , a payee or group of payee and a set of new discrete or variable terms. These dynamic term goal seekers allow payer and payee to set desirable outcomes. These dynamic terms can be pre-negotiated up-front or in real-time based on business event types. The approval of these new terms may require digital signature of either payer or payee. Also, third party financial institutions could be involved to provide funding for payee in returns for early discounts.
  • Disbursement logic 1012 includes all payment routing, signing, and approval logic for respective invoices or other requirements for payment. Some payments will require multiple signatures to be signed based on payment amount and/or destination payee(s). Digital signatures and nondigital signatures may both be used. Also, payer can configure to control new settlement date for the payment by defined payee group and number of business/calendar days to be adjusted.
  • the disbursement logic also includes auditing capability with multiple levels based on number of signatures and/or amount in one implementation, disbursement logic 1013 makes such disbursement in the form of electronic checks in one implementation. Such electronic checks are generated and signed with a digital signature.
  • the digital signature may be obtained from respective users such as through a routing process using routing logic 1005 to obtain a signature from employee logic 1007 with role assignment digital key 1006 .
  • a set of instructions may be received to send a set of checks that use a digital signature of the payer organization rather than the digital signature of an employee.
  • Such check processing may be accomplished through batch processing logic 1014 and disbursement logic 1013 .
  • Such batch processing logic 1014 uses an entity key 1015 , which is a private key of the payer's organization.
  • Batch processing logic 1014 requires particular authorization for the respective instruction. The authorization may require that the agent requesting the set of checks sign the instruction with the agent's private key.
  • Receipt/validation logic of payee system 1002 is in communication with disbursement logic 1013 .
  • Receipt/validation logic 1024 receives payment, such as in the form of electronic checks.
  • Receipt/validation logic decrypts any encrypted documents, for example if the electronic checks are encrypted with the public key of payee system 1002 , such checks are decrypted. Additionally, the digital signature of the sender is authenticated in receipt/validation logic 1024 . Such authentication is accomplished using the public key of the payer, which corresponds to the private key of the payer's organization (entity key 1015 ) that was used in batch processing logic 1014 (entity key 1015 ). Additionally, verification may be made against a payment database generated by the payer system when the checks are created in order to assure that the checks were actually sent by the payer system.
  • Settlement logic 1017 allows for settlement of payment between a payer system 1001 and payee system 1002 .
  • Settlement mechanism includes exiting combination of paper based checks, standard domestic electronic payment network (Fed Wire, ACH, CHIPS, etc), international electronic payment networks (SWIFT, Bolera, etc.), propriety private payment networks (VISA, MasterCard, and American Express, etc.), and internal account bank transfer (On-us, etc.)
  • settlement may be made through debits and credits in a database within the system.
  • settlement may be performed through an external network such as the ACH network with financial institutions involved, such as financial institutions 1050 .
  • Settlement logic 1017 supports standard fund transfer model (buyer's account will be debited and supplier's account will be credited) and good funds model (buyer's account will be debited and a temporary account will be credited. Upon receiving fund availability in temporary account, the supplier will be credited). Settlement logic 1017 is implemented via issuing requests to the settlement network. Such request can be tile-based requests such as ACH or transactional request such as VISA networks. For each request, there will be associated confirmation ID to ensure the trace ability of each transaction.
  • Global database 1028 is available for use by elements that send payment, such as disbursement logic 1013 and settlement logic 1017 .
  • Global database 1028 is also available for elements that send other documents or information between payees and their respective financial institutions. For example, invoices may be sent based on the respective recipient address as stored in the global database 1028 .
  • invoice sends logic 1021 is in communication with global database 1028 .
  • Global database 1028 includes addresses and account information for respective payers and payees who use the system. Links are created between items in the global database and other databases in order to allow for the global database to be updated and the corresponding linked information to continue to be used.
  • a payer has a separate database, payer databases 1027 , and matches are created between items, such as addresses or payment entities and payer 1027 and respective items in global database 1028 through a match generation process 1030 .
  • Such matched generation process 1030 may include providing a user of the payer system 1001 with a series of candidate matches between addresses stored on payer database 1027 and corresponding spellings of addresses or payment entities in global database 1028 . The user of payer system 1001 is then able to select the best match and create a link between the respective address or payment identification.
  • This link can then later be used to effect payment to the proper address as stored in the global database.
  • a match generation between items in payee database 1029 and global database 1028 can be performed so that payee system 1002 can send items to the proper recipient using information in global database 1028 .
  • Enrollment logic 1035 is available to enroll new entities as payees into the global database to make them available for use by payer system 1001 or payee system 1002 .
  • the links established are then available to allow for use of information in the respective payer database 1027 and payee database 1029 in order to find recipients to whom documents or payments are to be sent.
  • public keys of various participants in the systems are stored in the global database 1028 . Such keys are then available for use in order to determine the accuracy of a digital signature sent h a particular entity. Additional information regarding global database 1028 and related logic and communication is contained in the United States patent application entitled Method and System for Collaborative Vendor Reconciliation, U.S. patent application Ser. No.
  • invoices and other documents are exchanged between payers and payees over the public and internet networks 1080 .
  • invoices and or documents are signed with source private key, and encrypted with destination public key shown as 1081 .
  • the document is decrypted with its own private key, and validated against source public key to ensure non-repudiation shown as 1082 .
  • the system also can integrate with multiple enterprise resource planning (ERP) systems shown as 1062 .
  • ERP systems include: PeopleSoft, SAP, Oracle Financials, etc.
  • the system will integrate with these ERP systems via native and/or standard interfaces.
  • An example of native interface for PeopleSoft is Message Agent, etc.
  • the interfaces include EDI gateway, etc.
  • the system utilizes the ERP to extract documents (purchase orders, invoice status, unit of measurements, vendor list, etc.), to post documents (invoices, vendor information, status, etc.).

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Tourism & Hospitality (AREA)
  • Game Theory and Decision Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

A method of making payment. A request is received to effect payment between a buyer and a seller for a transaction having established terms. The terms include a payment amount and a settlement date. Messages are exchanged between the buyer and the seller that include an offer and acceptance of new terms for payment at other than the established terms. The new terms include an adjusted amount of payment to be made at a particular time after an event associated with the transaction. An electronic notification that the event has occurred is received, and the after the notification, payment between the buyer and seller is effected under the new terms.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This patent application is a Divisional of U.S. patent application Ser. No. 13/543,248, filed Jul. 6, 2012 which is a Divisional of U.S. patent application Ser. No. 13/162,185, filed Jun. 16, 2011 which is a Continuation of U.S. patent application Ser. No. 12/754,575, filed on Apr. 5, 2010 which is a Continuation of U.S. patent application Ser. No. 10/155,806, filed on May 24, 2002, now abandoned. The disclosures of these priority applications are hereby incorporated by reference in their entirety.
  • REFERENCE TO RELATED APPLICATIONS
  • This application is related to the following United States patent applications:
    • Method and System for Collaborative Vendor Reconciliation, U.S. patent application Ser. No. 10/155,797, invented by Duc Lam, Georg Muller, Chandra (CP) Agrawal, Baby Lingampalli, Pavel Lopin and Xuan (Sunny) McRae;
    • System and Method for Electronic Authorization of Batch Checks, U.S. patent application Ser. No. 10/155,800, invented by Duc Lam, Matthew Roland and Xuan (Sunny) McRae;
    • System and Method for Electronic Payer (Buy) Defined Invoice Exchange, U.S. patent application Ser. No. 10/155,840, invented by Duc Lam, Ramnath Shanbhogue, Immanuel Kan, Bob Moore and Xuan (Sunny) McRae;
    • Method and System for Invoice Routing and Approval in Electronic Payment System, U.S. patent application Ser. No. 10/155,853, invented by Bob Moore and Xuan (Sunny) McRae; and
    • Method and System for Buyer-Centric Dispute Resolution in Electronic Payment System, U.S. patent application Ser. No. 10/155,866, invented by Duc Lam, Celeste Wyman and Xuan (Sunny) McRae.
  • All of the foregoing applications are incorporated herein by reference in their entirety.
  • BACKGROUND OF THE INVENTION
  • 1. Field of the Invention
  • This invention relates to the field of software and computer network systems. In particular, the invention relates to electronic systems associated with financial transactions.
  • 2. Description of the Related Art
  • In traditional paper payment systems, an organization or an individual initiates payment by sending a physical check to the party to whom a debt is owed. The check may be sent in response to an invoice from the party to whom the debt is owed. A newer approach is electronic payment. For example, in the consumer context, individuals may be able to make, payment by way of electronic banking. Payment instructions are sent electronically from the individual's computer system to the individual's bank. Payment is then effected by the bank.
  • Numerous systems now exist relating to accounting and bill payment. For example, computer software is used to track invoices and print payment checks. Payments may be made by wire transfer, with instructions requesting funds of the payer in one financial institution to be transferred to an account of the party to whom payment is to be effected.
  • Enterprise resource planning (ERP) systems are used for managing the purchases of goods and services. Such systems may have databases of complex and extensive sets of information, such as addresses of various suppliers and similar information related to purchasing. Sellers also use electronic accounting and record keeping systems which may assist in the receipt and tracking receipt of payment for goods and services. Prior systems require considerable amounts of effort to update and maintain, and may lack compatibility with the systems used by parties with whom an organization wishes to engage in transactions. There is thus a need for improved systems to facilitate transactions between buyers and sellers.
  • SUMMARY
  • An embodiment of the invention is directed to a method of making payment. A request is received to effect payment between a buyer and a seller for a transaction having established terms. The terms include a payment amount and a settlement date. Messages are exchanged between the buyer and the seller that include an offer and acceptance of new terms for payment other than the established terms. The new terms include an adjusted amount of payment to be made at a particular time after an event associated with the transaction. An electronic notification that the event has occurred is received, and after the notification, payment between the buyer and seller is effected under the new terms. In one implementation, a digital signature indicating acceptance of the new terms is receive. A system may verify such signature before proceeding under the new terms.
  • According to different implementations, the event may include different forms of electronic notifications. For example, in one implementation, the event includes an electronic indication of approval of the seller's invoice by the buyer. According to other implementations, the event includes an electronic indication that the seller has shipped the goods ordered in the transaction, the buyer has received goods ordered in the transaction or the buyer has authorized payment for the transaction.
  • The different terms may take different forms. For example, in one embodiment of the invention, the different terms comprise a discount in exchange for payment a particular time between the settlement date and the event. In another implementation, the established terms include a discount date before which the seller is willing to offer a particular discount, and the new terms comprise a discount different from the discount provided in the established terms in exchange for payment a particular time earlier than the discount date. In another implementation, the new terms comprise a discount different from the discount provided in the established terms in exchange for a payment a particular time later than the discount date.
  • Another embodiment of the invention is directed to a method of making payment according to new terms, where the new terms include an adjusted amount of payment to be made at a particular time after an event associated with an invoice for the transaction. The invoice is received from the seller, and an electronic notification is received that the event associated with the invoice has occurred. After the notification, the payment is effected between the buyer and the seller under the new terms.
  • Another embodiment of the invention is directed to a method of effecting payment that includes receiving requests to effect a set of transactions with a set of entities. The transactions have established terms. A set of notifications of events associated with the transactions is received. Requests for offers of terms different than the established terms are sent to the entities, and the different terms are to apply to payment made at a particular time after the event. Offers are received in response to the requests, and a set of offers among the offers is selected based on a set of one or more criteria. After the respective events, payment is effected to the respective entities associated with the selected offers under the terms in the respective offers. The set of entities may comprise sellers, and the set of requests for offers may be sent by a buyer's system.
  • According to different embodiments of the invention, such requests and/or offers may be made differently. For example, according to one implementation, a series of requests to individual entities for offers of terms is made, and oilers are received from individual entities in response to the requests in the series. The requests may be made over time and with terms that are incrementally more attractive to the individual entities. In another implementation, a message is sent to individual entities with a series of different terms among which the entities may select to make the offers of terms. The series of different terms may include sets of proposed amounts of payment and associated dates of the payment. The sets may include multiple proposed amounts of payment associated with at least of some of the proposed dates of payment.
  • As indicated above, the offers may be selected based on a set of one or more criteria. The set of one or more criteria includes a risk assessment of the respective entity according to one implementation. In another implementation, the set of one or more criteria includes amount of savings per transaction, and in another implementation, it includes amount of time remaining before settlement date in the respective transaction.
  • Another embodiment of the invention is directed to a method of making payment involving a buyer, seller and a third party. According to one embodiment, the third party is a financial institution, such as a bank. Notification regarding the existence of a transaction between a buyer and a seller is received. The transaction has established terms, which include a payment amount and a settlement date. Messages are exchanged between the buyer, seller and a third party that include an offer and acceptance of new terms for payment other than the established terms. The new terms include an amount of payment to be made by the third party to the seller at a particular time after an event associated with the transaction. Electronic notification is received that the event has occurred. After the notification, payment of the adjusted amount is effected from the third party to the seller under the new terms. After payment by the third party, payment between the buyer and the financial institution is effected under the new terms. Terms are negotiated between third party and buyer are independent of terms between third party and seller according to one implementation. The transaction binds both sellers and buyers. The event includes, according to different embodiments, an electronic indication of approval of the seller's invoice by the buyer, electronic indication that the seller has shipped the goods ordered in the transaction, electronic indication that the buyer has received the goods ordered in the transaction, or electronic indication that the end user at the buyer's organization has received the goods ordered in the transaction.
  • Another embodiment of the invention is directed to a system for making payment. The system includes a first system associated with a seller and a second system associated with a buyer. The first system includes logic that generates an invoice and sends the invoice to a buyer. The invoice has an associated set of terms. The first system also includes logic that, in response to a request for an offer front the buyer, sends at least an offer to the buyer for a new set of terms other than the terms associated with the invoice. The offer applies to payment after an event associated with processing of the invoice. The second system associated with the buyer includes logic that receives the invoice from the seller and logic that generates and sends to the seller the request for an offer. The second system also includes logic that receives the offer from the seller, logic that sends an electronic indication to the seller accepting the offer from the seller and logic that generates electronic indications of events associated with processing of the invoice. The second system further includes logic that effects payment from the buyer to the seller according to the new terms after receipt of electronic indication of the event associated with the processing of the invoice.
  • According to a particular implementation, the second system includes logic that sends requests for offers of new sets of terms to systems associated with a plurality of sellers. The offers apply to payment after an event associated with processing of associated invoices, and the new terms are different from previously established terms associated with the invoice. This logic also accepts a subset of the offers and effects payment under the new terms alter the respective events in response to the offers for new terms.
  • Another implementation of the invention includes logic that selects the subset of offers based on whether a goal has been met. The goal may include an amount of sayings, duration of the goal, or combination of the amount and duration. The goal may also include other criteria such as other financial goals or a combination of goals and tolerance for risk.
  • In another embodiment of the invention, the first system includes logic that sends requests for offers of new sets of terms to systems associated with a plurality of buyers. The offers apply to payment after an event associated with processing of associated invoices. This logic also accepts a subset of the offers and accepts payment under the new terms after the respective events in response to offers for new terms.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 shows a block diagram of a system for payment with discounts according embodiment of the invention.
  • FIG. 2 shows a flow diagram for discounted payment according to an embodiment of the invention.
  • FIG. 3 shows a block diagram of a system for payment with logic to make offers to a set of entities according to an embodiment of the invention.
  • FIG. 4 shows a flow diagram for creation of a campaign for discounted payment according to an embodiment of the invention.
  • FIG. 5 shows a block diagram of a system for discounted payment involving a financial institution according to an embodiment of the invention.
  • FIG. 6 shows a flow diagram for discounted payment involving a financial institution according to an embodiment of the invention.
  • FIG. 7 shows a timing, diagram for discounted payment according to an embodiment of the invention.
  • FIG. 8 shows a user interface for a banking system according to an embodiment of the invention.
  • FIG. 9 shows a user interface for a payer system according to an embodiment of the invention.
  • FIG. 10 shows a system for electronic payment according to an embodiment of the invention,
  • DETAILED DESCRIPTION
  • An embodiment of the invention is directed to a system for dynamically adjusting the terms of payment in a transaction based on electronic notification of events associated with respective transactions. For example, early payments may be made after receipt of electronic notification of an event such as approval of the respective invoice or release of the payment for the invoice. An offer is made for an adjustment of the terms that apply to payment at a time after the respective event. In one implementation, one entity, such as a buyer, sends requests to a set of entities, such as sellers, for offers of terms different than the established terms between such entity and the respective other entities. In one implementation, the entity that sent the request selects among offers receive from the set of entities based on a goal. The entity that sent the request continues to evaluate offers of new terms until the goal have been reached. After acceptance of an offer, payment is then effected at a time after the respective event under the newly agreed upon terms.
  • An electronic notification of event may be made based on an action of an employee or other individual in the organization that is making the payment. For example, the event may be the approval by the responsible employee of the invoice associated with the transaction. In one implementation, the response is made through a response to an email notification regarding the invoice received by an employee of the payer organization. The employee is able to approve the invoice based on events regarding the status of the order. For example, the employee may approve the invoice when the employee determines that the goods ordered have been received. Approval of the invoice may alternatively occur automatically. For example, the invoice may be automatically approved when a procurement system sends a notification that the goods have been received and that the invoice data is accurate as compared to the corresponding purchase order.
  • One embodiment of the invention is directed to making payment at other than the agreed-upon time and on other than the agreed-upon terms at a time after electronic notification of an event regarding status of the respective order. The electronic notification regarding status of the order includes, according to different implementation, electronic notification regarding events that provide different level of confidence that the respective goods or services will be received satisfactorily and that payment will be properly authorized. Such events include the following:
      • Purchase order sent from buyer to seller;
      • Seller purchases parts on buyer's behalf;
      • Parts for order purchased by seller;
      • Goods completed by seller;
      • Goods completed to a particular percentage of completion;
      • Inspection of goods completed;
      • Goods designated ready to ship;
      • Shipment sent by seller;
      • Shipment in possession of a common carrier;
      • Shipment received by buyer;
      • Other buyer-determined status of shipment;
      • Shipment received by end-user individual in buyer's organization who ordered the shipment;
      • Service started;
      • Service is a particular percentage complete, or service completed;
      • Invoice approved by end-user;
      • Invoice approved by accounts payable;
      • Invoice approved by the responsible manager;
      • Final approval of the invoice at the buyer's organization;
      • Payments for the invoice approved by accounts payable department in buyer organization;
      • Approval received for payment;
      • Payment approved for release; and
      • Other event defined by the buyer which indicates a particular level of
      • confidence that the goods or service will be satisfactory delivered. Electronic notification of respective events is provided. In various implementations, super and sub combinations of the above events are available for selection for use to trigger a payment under terms other than the originally agreed terms. For example, in one implementation, the system allows a buyer to trigger payment after any or a subset of the following events: (1) the purchase order sent to the seller, (2) the invoice has been approved and (3) payment has been approved for the respective order. The buyer is then able to select based on risk and other factors which of these events is to be used to trigger payment for particular transactions, particular seller or sets of transactions or sets of sellers.
  • The buyer and seller may negotiate the new terms for payment based on different factors. For example, based on a simple time value of money based on a selected interest rate calculation, the change in the payment amount can be calculated based on the number of days earlier or later than the originally agreed-upon settlement date that payments occur. An interest rate may be used that extrapolated from the discount provide in the seller's original terms, or the original terms in the original agreement between the buyer and the seller. An advantage of the above approach is that a greater degree of granularity for adjustment of payment terms is provided in certain embodiments of the invention.
  • One embodiment of the invention is directed to requesting offers from multiple parties for a change or changes in payment terms to make payment on other than the agreed upon terms at a time after electronic notification regarding the status of the order. Such request for offers may be made by a buyer to respect the seller, seller is to respect the buyer or a combination of seller to respective buyers. Parties to whom such requests are sent may be selected based on the sizes of the transaction, potential savings to be received, potential amount of advanced cash flow to be obtained, reference standing at the party, the amount of term left in the transaction and other factors related to confidence with respect to other entities such as the credit rating or experience with the particular party. The selection based on the size of the transaction may be made based on the size of the outstanding transaction with the party in aggregate and alternatively may be made based on the size of individual transactions. Offers may then be accepted based on a goal such as aggregate savings to be achieved or amount of advance in cash flow.
  • The request for offers may be made as the respective electronic notification of the event occurs. Alternatively, a negotiation may take place between respective parties regarding the type of adjustment to the terms to take place after electronic notification of respective event will occur. For example, a buyer and seller may agree that after the buyer approves the invoice for an order, that the buyer may make early payment and receive an adjustment in the amount owed based on an interest rate and based on the number of days remaining before the originally required settlement date.
  • FIG. 1 shows a block diagram of a system for payment with discounts according to an embodiment of the invention FIG. 1 includes payer system 101 and payee system 102. Payer system 101 includes computer electronics such as processor 110 and input/output (I/O) 109. Other electronics such as those found in a computer server may be included in payer system 101 according to an embodiment of the invention. Payer system 101 includes routing logic 104 and approval logic 105 which is coupled thereto, Approval logic 105 is coupled with payment release logic 106, term adjustment 107 and order status logic 111, which are also included in payer system 101. Payer system also includes settlement logic 108 which is coupled to payment release logic 106 and settlement logic 123 of payee system 102, and offer logic 130, which is coupled to terms adjustment logic 107 and offer logic 131 of seller system 102. Routing logic 104 of payer system 101 is coupled with an invoice 103 received at payer system 101.
  • Payee system 102 includes an invoice creation logic 120 which is coupled with invoice 103 of payer system 101. Payee system 102 also includes approval/notification logic 121 coupled with term adjustment 122 and settlement logic 123, which are also included by payee system 102. Additionally, payee system 102 includes offer logic 131, which is coupled to discount logic 122 and offer logic 130 of payer system 101. Payee system creates an invoice using invoice creation logic 120. The invoice is created based on art invoice definition provided by payer system 101, according to one implementation. Invoice 103 is received by payer system 101 from invoice creation logic 120 of payee system 102.
  • Invoice 103 is routed to the appropriate personnel or mechanisms in order to have the invoice approved and verified for payment. Approval is carried out by approval logic 105, which is coupled with routing logic 104. Approval may be based on the status of the particular order, and such status may be obtained automatically by order status logic 111. Order status may include such items as whether the goods for which the invoice is received have been shipped or whether they have been received by the payer organization. Order status logic 111 may obtain additional information regarding the order status, such as automatically available information regarding the quantity of equipment received based on a just in time (JIT) or other inventory management system. Thus, order status logic 111 may be coupled with an enterprise resource planning (ERP) system. After the respective order is approved, payment made, the payment is released. Such action is carried out by payment release logic 106, which is coupled with approval logic 105.
  • Offer logic 130 makes a request for an offer of different terms other than those established terms associated with a particular transaction. Upon acceptance of the respective offer, the transaction can be effected under the different accepted terms. Thus, offer logic 130 communicates with terms adjustment logic 107 to adjust the terms that will be applied to the particular transaction or transactions. The request for an offer and receipt of the respective response may be made in advance of the event that will trigger payment, according to one embodiment of the invention. Alternatively, at least some portion of the interaction regarding the offer may be made upon receipt of electronic notification of the respective event, such as after receipt of electronic notification that an invoice for the transaction has been approved in payer system 101. Offer logic 130 may include criteria under which offers are accepted. In such an implementation, an offer is accepted only if it meets the configured criteria. Upon acceptance of an offer for newly defined terms, and after the receipt of electronic notification of the respective event, terms adjustment logic 107 calculates a new settlement date and payment amount. A notification is sent to seller system 102 to indicate acceptance of the offer of the newly defined terms.
  • Terms adjustment logic 107 implements the respective adjustment to the original payment amount (such as a discount) that is to be made in exchange for an adjusted payment date. Terms adjustment logic is coupled with payment release logic 106 and approval logic 105 so that an adjusted payment may be triggered upon an approval of the invoice or a release of the respective payment. Terms adjustment logic 107 is in communication with discount logic 122 of payee system 102 in order to reconcile the respective discount. Settlement logic 108 settles respective payment between payer system 101 and payee system 102 in communication with settlement logic 123 in payee system 102. Such settlement settles payment of the respective amount minus any discount taken for early payment as determined by terms adjustment logic 107.
  • The logic modules shown may be implemented in software processes in communication with each other. Some functionality may be shared between different respective modules for design, efficiency and other reasons. Alternatively, aspects of the respective logic modules may be implemented in hardware or a combination of hardware and software. The functions shown may be implemented on a computer system with a processor input/output, such as shown here with processor 110 and input/output (I/O) 109. Thus, payer system 101 may be implemented on a computer server and payee system may be implemented on a different computer server. Alternatively, functions of the payer system 101 and payee system 102 may be implemented on a common server. Functions of the various systems may also be distributed on different computer systems or servers. Such computer systems or servers may communicate through direct links or over a computer network, such as the internet.
  • FIG. 2 shows a flow diagram for discounted payment according to an embodiment of the invention. An offer is made to adjust timing of payment in exchange for adjusting the amount of payment. If the offer is accepted, an invoice is paid according to the newly agreed payment terms. A trigger event is an event after which payment is effected. A trigger event is an event such as approval of the invoice before the original due date or release of payment for the invoice before the original due date.
  • First payment terms are established with the original due date (block 201). Next an offer is made for the adjustment of terms program. In the case of a seller, the seller offers the buyer a discount in the amount otherwise owed in exchange for early payment by the buyer (block 202). In the case of the buyer, the buyer offers the seller early payment in exchange for a discount from the amount that otherwise would he owed by the buyer (block 203). Such process of offering a discount for early payment is, according to an embodiment of the invention, carried out automatically by a system sending requests to various buyers or sellers for the different terms. If assent from the other party to discount for early payment is not received (block 204), then effect payment according to the original terms (block 205). If assent from the other party to the discount for an exchange for early payment is received (block 204), then proceed to process the invoice and provide the discount. It is possible that other arrangements for adjusting the payment may be established at this stage. For example, the buyer may agree to make payment at a date having a relation to the original settlement date, and after a particular trigger event in exchange for an adjustment in the amount paid by the buyer. In one example, such adjustment is a discount from the payment required under the originally established payment terms.
  • The terms may also be adjusted by the respective party starting the negotiation making a request for offers of adjusted terms rather than making an offer of adjusted terms. The party making such request then decides to accept or not accept the offers that are received. The exchange of such requests and resulting offers may be made after receipt of the trigger event, according to one implementation of the invention. Thus, in such an approach, the actual times that payment may be made after the trigger event is established and the corresponding amounts of payment to be made on such date or possible dates are proposed. According to another implementation, the offering and campaign process definition/setup is independent of incoming invoices. The trigger events occur when a business document is approved, received, or when other events regarding the document or order occur.
  • The invoice is received from the vendor in the vendor system (block 206). Such invoice may be created by the vendor based on a set of rules provided by the buyer, according to one embodiment of the invention. Next, the seller invoice is validated (block 207). Such validation may include checking various aspects of the data provided for the invoice. Such validation may be based on a set of rules provided by the buyer, according to one embodiment of the invention. The completed invoice is then signed and encrypted (block 208). The signing of the invoice, according to one embodiment of the invention, is performed using a digital signature of the seller so that the recipient can verify that the invoice has been sent by the seller. The invoice is encrypted to help provide security. Encryption may be performed using a public key/private key scheme and the encryption would be performed using the public key of the recipient. Then the invoice can later be decrypted using the private key of the recipient according to the public key/private key scheme. Next, the invoice is sent to the buyer system (block 209). Such sending may be performed by placing the invoice into an e-mail format and sending that e-mail over an e-mail link between the buyer system and the seller system. Alternatively other forms of electronic communication may be used to send the invoice, such as http post, ftp, electronic data interchange (EDI).
  • The invoice is received at the buyer system (block 210). The invoice is decrypted and authenticated in the buyer system (block 211). Such decryption may be performed using the private key of the buyer, assuming that the invoice was encrypted using the public key of the buyer. The invoice is authenticated by determining whether it was sent by the seller. Such authentication may involve a public key/private key scheme and, assuming that the invoice was digitally signed by the seller system, is performed using the public key of the seller. The data of the invoice is validated to ensure that it meets certain characteristics preferred by the buyer (block 212). Such characteristics may include “such as the format of the data as well as whether the data in the invoice may have certain values.
  • Next, the invoice is routed in the buyer system (block 213). The invoice is routed to various recipients within the buyer system in order to receive their input regarding the invoice. Their input may include approval of the invoice or acknowledgement of receipt of the invoice. Based on events such as the approval by recipients in the routing process, a trigger event may occur. A trigger event may also be based on an automatic update regarding the order status. For example, in one implementation, the system automatically determines that the respective goods have been shipped or that the respective service has been commenced. Alternatively, the system automatically determines that the respective goods have been received or that the respective service has been completed. Such determination automatically updates the trigger event. Alternatively, such information may be obtained based on user input through the routing process. A user receives, according to an embodiment of the invention, an electronic notification, such as an e-mail, regarding the respective invoice. The user is then able to respond to the message and indicate a status of the order. For example, an e-mail may be routed to the respective end user of the product that was ordered. The user then, according to one embodiment of the invention, provides an electronic notification to the system indicating that the user has received the goods ordered. In response to such indication from the user, the system may automatically cause the trigger event to occur. Alternatively, the user may indicate approval of the invoice.
  • A trigger event may be selected from among different type of events. For example, as shown here, the system provides a trigger event of either invoice approval or release of payment scheduled (block 214). The invoice approval may be determined based on a number of factors. As shown, the invoice is posted into the enterprise resource planning (ERP) system (block 215). The ERP system is notified to execute matching rules (block 216). The system monitors the status of the invoice to determine the action taken upon the invoice, such as whether it is approved by the user (block 217), if the invoice is approved, or within a certain amount of time, not approved, the respective status is sent to the seller (block 218). Based on such actions, if the approval of the invoice is received before the original due date (block 219), then the adjusted payment is effected (block 220). If the approval of the invoice is not received before the original due date, assuming that such action is the trigger event, payment is effected according to the original terms (block 222). The adjusted payment may take place upon, or shortly after the trigger event. Alternatively, the early payment takes place some time later after the trigger event but still before the original payment due date.
  • According to one implementation, a request for an offer of a new set of terms with an adjusted payment is sent after receipt of the trigger event. An offer is received from the seller in response to the request for an offer. The buyer may have proposed the new terms that the seller is to offer. The buyer may determine that it will reject the offer proposed by the seller and instead effect payment according to the original terms.
  • If the new terms have been accepted, and if the trigger event is release of payment scheduled (block 214), then it is determined whether the release of payment occurs before the original due date (block 221). If the release of payment does not occur according to the original due date (block 221), then payment is effected according to the original terms (block 222). If the release of payment is scheduled before the original due date (block 221), and the trigger event is the release of payment scheduled, then discounted early payment is effected (block 220). The early discounted payment may take place upon, or shortly after the trigger event. Alternatively, the early payment takes place some time later after the trigger event but still before the original payment due date.
  • FIG. 3 shows a block diagram of a system for payment with logic to make offers to a set of entities according to an embodiment of the invention. FIG. 3 includes buyer system 301, seller system A 302, seller system B 303, seller system C 304, and seller system D 305. Also shown in FIG. 3 are set of outcomes 306 and 307 as well as response 308 and 309. Buyer system 301 includes goal seeker logic 313, payment logic 314 and event generation logic 315. Also shown in buyer system 301 are event A 317 and event B 316. Goal seeker logic 313 includes rules 318, selection logic 319 and stop logic 320. Event A 317 and event B 316 each include information regarding the event. For example, event A 317 includes event type 324, identification of the vendor 321, identification of the amount in the transaction 322 and the settlement date 323. Offer request will be sent to proper seller based on vendor identification of the event.
  • In the system shown in FIG. 3, a buyer, through buyer system 301, makes a set of request for offers of new terms based on electronic notification of events. Buyer system 301 establishes a goal or set of goal to be achieved with the new terms. The goal includes criteria under which the attempts to achieve different terms will stop, and the stopping of the seeking of different terms is controlled, based on such criteria, by stop logic 320. Selection logic 319 determines how often sets of offers with changes in terms are evaluated and selected. Rules logic 318 determines whether an offer is sent to a seller or sellers based on a particular event. Such determination is made based on the identification of the vendor, the amount of payment in the transaction and settlement date.
  • Request for modified terms are sent to different sellers. As shown here, request 306 and request 307 are sent to seller system A 302 and seller system 8 303 respectively. Responses are received from sellers with offers for changes in the respective terms. For example, response 308 and response 309 are received from the seller system C 304 and seller system D 305 respectively. The request for an offer for a different set of terms may be in the form of a set of outcomes. For example, request 306 includes a set of dates of 310 and corresponding adjusted payments to he made 311. Such a request may have an additional dimension as shown in additional sets of outcomes 312. Such additional sets of outcomes may represent payments based on different interest rate calculations, for example. The seller responds with an offer with a selection of a subset of the set of outcomes. The buyer can then select among this subset and among such offers from varies other sellers.
  • The sellers may create their response oilers automatically based also on a goal seeking logic, as shown here with goal seeker logic 330 and seller system A 302. Such goal seeking logic may select among the outcomes to make offers based on various criteria. For example, such selection may be made based on credit rating, size of the payment, number of days that the payment is advanced, changed in date of payment versus interest rate or other criteria.
  • FIG. 4 shows a flow diagram for creation of a campaign or goal seeker for discounted payment according to an embodiment of the invention. A campaign may be undertaken in order to change the terms with a set of buyers or suppliers in order to achieve an earlier payment, for improved cash flow, or, as a buyer, to achieve reduced overall payments in exchange for making payments on an earlier schedule.
  • First, a set of buyers or suppliers is determined according to the desired savings (block 401). Such determination may be made in view of the respective amounts owed to a set of suppliers and the time before such payment is due. If the remaining time left before such payments are due is great enough, there is a potential for negotiating a significant discount in such payments. Based on the prevailing interest rates, and amount of outstanding balances, a set of buyers or suppliers may be selected to achieve the desired savings. In the case of suppliers, a set of buyers having substantial enough amounts owed to the supplier may be selected as candidates for early payment. This set may be selected based on the amount of payments outstanding and the remaining time for such payments. Selection may be made based on first choosing the set of organizations haying the largest outstanding balances and the most time remaining on such balances. Alternatively, one factor such as the amount of balances or time on such balances may be preferred over the other in various embodiments of the invention. Different subsets of buyers or sellers may be established based on various factors such as credit ratings, size, length of relationship or other factors. Then different rules for response are established for each group of buyers or sellers depending on the nature of the group.
  • Trigger conditions are defined (block 402). Such trigger conditions may be approval of the invoice or release of payment. Other trigger conditions may be selected in alternative embodiments of the invention. Negotiations are entered to achieve different payment terms in exchanging discounted payment for earlier payment. Such negotiations, according to an embodiment of the invention are performed in a step-wise manner (block 403). Such negotiations are performed by providing a series of offers for progressively better terms to the other party. For example, according to one embodiment of the invention, a buyer automatically offers successively earlier payments in exchange for a particular discount. Alternatively, a buyer oilers successively lesser discounts in exchange for a particular early payment. In one embodiment of the invention a seller offers successively greater discounts in exchange for a particular earlier payment schedule. In an alternative embodiment, the seller offers successively later payment schedule in exchange for a particular discount. Combinations of such offers may be used in alternative embodiments of the invention. In one implementation, the negotiation takes place after the trigger event (discussed below).
  • Next, define a set of approval rules (block 404). Such rules determine when the respective invoice is in a status such that it is sufficiently certain that the goods are received or the services have been rendered that the buyer can reliably guarantee payment (block 404). For example, depending on the rule, different trigger conditions may apply to different parties e.g. different sellers, or different buyers or different groups depending on the rules established. Next, notification and approval rules are defined (block 405). Such rules determine upon what conditions notification is provided regarding the status of the order. Examples of such rule include: wait for signed approval from particular individual (CFO, etc) if amount is greater than certain amount, auto approval if no approval action has not received in number of business days, or other rules. After such definition, the campaign can be enabled (block 406). Then, when such campaign is enabled, a trigger event occurs (block 407) and supplier approval, notification and confirmation rules are executed (block 408). Similarly, buyer approval, notification and confirmation rules are executed (block 409). In response, the final settlement date and amount are automatically adjusted (block 410).
  • FIG. 5 shows a block diagram of a system for discounted payment involving a third party such as financial institution according to an embodiment of the invention. A financial institution is involved in order to allow a seller to receive early payment for its electronically invoiced accounts. The seller system receives early payment upon or after a trigger event, such as approval of the invoice or release of payment by the buyer. The seller receives this payment from a financial institution at this earlier date. The buyer makes payment to the financial institution later. The payment received by the seller from the financial institution is discounted, and the payment made by the buyer to the financial institution is at a higher amount than what the financial institution pays to the seller.
  • The system shown in FIG. 5 is one embodiment of the invention to effect such transactions. The system shown includes a buyer system 501, seller system 502 and financial institution system 503. Buyer system includes payment terms setup logic 504, invoice 505, approval logic 506, payment and release logic 507, events logic 508 and payment with dates payable outstanding (DPO) logic 509. Payment terms setup logic 504 is coupled with buyer terms 513 of financial institution 503. Invoice 505 on buyer system 501 is coupled into approval logic 506 and payment release logic 507. Approval logic 506 is coupled with payment and release logic 507 and events logic 508. Approval logic 506, payment and release logic 507 and events logic 508 are coupled into event notices logic 520 which is coupled with event notification logic 523 of seller system 502. Approval logic 506, payment release logic 507 and events logic 508 are also coupled with event notification logic 514 of financial institution 503. Payment with dates payable outstanding logic 509 is coupled with payment and release logic 507 and approval logic 506. Logic 509 is also coupled with payment receipt logic 515 of financial institution 503.
  • Financial institution 503 includes buyer terms logic 513, event notification logic 514, payment receipt logic 515, seller terms logic 516, payment release logic 517, remittance information logic 518 and debit memo logic 519. Seller terms logic 516 is coupled with payment terms setup logic 521 of seller system 502. Payment release logic 517 is coupled with payment receipt logic 524 of seller system 502. Remittance information logic 518 is coupled, along with debit memo 519, to reconciliation logic 525 of seller system 502.
  • Seller system 502 includes payment terms setup logic 521, invoice generation logic 522, event notification receipt logic 523, payment receipt logic 524 and reconciliation logic 525. Payment terms set up logic 521 includes business events logic 526, fees logic 527 and terms logic 528.
  • Payment terms are set up between a buyer and a financial institution. The system facilitates such negotiation and set up with payment terms setup logic 504 and buyer terms logic 513. Payment terms setup logic determines the set of business events, days payable outstanding and percentage rebate provided under the agreed upon terms. Such setup is performed respectively by business events logic 510, additional DPOs logic 511 and percent rebate logic 512 respectively. After such terms are set up, they are stored by buyer terms: logic 513 to be available to automatically set the respective terms in future financial transactions.
  • Negotiation occurs between the financial institution and the seller. Seller terms logic 516 and payment terms setup logic 521 facilitates such negotiation and sets up the respective terms between the financial institution and the seller. The setup of the payment terms includes determination of the respective business events giving rise to the early payment, the fees charged by the financial institution to the seller for the early payment and the terms under which such payment is made. Such setup is performed by business events logic 526, fees logic 527 and terms logic 528 respectively.
  • The tasks performed by the logic shown in the systems shown may be performed by software programs. The software programs may run in modules in the organization shown. Such software may, according to various embodiments of the invention, be implemented as different schemes of software modules and/or classes or processes according to different system and communication requirements. According to one embodiment of the invention, buyer system and seller system are implemented on separate servers each with respective computer processor or processors. Alternatively the respective systems may be implemented on a common server or a distributed set of servers. Other implementations are possible such as in a distributed network environment.
  • After the terms have been set up between either the buyer system and financial institution or the seller system and financial system or a combination thereof, transactions may be performed using the new terms. According to one embodiment of the invention, only one of either the buyer or seller enters into an arrangement with the financial institution. According to another embodiment of the invention, both buyer and seller enter into arrangements with the financial institution to change the payment terms from the original payment terms.
  • An invoice is generated by seller system 502. As shown here, invoice 522 is created. Such invoice may be created and validated based on a definition of the invoice and rules for the invoice provided by a buyer or buyer system. The invoice is transmitted to the buyer system and received, as shown here as invoice 505. The invoice is subject to approval and other factors such as validation. Approval is performed by approval logic 506. When the invoice reaches the appropriate status payment may be released as performed by payment release logic 507. The event for which payment is released may be indications received from the users that the goods have been received and that appropriate management has approved the expenditure. Other events regarding the status of the invoice and order are recorded and transmitted by events logic 508. Notices of events such as approval, payment release and other events are transmitted to event notification logic 514 in financial institution 503. This allows financial institution to base payment to the seller system on the appropriate event the buyer system. Event notices are also transmitted as event notices 520 to event notification logic 523 of seller system. Payment is made from buyer system 501 to financial institution 503 by payment with DPO logic 509. This logic makes payment to the financial institution instead of the seller system because the seller is paid directly by the financial institution. Payment is made at the full amount of the invoice or some amount greater than the amount paid by the financial institution to the seller.
  • Seller system 502 receives payment in payment receipt logic 524 from payment release logic 517 of financial institution 503. Assuming the proper trigger event has occurred before the expiration date of such event, this payment is made at a time earlier than originally scheduled under the original terms between the buyer and the seller. The payment however is made at a discounted amount to account for the time value of money in having the payment made at an earlier time. Reconciliation logic 525 of seller system 502 reconciles the various records of payment including the original invoice records and other payment records with respect to remittance information transmitted from remittance info logic 518 and debit memo logic 519 of financial institution 503.
  • FIG. 6 shows a flow diagram for discounted payment involving a financial institution according to an embodiment of the invention. Terms are set up between a buyer and a financial institution allowing the buyer to make payment to the financial institution according to the normal payment schedule or later. Terms are set up between the seller and the financial institution allowing for the seller to receive payment earlier than the normal scheduled payment time in exchange for the financial institution paying the seller only a discounted amount of the original agreed upon payment amount.
  • The system facilitates negotiation of terms between the buyer and the financial institution (block 601). An association is established between an incentive program providing such payment terms and a buyer for the financial institution (block 602); this includes type of trigger events (invoice approval, good received, etc.), additional days payable outstanding (DPO) rebate percentage and/or other terms. The system receives a designated payment type for the buyer from the financial institution (block 603). The payment type defines how the financial institution will collect payment on behalf of the seller (e.g., credit to financial institution is sent by buyer, or financial institution will automatic debit from buyer's account according to different optional approaches). The financial institution has various payment types that are available for use by the buyer and a selection of the type agreed upon between the buyer and the financial institution is received. A credit limit is established for the buyer (block 604). Such credit limit may be determined based on a number of standard factors for determining credit. Additionally, the credit limit is established based on an analysis of the security of allowing for payment to the seller based on certain trigger events such as approval of the respective invoice by the buyer. Such events present a different risk profile than other types of events more typical of bank financing.
  • The following relate to setting up the vendor for financing. The normal vendor terms and conditions are received (block 605). Enrollment is received from the vendor for the additional terms and conditions with the financial institution (block 606). These additional conditions may include event type, discount rate, new term/due, and/or whether fixed or interpolated. Next, the approval is received from the financial institution of the vendor and the additional terms and conditions (block 607). Such approval may be based on various financial criteria regarding the vendor and the terms and conditions. Additionally, the approval may be based on an analysis of the security of basing payment to the vendor on particular events such as electronic approval of the invoice by the buyer or electronic notification of release of payment by the buyer. Based on the particular events selected and the type of notification, an analysis is made of the credit risk and appropriate financing terms are provided.
  • After the credit terms and agreement are established between the buyer and the financial institution and the seller and the financial institution, payment may be effected using the system, Payment is effected between the financial institution and the seller and between the buyer and the financial institution. An invoice is prepared and validated in the vendor system (block 608). The prepared invoice is received and validated in the buyer system (block 609). The approval of the invoice is received in the buyer system (block 610). Such approval may be made based on a selected set of factors such as approval by respective employees of the buyer system as described herein. The status is sent to the vendor and financial institutions (block 611). Such status may include the status of approval, release of payment or other events regarding the invoice and the respective order based on events received by and generated in the buyer system. In particular, notification of the trigger event upon which adjusted payment terms are based is sent to the vendor and financial institution.
  • If the additional payment conditions that are agreed upon for the new payment terms between the financial institution and buyer and seller respectively are not met (block 612), then payment is made according to original terms (block 613). If the additional payment conditions are met (block 612), then the negotiated terms are executed (block 614). The vendor is notified of the fund transfer and fee and is provided transfer/remittance information (block 615). Such fund transfer is at a discounted amount discounted from the original agreed upon payment between the buyer and the seller. The fee may be a discount from the full amount. Alternatively the fund transfer is a discounted amount and a separate fee is not charged. In yet another alternative, the fund transfer is the full amount minus the respective fee. Later, the buyer fund redirection is executed and the buyer settlement date is delayed as agreed between buyer and financial institution (block 616). The buyer funds are redirected to the financial institution instead of to the seller.
  • Next, receive fund notification and remittance format at seller (block 617). The fund notification indicates that the funds have been transferred to the seller. Remittance format is the format of remittance information provided by the buyer with respect to the payment. Reconciliation is then performed for the seller account receivable (A/R) system (block 618). Fund redirection instruction is received in the buyer system (block 619). The reconciliation then occurs in the buyer system (block 620). Later a rebate is executed according to one implementation (block 618). Such rebate is based on the collective savings incurred by the financial institution in receiving larger amounts of payment from buyer and making lesser amounts of payments to the respective sellers for the respective transactions taking into account the discounted value of the amounts paid later by the buyer and a profit for the financial institution. Providing, a rebate may be an optioned feature.
  • Payment of the funds will be transferred based on seller's preferences, which may preferably include single or combination of mechanism ranging from paper check to electronic clearing house centers (ACH, VISA, credit card, etc). Fund availability will notified by email to suppliers. Remittance information will be available to the seller in multiple media (paper, email, or online) as well as different A/R formats that are defined by suppliers (EDI, PeopleSoft, SAP, Oracle Financials, etc). These remittance files can be used by suppliers to reconcile with various Enterprise Resources Process (ERP) systems.
  • FIG. 7 shows a timing diagram for discounted payment according to an embodiment of the invention. FIG. 7 shows two timelines for transactions between buyer and seller. The first timeline includes seller 701 and buyer 702. The second timeline includes seller 703, financial institution 704 and buyer 705. The timeline for seller 701 includes the following seller actions: goods shipped 706 and invoice issued 707. The timeline for buyer 702 includes the following buyer actions: invoice approved 708, release for payment 709, send discounted payment and full payment due date 711.
  • The following is a description of events according to the first timeline. First goods are shipped (action 706). Alternatively, similar actions may be taken based on other actions of the seller, such as performance of a service. Other actions such as receipt of goods approval and inspection of the goods or other actions related to the goods or services may trigger events according to this scheme. An invoice is then issued by the seller (action 707). A buyer later approves the invoice (action 708). Later, the buyer releases payment (action 709). The buyer provides a discounted payment (action 710) which is less than the full payment that would otherwise be due at a later point in time. Such full payment that otherwise would be due is shown as full payment due date 711. Buyer pays full payment to financial institution as new agreed full payment due date 718.
  • The following are examples of payment in selected situations. The examples are for illustration and are not intended to limit the invention.
  • Example 1
  • PO Issued Day −6
    Invoice Submitted Day 0 
    Invoice Amount $100,000
    Supplier terms for this buyer 2% 10, Net 30
    Buyer terms for this supplier 2% 10, Net 30
    Early Pay Discount Capture Threshold Day 10
    Invoice Due Day 30
    Trigger notification: Invoice Approval Day 12
    Payment Method: ACH ACH
    Processing Method Delay  2 Days
    Funds Available In Supplier Account Day 14
    Calculation Method Simple
    Days Early Relative to Due Date 16 Days
    Effective Discount. 1.60%
    Discount Amount  $1,600
    Payment Amount  $98,400
  • In this example 1, an invoice is submitted to the buyer on day 0. The supplier's terms for payment on this invoice are 2%, 10, net 30, meaning the supplier is willing to offer the buyer a 2% discount if the buyer pays within 10 days, else pay the full amount in 30 days. In this example, the buyer's terms for this supplier match the suppliers terms. The trigger event in this example is invoice approval, whereby notification regarding the trigger event occurs on the 12th day relative to the date of invoice submission. Note this is two days past the early pay date as defined by the agreed upon terms. Because both parties have expressed a willingness to extend the discount capture opportunity throughout the due date horizon (from 10 to 30 days), we can apply a numerical method to extrapolate the early payment amount, adjusting for the actual trigger date+delays of the chosen payment method, which in this example is 2 days. Also note that in this example, simple interest is used, but other methods such as present value or time value of money formulas can be used. The actual settlement date relative to the due date is the 14th day (12 days for invoice approval+2 days for payment processing delay), or alternatively, 16 days earlier than the full term of 30 days. Discount logic using the aforementioned numerical method is applied (2% for 20 days early is equivalent in the method to 1.6% for 16 days early). Therefore, a payment is issued to the supplier in the amount of $98,400 scheduled to be available in the suppliers bank account on the 14th day relative to the invoice submission date
  • Example 2 Example 2
  • PO Issued Day −8
    Invoice Submitted Day 0 
    Invoice Amount $100,000
    Initial Supplier terms for this buyer  1.5% 10, Net 30
    Buyer terms for this supplier   2% 10, Net 30
    Adjusted Supplier terms for this buyer 1.75% 10, Net 30
    Adjusted Buyer terms for this supplier 1,75% 10, Net 30
    Early Pay Discount Capture Threshold Day 10
    Invoice Due Day 30
    Trigger notification: Invoice Approval Day 2 
    Trigger notification: Terms agreement Day 4 
    Payment Method: ACH ACH
    Processing Method Delay NA
    Days Early Relative to Due Date 26 Days
    Base Discount Rate 1.75%
    Base Number of Days Early 20
    Effective Daily Rate 0.0875% 
    Calculation or lookup method Simple
    Effective Discount Rate (Daily Rate *# of Days Early) 2.28%
    Actual Discount    $2,275.00
    Payment Amount    $97,725.00
  • In this Example 2, an invoice is submitted to the buyer on day 0. The supplier's terms for payment on this invoice are 1.5%, 10, net 30, meaning the supplier is willing to offer the buyer a 1.5% discount if they pay within 10 days, else pay the full amount in 30 days. At the time of submission, however, the buyers terms for this supplier are higher in that the buyer is “offerings” 2%10, Net 30. The trigger event in this example is invoice approval, whereby notification regarding the trigger event occurs on the 2nd day relative to the date of invoice submission. Recognizing the disparity in terms, the supplier enters a new term to “meet the buyer halfway”, at 1.75%10, net 30. The buyer responds to this “offer” or “adjustment” in the supplier's term on day 4 by adjusting his own term to meet the 1.75%10, net 30. The buyer also indicates in his discount logic preferences to use this new rate going forward for this supplier. Note a payment method delay as was presented in Example 1 may be avoided. Note that extrapolation logic can be applied for days prior to the early payment due term or “early payment threshold” depending upon the specific deployment of the invention with respect to “extrapolation” preferences resident in the discount logic. In this example, agreed upon terms are 1.75%10, Net 30, and this agreement occurs on day 4, and discount logic determines that payment should be made as early as possible, adjusting amounts for differences in relative days, in this example, payment is initiated on day 4, or 26 days early from the scheduled due date. If the parties agree to a rate of 1.75% in exchange for payment 20 days early (30 days less 10 days), then mathematically we can extrapolate using simple interest or other numerical method such as net present value to determine the effective discount rate and discount amount, in Example 2, this adjusted discount rate is 2.28% to reflect the payment of the invoice faster than the defined early threshold.
  • Example 3 Example 3
  • PO Issued Day −4
    Invoice Submitted Day 0 
    Invoice Amount 100,000
    Supplier terms for this buyer 14% APR, Net 30
    Buyer terms for this supplier 14% APR, Net 30
    Invoice Due Day 30
    Trigger notification: Invoice Approval 14
    Payment Method: ACH ACH
    Processing Method Delay  2
    Days Early Relative to Due Date 14 Days
    Effective Daily Rate 0.0384% 
    Calculation or lookup method net present value
    Net present value discount factor 0.54%
    Actual Discount    $534.12
    Payment Amount    $99,465.88
  • In this Example 3, discount terms are represented as an annualized rate of return, or interest rate, or, as businesses commonly refer to them, internal hurdle rates. In conjunction with this interest rate is the net due date of the invoice. Using these two numerical data points the system can extrapolate the appropriate discount depending upon the timing of a valid trigger event relative to the invoice due date. As with the other methods, we can use a variety of calculation methods, like simple interest or net present value. Example 3 utilizes Net Present Value in the calculation. Example 3 illustrates that both buyer and supplier have agreed upon the same set of terms, which is a 14% annual percentage rate and a invoice due date at day 30. In this example, the invoice is approved on day 14, or 16 days before the actual due date. Note, however, that Example 3 employs the use of the payment method factor, which is 2 days, effectively adjusting the early pay date to 16 days after submission of the invoice, and 14 days before it is due. This 14 days becomes the basis of our discount calculation. Using the APR of 14%, we can generate an effective daily rate of 0.0384% (14/365). Applying this rate over a 14 day period translates to 0.537% (14*0.00384). The net present value of the calculation, given a future value of $100,000 on day 30, using 0.537% as the rate of discount over 1 period yields a present value of $99,465.88, or a discount amount of $534.12
  • Example 4 Example 4
  • PO Issued Day −4
    Invoice Submitted Day 0 
    Invoice Amount $100,000
    Supplier invoice due term 30 days
    Buyer invoice due term 30 days
    Supplier discount terms, day 1 through 10   2%
    Supplier discount terms, day 11 through 15 1.50%
    Supplier discount terms, day 16 through 22   1%
    Buyer discount terms, day 5 through 10 2.50%
    Buyer discount terms, day 11 through 15 1.50%
    Buyer discount terms, day 16 through 22 1.25%
    Trigger notification: Invoice Approval 5
    Payment Method: ACH ACH
    Processing Method Delay 2
    Discount Applied (based on lookup value) 1.50%
    Scheduled settlement date Day 15
    Actual Discount    $1,500.00
    Payment Amount    $98,500.00
  • In this embodiment of the invention, utilization of a discrete value lookup is used in place of the continuous range calculation offered by the methods described above. In example 3, both the buyer and supplier ha re entered into the discount logic engine a series of terms to be referenced depending upon when the trigger event takes place. As the table illustrates, the supplier has entered a discount amount that should be applied if an invoice is approved between 1 and 10 days, a different rate between 11 and 15 days. etc. The buyers defines a rate for days 5-10, 11 to 16 etc. In example 4, the invoice was approved on day 5, with an :NCH processing delay of 2 days, resulting in the early pay date at day 7. Because 7 falls in the supplier's range of 1-10 days, and the buyers range of 5-10 days, those respective discount rates are referenced and checked for agreement. In this instance, they do not agree, upon which the discount logic references the next available opportunity in the list, which in these case is day 11-15 for both buyer and supplier. Note from the table that there is agreement in discount amount for this range of days. Therefore, the payment will be scheduled to settle on or before the 15th day and after the 11th day for a 1.5% discount.
  • The second timeline shows interaction between the parties including a financial institution 704. Goods are shipped from the seller 709 to buyer 705 (action 712). Next, an invoice is issued by the seller (action 713). Invoice is approved by buyer 705 in event invoice approved (action 714). The invoice approval notice event is provided to financial institution 704 as well as seller 709 so that financial institution can base payment to seller on the approval of the invoice. Next, payment is released (action 715). A notification of such release is provided to seller 709 as well as financial institution 704. Such notice is provided to financial institution 704 so that financial institutional may optionally trigger payment to the seller based on the release of payment by the buyer. A discounted payment is made from financial institution 704 to seller 709 (action 716). Later, a full payment is made between buyer 705 and financial institution 704 (action 718). Such payment may, in an alternative embodiment of the invention, equal the payment less than the full amount but larger than the amount made by the financial institution to the seller. Such payment may also be made at a time (action 718) that is later than the original payment due date (action 717).
  • Example 5 Example 5
  • Buyer 1 Buyer 2
    PO Issued Day −4 Day −5
    Invoice Submitted Day 0  Day 0 
    Invoice Amount $100,000 $200,000
    Supplier Terms 2% 10, Net 30 2% 10, Net 30
    Buyer Program 60 Day Payable, 50 Day Payable,
    No rebate 10% of Discount
    Trigger notification: Invoice 5 5
    Approval
    Payment Method: ACH ACH ACH
    Processing Method Delay 2 2
    Days Early Relative to Due Date 23 Days 23 Days
    Effective Daily Rate 0.1000% 0.1000%
    Calculation or lookup method Simple Simple
    Effective Discount Rate  2.30%  2.30%
    Actual Discount    $2,300.00    $4,600.00
    Payment Amount    $97,700.00   $195,400.00
    Net Result: Bank pays this   $293,100.00
    supplier:
    Bank Reimbursement $100,000 $200,000
    Bank Rebate to Buyer (for None    $460.00
    simplicity,
    bank cost of capital is ignored
    because this is a % of Discount
    Program and not a % of Profit
    program)
  • In example 5, a bank is paying the supplier on behalf of two buyers who have received and processed invoices from this supplier. The table shows the trigger events within the buying organizations occurred on day 5 relative to the due date. Adjusting for payment method delay places the early pay opportunity at 23 days. With an effective daily discount rate of 0.1% (2% for 20 days early=0.1% per day), the effective discount rate applied to each invoice is 2.3%. For buyer 1, this translates to a discount of $2,300, and $4,600 for buyer 2. Subtracting the discount amounts from the original invoice amount yields net payments of $97,700 and $195,400 for buyer one and two, respectively. Also note, because the financial institution is making payment to a single supplier in this example, the payments can be consolidated into one or initiated separately depending upon the financial institutions preferences. The financial institution receives $100,000 from buyer I on day 60, and $200,000 from buyer 2 on day 50 in addition, note that buyer 1 is not subject to receiving a rebate from the financial institution. Buyer 2 in this instance will receive a rebate in the amount of $460, or 10% of the discount capture rate. Note, the bank can apply different methods to the calculation such as adjusting the $460 down based on cost of capital and duration the credit is outstanding, which in this case could be 20 days (50 days−30 days (original due date of invoice). Also note that the numerical or lookup methods discussed in Examples 1-4 can also apply to the banking oriented embodiment of the system.
  • FIG. 8 shows a user interface for a banking system according to an embodiment of the invention. The bank interface includes top level navigation inputs 801 and low level navigation/views, filters or functions 802. The major actions that the bank is able to take according to this interface include those associated with task list 803, buyers 804, suppliers 805, activity $06 and credit analysis 807.
  • The following are the actions available in the different respective categories. Under task list 803 is available supplier targets 808 Under buyers 804 is available incentive programs 809, buyer debit $17, credit limit 821, contact information 824 and credit program 825. Within incentive programs is available rebate method, which includes flat versus percentage of profit options 813 and payable date 815. Rebate method 813 includes value 814. Payable date includes days from invoice date 816. Buyer debit 817 includes payment method 818, credit limit 821, contact information 824 and credit program 825, Payment method 818 includes direct debit account number 819 and buyer initiated 820. Credit limit 821 includes value 823. Credit program 825 includes value or custom 826.
  • The following actions are included under suppliers 805 discount program 810, supplier directory 830 and participation statistics 832. Under discount program 810 is included rate 827, term/due 828 and fixed/interpolated 829. Under supplier directory 830 is included discount program 831. Under category activity 806 is included current 811, paid 833 and closed 834. Under closed 834 is included approved date 835, buyer 836, invoice number 837, supplier 838, original amount 839, payable amount 840 and payable date 841.
  • Under category credit analysis 807 is included credit limit summary by buyer 812, dollars proved 842 discounts captured 843 and net benefit 844. Under net benefit is included trend analysis 845, cumulative summary 846 and receivables 847. Under receivables is included summary 848 and by buyer 851. Under summary 848 is included amount 849 and age 850. Under buyer 851 is included amount 852 and age 853.
  • Bank interface includes various options that allow the bank to manage and analyze its program of making payments for sellers and receiving payments from buyers. For example buyers 804 allows for the bank to analyze the various programs that are set up for respective buyers. The programs shown may be available in various combinations in various embodiments of the invention. Similarly, category suppliers 805 allows for the bank to analyze its programs offered for various suppliers. Such analysis may be provided for each respective supplier and also for the programs that are available in general to the bank with respect to suppliers. As with the other categories, various combinations or sub combinations of the features shown, including with additional elements, may be provided in different implementations. Category activity 806 allows for the bank to analyze various pending activities with respect to the discount programs offered and managed by the bank. Credit analysis category 807 allows for the bank to conduct various forms of analysis on these programs. The analysis may take the form of the types shown or other combinations, sub combinations or super combinations of these elements.
  • FIG. 9 shows a user interface for a payer system according to an embodiment of the invention. Payer administration interface includes top level navigation actions 901 and low level navigation/views, filters, or functions 902. Top level navigation 901 includes the following categories: task lists 903, supplier 905, activity 906 and credit analysis 907. Task list 903 includes supplier targets 904.
  • Suppliers 905 includes same as current GSD 908. Same as current GSD 908 includes new flag for payables financing 909 and filter and view 910. Category activity 906 includes current 911, paid 912 and closed 913. Closed 913 includes approve date 914, buyer 913, invoice number 916, supplier 917, original amount 918, payable amount 919 and payable date 920.
  • Category credit analysis 907 includes credit limit summary by buyer 921, dollars moved 922, discounts captured 923 and net benefit 924. Category net benefit 924 includes trend analysis 925, cumulative analysis 926 and receivables analysis 927. Receivables analysis includes summary 92$ and by buyer 931 Summary 928 includes amount 929 and 930. By buyer 931 includes amount 932 and age 933.
  • Payer administration may be used by a buyer to display potential candidates suppliers with whom a program of discounts may be engaged. The various actions shown allow for the buyer to filter among the set of suppliers that the buyer works with to find potential suppliers for whom various levels of savings may be achieved through earlier payment and reciprocal discounts. For example filter and view 910 allows for identification of suppliers selected by various filters. Such filters may be based on the potential savings for the respective suppliers. Activity 906 allows for analysis of current payment activity. Credit analysis 907 allows for analysis of the use of discounts to achieve savings. Such savings may be displayed in various forms as shown.
  • This interface shows current on-going activity and balance with regarding to buyer and suppliers. There complete sections: current, close, and paid. The current section displays invoices that match defined criteria awaiting approval to be executed. The paid section displays invoices that currently has been paid to suppliers and awaiting buyer re-embursements. The close section displays all completed transactions.
  • FIG. 10 is a block diagram of a system according to an embodiment of the invention. The system allows a paying entity to define the invoice format for invoices it wishes to receive. The system facilitates routing, editing, dispute resolution, and disbursement of payment. The system includes payer (buyer) shown as 1001, payee (vendor) shown as 1002, and financial institutions shown as 1050. The system has the following characteristics according to one implementation: collaborative network model, A/P (buyer) centric enterprise software, plugging into existing ERP systems, full cycle bill-to-pay functionality, web-based A/R (vendor) software, and co-existence with the customer existing bank relationships.
  • The collaborative network model supported by the unique collaborative vendor reconciliation engine between global directory shown as 1028 and A/P centric master vendor list shown as 1027. The reconciliation engine provides methods of matching existing vendor name/address with self enrolled vendor information in the global directory. These methods include: fuzzy attributed weight based matching shown as 1030, previous vendor histories of matching in the knowledge based shown as 1031, third party outsourced recommended matching proposal shown as 1032, and manual interactive selection from buyers shown as 1033. Each vendor is represented by several critical attributes in the global directory: addresses shown as 1038, real and alias accounts shown as 1039, and keys shown as 1040. Vendor entries are pre-populated with information uploaded from the buyer ERP system. The vendor enrolls via the online self-service enrollments 1035. Vendor also provides additional rules to match 1034, A/R remittance format attributes 1036, and notification rules/addresses 1037.
  • Accounts payable (A/P) buyer-centric enterprise software associated with payer system 1001 includes several key unique functions. These functions include buyer defined electronic invoice exchange, routing/editing and approval, and dispute resolution. Payer system 1001 includes invoice definition engine 1003, invoice 1004, HR organization data 1008, routing/editing logic 1005, dispute logic 1009, notifications logic 1012, disbursement logic 1013, dynamic terms logics/offers 1060, discount logic 1016 and settlement logic 1017. Also included on payer system 1001 are input output (I/O) 1010, processor 1011, entity key 1015, and payer central repository database 1027. The invoice definition engine 1003 includes validation logic 1053, tolerance/replacement items 1055, interaction severity 1054, and several presentation forms 1056. This definition engine is controlled by payer helps provide clean invoice data from payees. The definition logics (1053, 1054, 1055, and 1056) can be configured to specific payee or a specific group of payees.
  • Invoice definition engine 1003 and its definition logics are exposed to payee via global directory and are operative with invoice definition generation/validation 1018 of payee system 1002. The routing/editing logic 1005 includes business logic that governs how an invoice will be processed by AP clerks, and what data entry information will be required to complete the transaction. Routing/editing logic 1005 can operate differently based on multiple attributes: document type, document value, discount value, etc. Routing/editing logic 1005 acts on HR organization database 1008 to define routing/editing/approval work flow based on employee information 1007 and role values 1006. Invoice 1004 is coupled into routing logic 1005/Routing logic 1005 is coupled with employee logic 1007 and role assignment 1006. Routing logic 1005 is coupled with HR data 1008 and with dispute logic 1009, notifications logic 1012 and disbursement logic 1013 of payer system 1001. Notification logic 1012 is configured by the payer, and includes collaborative filtering, and mappings status and notification definitions between internal o external payees. These collaborative filtering and mappings can be designated to a payee or a group of payees.
  • Dispute logic 1009 is set of payer defined centric collaboration rules and interactions between payer and payee to resolve issues related to invoice or other exchanged documents. Some disputes are simple (e.g., number of items is received, etc.) while others are more complex (e.g., replacement items do not meet part specification and price). The outcomes of a dispute are partial payments, partial invoices, new invoices, or other outcomes. According to one implementation, a dispute can only he finalized by payer and its members, and some finalized exchanges will require digital signature to ensure non-repudiation. The payer dispute logic 1009 orchestrates with payee dispute logic 1022. Payer dispute logic, references, and history are stored in payer central repository 1027.
  • A/R web based centric software associated with payee system 702 helps provide an online self-service payee system. Payee system 702 includes a processor 1052 and input/output (I/O) 1051. Such processor 1052 and input/output 1051 allow for communication with other entities such as payer system 1001, financial institutions 1050 and global database 1028. Processor 1052 and processor 1011 of payee 1002 and payer 1001 respectively may run various software processes to implement the logic shown. The processes may be implemented as software objects, routines or other software processes, programs or implementations. Alternatively, portions of such logic may be implemented in hardware logic or other forms of logic. The functions shown may alternatively be implemented on a common server or in a distributed set of computer systems separated over a computer network, or other configuration that achieves the logical functions shown. Data and information such as for global database 1028 may be stored in data structures or other data format and stored in computer memory, fixed storage or other data storage or archived in various implementations of the invention.
  • Payee system 1002 includes invoice generation/validation logic 1018, invoice send logic 1021, dispute logic 1022, notifications logic 1023, receipt/validation logic 1024, discount logic 1025 and settlement logic 1026. Invoices or other documents can be submitted to payer via multiple mechanism. Three sample mechanisms are shown here: Web forms shown 1057, purchase order pre-populated invoice (PO flip) 1058, and electronic file submission via file mapping 1019. The Web forms 1057 are a set of payer defined presentations that can be selected and/or authorized to be used by payee(s). Payee can also define additional payee private attributes and fields to be used during A/R matching as well as graphic materials (such as company logo, etc,). The PO flip 1058 uses information from purchase orders which are transmitted to payee from payer to pre-populate the invoice data. The status of each purchase order is maintained within the payee central repository to support blanket purchase orders. File mapping 1019 is used by the payee to automate the bulk invoice submission process. Normally, these file are exported from payee's A/R system. The mapping defines bow payee's data will be mapped into payer, as well as default/validation/transformation rules. Upon submission of these invoices or other documents via multiple mechanisms (1057, 1058, 1019). The documents are validated based on the payer definition engine 1018. This definition engine 1018 includes payer definition engine 1003 and its components: validation 1053, severity 1054, tolerance 1055 and presentation 1056.
  • Invoice generation/validation logic 1018 is coupled with mapping logic 1019 in communication with the data 1020. Invoice generation/validation logic 1018 is coupled into invoice send logic 1021. Dispute logic 1022 is coupled with dispute logic 1009 of payer system 1001. Notifications logic 1023 is in communication with notifications logic 1012 of payer system 1001 and discount logic 1025 of payee system 1002. Receipt/validation 1024 of payee system 1002 is in communication with disbursement module 1013 of payer system 1001. Settlement logic 1026 is operative with discount logic 1025 of payee system 1002 and receipt/validation logic 1024.
  • Global database 1028 is available to notifications logic 1012 and 1023, disbursement logic 1013, settlement logic 1017 and 1026, invoice send logic 1021, receipt 1021 and receipt/validation logic 1024. Global database 1028 is in communication with payer database 1027 through attribute match rules 1030, knowledge based history matching samples 1031, third party recommendation/proposal 1032 and manual interactive matching by payers 1033. Global database 1028 is in communication with payee database 1029 through match rules 1034, enrollment logic 1035, remittance formats 1036 and notification preferences 1037. Global database includes items such as address 1038, accounts 1039 and public keys 1040. Payer database 1027 is located with payer system 1001 and payee database 1029 is located with payee system 1002. Global database 1028 is also available to financial institutions 1050.
  • Through invoice definition engine 1003 a payer uses payer system 1001 to define the invoice that the payer wishes to receive. Such definition helps to increase efficiency in the payer system because the resulting invoice from the payee, such as a seller, is more likely then in the proper data format when it is received. Payee system 1002 generates an invoice based on the defined invoice in invoice generation/validation logic 1018. The input data for the invoice is validated based on the invoice definition rules defined in payer system 1001. If file data is used to automatically map into an invoice, such mapping is performed in one embodiment of the invention by mapping logic 1019. Mapping logic 1019 receives the file data 1020 with information to be populated into respective invoices. File data 1020 may contain files with data for invoices for various payers who have purchased good or services from the payee. When an invoice is completed it is sent through invoice send logic 1021 to payer system 1001. Additional information regarding definition of invoice by the buyer and use of related invoice rules is contained in United States patent application entitled System and Method for Electronic Payer (Buyer) Defined Invoice Exchange, U.S. patent application Ser. No. 10/155,840, invented by Duc Lam, Ramnath Shanbhogue, Immanuel Kan, Bob Moore and Xuan (Sunny) McRae, which is incorporated herein by reference in its entirety.
  • An invoice is received at payer system 1001 as shown here with invoice 1004. The invoice is routed to the respective employees or other agents for its review and approval. Some approval may require additional signatures according to one embodiment of the invention. As shown here, employee logic 1007 is in communication with routing logic 1005 to allow an employee to authorize, audit or view respective invoice car check information.
  • Routing logic 1005 is also used to route checks or other documents to various employees for signature or approval using HR data 1008. Routing logic 1005 uses HR data 1008 to determine the correct employees to whom to route the respective document, such as in an invoice or check. Routing may be made to the manager of a respective employee if the employee has not responded in a certain time to the document. Such the choice of such manager to whom to route is made based on the management hierarchy in the organization stored in HR database 1008. Such database is extracted from a human resource management system (HRMS), in one implementation of the invention. Additional information regarding routing of documents in the system is described in United States patent application entitled Method and System for Invoice Routing and Approval in Electronic Payment System, U.S. patent application Ser. No. 10/155,853, invented by Bob Moore and Xuan (Sunny) McRae, which is incorporated herein h reference in its entirety.
  • A user of payer system 1001 may dispute an invoice or other payment request through dispute logic 1009. Dispute logic 1009 is in communication with dispute logic 1022 of payee system 1002. This allows for communication regarding a dispute between a payer and a payee. The dispute may be only initiated and finalized by a payer. According to one embodiment of the invention, the dispute may be finalized only by the buyer, or the payer system. The dispute includes the capability to indicate that particular items in an invoice are disputed, such as the tax. The dispute logic 1009 and 1022 include the capability for individuals using the payer system 1001 using payee system 1002 to engage in a chat dialog. For additional discussion regarding electronic dispute resolution in such a system, refer to United States patent application entitled Method and System for Buyer-Centric Dispute Resolution in Electronic Payment System, U.S. patent application Ser. No. 10/155,866, invented by Duc Lam, Celeste Wyman and Xuan (Sunny) McRae, which is incorporated herein by reference in its entirety.
  • Notifications logic 1012 communicates completion of various stages of approval or other issues of status regarding invoices and disbursement. For example, when an invoice is approved notifications logic 1012 communicates a notification to notifications logic 1023 of payee system 1002. Based on such notifications, a discount may be enabled through discount logic 1016, which is in communication with discount logic 1025 of payee system 1002. For example, where an invoice is approved, a discount may be enabled based on an agreement or outstanding dynamic terms offers shown as 1060 that the corresponding payment is made earlier than required under the original terms and conditions. Dynamic terms are additional real-time terms, a set of rules, and/or goal seeker that are established by payer 1060 or payee 1061. These dynamic terms rules 1060 and 1061 are based on business event types (invoice approval, purchase order approval, etc.}, a payee or group of payee and a set of new discrete or variable terms. These dynamic term goal seekers allow payer and payee to set desirable outcomes. These dynamic terms can be pre-negotiated up-front or in real-time based on business event types. The approval of these new terms may require digital signature of either payer or payee. Also, third party financial institutions could be involved to provide funding for payee in returns for early discounts.
  • To facilitate complete bill-to-payment functionality, the system in FIG. 10 includes disbursement logic 1012 and settlement logic 1017. Disbursement logic 1013 includes all payment routing, signing, and approval logic for respective invoices or other requirements for payment. Some payments will require multiple signatures to be signed based on payment amount and/or destination payee(s). Digital signatures and nondigital signatures may both be used. Also, payer can configure to control new settlement date for the payment by defined payee group and number of business/calendar days to be adjusted. The disbursement logic also includes auditing capability with multiple levels based on number of signatures and/or amount in one implementation, disbursement logic 1013 makes such disbursement in the form of electronic checks in one implementation. Such electronic checks are generated and signed with a digital signature. The digital signature may be obtained from respective users such as through a routing process using routing logic 1005 to obtain a signature from employee logic 1007 with role assignment digital key 1006.
  • Alternatively, a set of instructions may be received to send a set of checks that use a digital signature of the payer organization rather than the digital signature of an employee. Such check processing may be accomplished through batch processing logic 1014 and disbursement logic 1013. Such batch processing logic 1014 uses an entity key 1015, which is a private key of the payer's organization. Batch processing logic 1014 requires particular authorization for the respective instruction. The authorization may require that the agent requesting the set of checks sign the instruction with the agent's private key. Receipt/validation logic of payee system 1002 is in communication with disbursement logic 1013. Receipt/validation logic 1024 receives payment, such as in the form of electronic checks. Such electronic checks are validated to assure that they are accurate, Receipt/validation logic decrypts any encrypted documents, for example if the electronic checks are encrypted with the public key of payee system 1002, such checks are decrypted. Additionally, the digital signature of the sender is authenticated in receipt/validation logic 1024. Such authentication is accomplished using the public key of the payer, which corresponds to the private key of the payer's organization (entity key 1015) that was used in batch processing logic 1014 (entity key 1015). Additionally, verification may be made against a payment database generated by the payer system when the checks are created in order to assure that the checks were actually sent by the payer system. Additional information regarding disbursement 1013 and batch processing 1014 is contained in United States patent application entitled System and Method for Electronic Authorization of Batch Checks, U.S. patent application Ser. No. 10/155,800, invented by Duc Lam, Matthew Roland and Xuan (Sunny) McRae, which is incorporated herein by reference in its entirety.
  • Settlement logic 1017 allows for settlement of payment between a payer system 1001 and payee system 1002. Settlement mechanism includes exiting combination of paper based checks, standard domestic electronic payment network (Fed Wire, ACH, CHIPS, etc), international electronic payment networks (SWIFT, Bolera, etc.), propriety private payment networks (VISA, MasterCard, and American Express, etc.), and internal account bank transfer (On-us, etc.) For example, settlement may be made through debits and credits in a database within the system. Alternatively, settlement may be performed through an external network such as the ACH network with financial institutions involved, such as financial institutions 1050.
  • Settlement logic 1017 supports standard fund transfer model (buyer's account will be debited and supplier's account will be credited) and good funds model (buyer's account will be debited and a temporary account will be credited. Upon receiving fund availability in temporary account, the supplier will be credited). Settlement logic 1017 is implemented via issuing requests to the settlement network. Such request can be tile-based requests such as ACH or transactional request such as VISA networks. For each request, there will be associated confirmation ID to ensure the trace ability of each transaction.
  • Global database 1028 is available for use by elements that send payment, such as disbursement logic 1013 and settlement logic 1017. Global database 1028 is also available for elements that send other documents or information between payees and their respective financial institutions. For example, invoices may be sent based on the respective recipient address as stored in the global database 1028. Thus, invoice sends logic 1021 is in communication with global database 1028.
  • Global database 1028 includes addresses and account information for respective payers and payees who use the system. Links are created between items in the global database and other databases in order to allow for the global database to be updated and the corresponding linked information to continue to be used. Thus, for example, according to one embodiment of the invention, a payer has a separate database, payer databases 1027, and matches are created between items, such as addresses or payment entities and payer 1027 and respective items in global database 1028 through a match generation process 1030. Such matched generation process 1030 may include providing a user of the payer system 1001 with a series of candidate matches between addresses stored on payer database 1027 and corresponding spellings of addresses or payment entities in global database 1028. The user of payer system 1001 is then able to select the best match and create a link between the respective address or payment identification.
  • This link can then later be used to effect payment to the proper address as stored in the global database. Similarly, a match generation between items in payee database 1029 and global database 1028 can be performed so that payee system 1002 can send items to the proper recipient using information in global database 1028. Enrollment logic 1035 is available to enroll new entities as payees into the global database to make them available for use by payer system 1001 or payee system 1002.
  • The links established are then available to allow for use of information in the respective payer database 1027 and payee database 1029 in order to find recipients to whom documents or payments are to be sent. In addition to address information 1038 and account information 1039, according to one embodiment. of the invention, public keys of various participants in the systems are stored in the global database 1028. Such keys are then available for use in order to determine the accuracy of a digital signature sent h a particular entity. Additional information regarding global database 1028 and related logic and communication is contained in the United States patent application entitled Method and System for Collaborative Vendor Reconciliation, U.S. patent application Ser. No. 10/155,797, invented by Duc Lam, Georg Muller, Chandra (CP) Agrawal, Baby Lingampalli, Pavel Lopin and Xuan (Sunny) McRae, which is incorporated herein by reference in its entirety.
  • In the FIG. 10 system, invoices and other documents are exchanged between payers and payees over the public and internet networks 1080. To help provide security and privacy, before they are sent, invoices and or documents are signed with source private key, and encrypted with destination public key shown as 1081. Upon receiving invoice or other document, the document is decrypted with its own private key, and validated against source public key to ensure non-repudiation shown as 1082.
  • The system also can integrate with multiple enterprise resource planning (ERP) systems shown as 1062. Such ERP systems include: PeopleSoft, SAP, Oracle Financials, etc. The system will integrate with these ERP systems via native and/or standard interfaces. An example of native interface for PeopleSoft is Message Agent, etc. The interfaces include EDI gateway, etc. The system utilizes the ERP to extract documents (purchase orders, invoice status, unit of measurements, vendor list, etc.), to post documents (invoices, vendor information, status, etc.).
  • The foregoing description of various embodiments of the invention has been presented for purposes of illustration and description. It is not intended to limit the invention to the precise forms described.

Claims (5)

What is claimed is:
1. A system for providing supply chain financing, comprising:
a communications network;
one or more computers, each comprising at least a computer processor, communicatively coupled to the communications network, configured to:
negotiate one or more payment terms between a buyer, a seller, and a financial institution, such that the negotiated payment terms comprise a discount proposal option to present to at least one of the seller or the buyer from the financial institution, the discount proposal option comprising a discount payment amount in exchange for payment in response to a trigger event;
receive at least one invoice from the seller,
validate the at least one invoice based on predetermined rules;
receive a buyer's payment in accordance with the payment terms, wherein the buyer's payment is received by the financial institution; and
arrange a seller's payment in accordance with the payment terms based on the trigger event, wherein the seller's payment is made by the financial institution.
2. The system of claim 1 wherein negotiate further comprises making modifications to the terms of the discount proposal and receiving one or more counter-discount proposals.
3. The system of claim 1 wherein the at least one discount proposal comprises different schemes for arranging early or immediate payment.
4. The system of claim 1 further wherein the payment is made at a discounted amount to account for a time value of money in having the payment made at an earlier timer.
5. The system of claim 1 in which the one or more computers are further configured to provide requests for offers of new sets of terms to the seller.
US13/893,769 2002-05-24 2013-05-14 System and Method for Varying Electronic Settlements Between Buyers and Suppliers with Dynamic Discount Terms Abandoned US20130268339A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/893,769 US20130268339A1 (en) 2002-05-24 2013-05-14 System and Method for Varying Electronic Settlements Between Buyers and Suppliers with Dynamic Discount Terms

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US10/155,806 US20030220863A1 (en) 2002-05-24 2002-05-24 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US12/754,575 US8108296B2 (en) 2002-05-24 2010-04-05 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US13/162,185 US8244625B2 (en) 2002-05-24 2011-06-16 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US13/543,248 US8484129B2 (en) 2002-05-24 2012-07-06 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US13/893,769 US20130268339A1 (en) 2002-05-24 2013-05-14 System and Method for Varying Electronic Settlements Between Buyers and Suppliers with Dynamic Discount Terms

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US13/543,248 Division US8484129B2 (en) 2002-05-24 2012-07-06 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms

Publications (1)

Publication Number Publication Date
US20130268339A1 true US20130268339A1 (en) 2013-10-10

Family

ID=29549171

Family Applications (5)

Application Number Title Priority Date Filing Date
US10/155,806 Abandoned US20030220863A1 (en) 2002-05-24 2002-05-24 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US12/754,575 Expired - Fee Related US8108296B2 (en) 2002-05-24 2010-04-05 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US13/162,185 Expired - Lifetime US8244625B2 (en) 2002-05-24 2011-06-16 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US13/543,248 Expired - Lifetime US8484129B2 (en) 2002-05-24 2012-07-06 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US13/893,769 Abandoned US20130268339A1 (en) 2002-05-24 2013-05-14 System and Method for Varying Electronic Settlements Between Buyers and Suppliers with Dynamic Discount Terms

Family Applications Before (4)

Application Number Title Priority Date Filing Date
US10/155,806 Abandoned US20030220863A1 (en) 2002-05-24 2002-05-24 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US12/754,575 Expired - Fee Related US8108296B2 (en) 2002-05-24 2010-04-05 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US13/162,185 Expired - Lifetime US8244625B2 (en) 2002-05-24 2011-06-16 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US13/543,248 Expired - Lifetime US8484129B2 (en) 2002-05-24 2012-07-06 System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms

Country Status (6)

Country Link
US (5) US20030220863A1 (en)
EP (1) EP1514210A4 (en)
JP (1) JP2005527046A (en)
AU (1) AU2003243251B2 (en)
CA (1) CA2483348C (en)
WO (1) WO2003100689A1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190108560A1 (en) * 2016-04-15 2019-04-11 Eckehard Stolz Method for automatically financing bills
CN109615511A (en) * 2019-01-07 2019-04-12 北京锐融天下科技股份有限公司 A kind of supply chain banking software system and method
WO2019202367A1 (en) * 2018-04-18 2019-10-24 Cashworks Operations Ag Method and system for facilitating a decision about a money transaction

Families Citing this family (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080172314A1 (en) 1996-11-12 2008-07-17 Hahn-Carlson Dean W Financial institution-based transaction processing system and approach
US8392285B2 (en) 1996-11-12 2013-03-05 Syncada Llc Multi-supplier transaction and payment programmed processing approach with at least one supplier
US20070055582A1 (en) 1996-11-12 2007-03-08 Hahn-Carlson Dean W Transaction processing with core and distributor processor implementations
US8396811B1 (en) 1999-02-26 2013-03-12 Syncada Llc Validation approach for auditing a vendor-based transaction
CN1439142A (en) 1998-12-23 2003-08-27 大通银行 System and method for integrating trading operations including the generation, processing and tracking of and trade documents
US7617146B2 (en) * 2000-09-05 2009-11-10 Primerevenue, Inc. Factoring system and method
US7822679B1 (en) * 2001-10-29 2010-10-26 Visa U.S.A. Inc. Method and system for conducting a commercial transaction between a buyer and a seller
US20030220863A1 (en) 2002-05-24 2003-11-27 Don Holm System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
JP2005530234A (en) * 2002-06-18 2005-10-06 マスターカード インターナシヨナル インコーポレーテツド Integrated electronic invoice issuance and payment system and method
US20040073510A1 (en) * 2002-06-27 2004-04-15 Logan Thomas D. Automated method and exchange for facilitating settlement of transactions
AU2003297296A1 (en) * 2002-12-30 2004-07-29 Fannie Mae System and method for creating and tracking agreements for selling loans to a secondary market purchaser
US7765155B2 (en) * 2003-03-13 2010-07-27 International Business Machines Corporation Invoice processing approval and storage system method and apparatus
EP1627288A2 (en) * 2003-05-06 2006-02-22 Bridge Associates, LLC Method and system for performing preference analysis
TW200504551A (en) * 2003-07-28 2005-02-01 yu-qian Xing Joint web shopping model using approval mechanism
US20050075912A1 (en) * 2003-10-06 2005-04-07 Bealke Bruce B. Computerized settlement method
US20050125346A1 (en) * 2003-12-04 2005-06-09 Winiecki Kurt A. Method and system for calculating and presenting bankruptcy preference payment defenses
US7756778B1 (en) 2003-12-18 2010-07-13 Fannie Mae System and method for tracking and facilitating analysis of variance and recourse transactions
US8762238B2 (en) 2004-06-09 2014-06-24 Syncada Llc Recurring transaction processing system and approach
AU2005255456B2 (en) 2004-06-09 2007-09-13 Syncada Llc Order-resource fulfillment and management system and approach
WO2005124639A2 (en) 2004-06-09 2005-12-29 U.S. Bancorp Licensing, Inc. Distributor-based transaction processing arrangement and approach
US8554673B2 (en) * 2004-06-17 2013-10-08 Jpmorgan Chase Bank, N.A. Methods and systems for discounts management
US8682757B2 (en) * 2004-08-25 2014-03-25 American Express Travel Related Services Company, Inc. Method and apparatus for processing financial transactions subject to different financing terms
WO2006026418A2 (en) * 2004-08-25 2006-03-09 Mastercard International Incorporated Method and system for automated payment authorization and settlement
AU2012200011B2 (en) * 2004-08-25 2015-05-21 Mastercard International Incorporated Method and system for automated payment authorization and settlement
US7848978B2 (en) * 2004-10-19 2010-12-07 Apollo Enterprise Solutions, Inc. Enhanced transaction resolution techniques
US7433838B2 (en) * 2004-11-19 2008-10-07 Microsoft Corporation Realizing legally binding business contracts through service management models
US7958360B2 (en) * 2005-05-12 2011-06-07 Microsoft Corporation Method and system for performing an electronic signature approval process
US7822682B2 (en) 2005-06-08 2010-10-26 Jpmorgan Chase Bank, N.A. System and method for enhancing supply chain transactions
JP4217700B2 (en) * 2005-07-22 2009-02-04 三井倉庫株式会社 Transaction management server control method, transaction management server, and program
US8676702B1 (en) * 2005-08-02 2014-03-18 At&T Intellectual Property Ii, L.P. Method and apparatus for generating a bill in a packet network
US20070156584A1 (en) * 2005-11-22 2007-07-05 Primerevenue, Inc. Supply Chain Financing Systems and Methods
US20070282744A1 (en) * 2005-11-22 2007-12-06 Primerevenue, Inc. Supply chain financing and credit memo systems and methods
US20070282724A1 (en) * 2006-02-21 2007-12-06 Primerevenue, Inc. Asset based lending (abl) systems and methods
US7698164B2 (en) * 2006-03-10 2010-04-13 Reagan Inventions, Llc Method and system for providing a payment incentive for distributing digital files over a network
US20080021885A1 (en) * 2006-07-24 2008-01-24 Chacha Search, Inc. System for substantially immediate payment for search related tasks
US8712884B2 (en) 2006-10-06 2014-04-29 Syncada Llc Transaction finance processing system and approach
US20080177659A1 (en) * 2007-01-19 2008-07-24 Timothy Douglas Lacey Systems and methods for providing financial processing in conjunction with instant messaging and other communications
JP5554890B2 (en) * 2007-07-20 2014-07-23 楽天株式会社 Virtual shopping street management system
US8229807B2 (en) * 2007-08-12 2012-07-24 Elbizri Samer System and method of offsetting invoice obligations
US20090055281A1 (en) * 2007-08-20 2009-02-26 Usa Technologies, Inc. Processing systems and methods for vending transactions
US8622308B1 (en) 2007-12-31 2014-01-07 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
US8751337B2 (en) 2008-01-25 2014-06-10 Syncada Llc Inventory-based payment processing system and approach
US8478637B1 (en) * 2008-04-08 2013-07-02 Jpmorgan Chase Bank, N.A. Index for assessing discount potential
US20110106677A1 (en) * 2008-08-08 2011-05-05 Elbizri Samer System and method of offsetting invoice obligations
US8401928B2 (en) * 2008-09-18 2013-03-19 Sap Ag Providing supplier relationship management software application as enterprise services
US10817932B2 (en) 2008-10-31 2020-10-27 Pollen, Llc Dynamic discounting system and method
US20110307345A1 (en) * 2008-10-31 2011-12-15 Kemper Alexander C Dynamic discounting system and method
US20100299218A1 (en) * 2009-05-19 2010-11-25 Nokia Corporation Method and apparatus of providing discovery and payment for online commerce
US9251539B2 (en) * 2010-01-15 2016-02-02 Apollo Enterprise Solutions, Ltd. System and method for resolving transactions employing goal seeking attributes
AP2013007185A0 (en) * 2011-03-21 2013-10-31 Infosys Technologies Ltd System and method for rule-based presentment and payment of bill or invoices
WO2012161720A1 (en) 2011-05-20 2012-11-29 Primerevenue, Inc. Supply chain finance system
US8924974B1 (en) * 2011-06-08 2014-12-30 Workday, Inc. System for error checking of process definitions for batch processes
WO2013059815A1 (en) * 2011-10-21 2013-04-25 Thomas Daniel B Network-based electronic invoicing system with reverse invoicing
JP5856181B2 (en) * 2011-10-25 2016-02-09 株式会社アイエスアイ Electronic money remittance method and system
US10026120B2 (en) 2012-01-06 2018-07-17 Primerevenue, Inc. Supply chain finance system
GB2513512A (en) * 2012-02-14 2014-10-29 Allen Cage Closed loop accounts payable network system and method
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
WO2013166207A1 (en) * 2012-05-02 2013-11-07 Oxygen Finance Americas, Inc. Systems for and methods of securitizing asset-backed supplier rebate cash flows derived from procurement expenditures
US20130297392A1 (en) * 2012-05-02 2013-11-07 Bank Of America Corporation Intelligent offer tool
WO2013166210A1 (en) * 2012-05-02 2013-11-07 Oxygen Finance Americas, Inc. Systems for and methods of establishing closed-loop business payment services
CN104471602A (en) * 2012-05-16 2015-03-25 英特拉有限公司 Invoice and freight statement matching and dispute resolution
US11625741B2 (en) 2012-07-05 2023-04-11 Share Edge, Llc Systems and methods of sharing promotional information
US10963903B1 (en) 2012-07-05 2021-03-30 Share Edge, Llc Workflow management system for tracking event objects associated with entities and secondary entities
US20140012649A1 (en) * 2012-07-06 2014-01-09 Bank Of America Corporation Allocating offer savings to non-profit organizations
US11468410B2 (en) 2012-07-11 2022-10-11 Viewpost, Llc. Universal payment module and system
US10607236B2 (en) 2012-07-11 2020-03-31 Viewpost, Llc Universal system for enabling dynamically discounted buyer-vendor payments
US20140019346A1 (en) * 2012-07-11 2014-01-16 Max Eliscu Universal system for electronic check creation and payment via image cash letter
US8762271B2 (en) 2012-07-11 2014-06-24 Viewpost, Llc Universal payment module and system
US9373120B2 (en) 2012-07-20 2016-06-21 Bank Of America Corporation Reverse couponing
US9514474B2 (en) * 2012-07-20 2016-12-06 Bank Of America Corporation Offers based on life events
US20140032290A1 (en) * 2012-07-30 2014-01-30 Bank Of America Corporation Incentive for offer distribution
US10650385B1 (en) 2012-10-08 2020-05-12 Viewpost, Llc System and method for remote check assurance
US20150039500A1 (en) * 2013-08-05 2015-02-05 Masco Corporation Process for invoice agent coupling
US10389671B2 (en) * 2013-09-12 2019-08-20 W.W. Frainger, Inc. System and method for providing personalized messaging
US9058626B1 (en) 2013-11-13 2015-06-16 Jpmorgan Chase Bank, N.A. System and method for financial services device usage
US20150178835A1 (en) * 2013-12-20 2015-06-25 David W. Quillian Supply chain finance system
US9721248B2 (en) 2014-03-04 2017-08-01 Bank Of America Corporation ATM token cash withdrawal
US20180357619A1 (en) * 2014-12-22 2018-12-13 Wells Fargo Bank, N.A. Supplier Finance and Invoice Presentation and Payment
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US10373157B1 (en) 2015-07-30 2019-08-06 Payability, LLC Computer system for accelerating resource transfers based on non-finalized operation information
US10163082B1 (en) * 2015-10-26 2018-12-25 Intuit Inc. Gamification of fields in online e-commerce documents
US10261782B2 (en) * 2015-12-18 2019-04-16 Amazon Technologies, Inc. Software container registry service
US10460367B2 (en) 2016-04-29 2019-10-29 Bank Of America Corporation System for user authentication based on linking a randomly generated number to the user and a physical item
US20170364879A1 (en) * 2016-06-15 2017-12-21 Mastercard International Incorporated Transaction flows and transaction processing for bridged payment systems
US10268635B2 (en) 2016-06-17 2019-04-23 Bank Of America Corporation System for data rotation through tokenization
US10057145B2 (en) * 2016-10-11 2018-08-21 Bank Of America Corporation Establishing an operative connection between a computing network and a third-party computing system for transmitting indications of process relationships
US20180322521A1 (en) * 2017-05-08 2018-11-08 Zycus Infotech Pvt.Ltd. Auto extension of discount offer for electronic transaction
JP7180224B2 (en) * 2018-09-18 2022-11-30 富士フイルムビジネスイノベーション株式会社 Information processing device and program
US11449844B1 (en) * 2019-03-11 2022-09-20 Coupa Software Incorporated Management of payment plan data in a distributed environment
US11275782B2 (en) 2019-05-17 2022-03-15 Bank Of America Corporation Digital systems and methods for a consolidated transfer matrix
US11361390B2 (en) 2019-10-02 2022-06-14 Mastercard International Incorporated Scheduling a payment based on a recommended payment schedule for a business entity
US20210142328A1 (en) * 2019-11-13 2021-05-13 Early Warning Services, Llc System and method for preventing fraud in real-time payment transactions
US11657408B2 (en) 2020-01-07 2023-05-23 Bank Of America Corporation Synchronously tracking and controlling events across multiple computer systems
US11204760B2 (en) 2020-02-20 2021-12-21 Share Edge, Llc Online activity monitoring
WO2021231450A1 (en) 2020-05-11 2021-11-18 Jpmorgan Chase Bank, N.A. Integrated supplier networks
US20230289750A1 (en) * 2022-03-14 2023-09-14 Fidelity Information Services, Llc Systems and methods for executing real-time electronic transactions by a dynamically determined transfer execution date
US11934375B2 (en) 2022-07-28 2024-03-19 The Toronto-Dominion Bank System for automatic data transfer acceleration
CN117114669B (en) * 2023-10-17 2024-03-15 深圳市企企通科技有限公司 Account payment-based data processing method, device, equipment and medium

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010051919A1 (en) * 2000-03-14 2001-12-13 Mason Elaine Scott Early-payment discount for E-billing system
US6347307B1 (en) * 1999-06-14 2002-02-12 Integral Development Corp. System and method for conducting web-based financial transactions in capital markets
US20020082985A1 (en) * 2000-12-21 2002-06-27 Mackay J. Sott Method and system for converting existing or future trade credit obligations into a new obligation
US7155409B1 (en) * 1999-03-05 2006-12-26 Trade Finance Service Corporation Trade financing method, instruments and systems
US7496519B2 (en) * 2002-05-10 2009-02-24 U.S. Bank National Association Automated transaction processing system and approach

Family Cites Families (319)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB1250686A (en) * 1968-10-14 1971-10-20
US4205780A (en) 1977-03-21 1980-06-03 Teknekron, Inc. Document processing system and method
US4264808A (en) * 1978-10-06 1981-04-28 Ncr Corporation Method and apparatus for electronic image processing of documents for accounting purposes
US4321672A (en) * 1979-11-26 1982-03-23 Braun Edward L Financial data processing system
JPS56101264A (en) 1980-01-16 1981-08-13 Omron Tateisi Electronics Co Electronic cash register for restaurant
US4385285A (en) * 1981-04-02 1983-05-24 Ncr Corporation Check dispensing terminal
DE3227166C1 (en) * 1982-07-21 1984-04-12 Vohrer, Christoph, 6240 Königstein Method of making a reinforced hose
US4617457A (en) 1983-12-19 1986-10-14 Ncr Corporation Teller-assisted, customer-operated ATM document cashing system
US4752877A (en) 1984-03-08 1988-06-21 College Savings Bank Method and apparatus for funding a future liability of uncertain cost
US4812628A (en) * 1985-05-02 1989-03-14 Visa International Service Association Transaction system with off-line risk assessment
US4672377A (en) 1985-09-09 1987-06-09 Murphy Arthur J Check authorization system
US4700055A (en) 1985-10-15 1987-10-13 Kashkashian Jr Arsen Multiple credit card system
US5508731A (en) * 1986-03-10 1996-04-16 Response Reward Systems L.C. Generation of enlarged participatory broadcast audience
US4823264A (en) * 1986-05-27 1989-04-18 Deming Gilbert R Electronic funds transfer system
JPH0412883Y2 (en) * 1986-09-08 1992-03-26
US4799156A (en) * 1986-10-01 1989-01-17 Strategic Processing Corporation Interactive market management system
US5053607A (en) 1986-10-06 1991-10-01 Carlson Steven R Point-of-sale device particularly adapted for processing checks
JP2624674B2 (en) * 1987-04-10 1997-06-25 株式会社日立製作所 Transaction processing system
US5023904A (en) 1987-08-04 1991-06-11 Science Dynamics Corporation Direct telephone dial ordering service
US4797913A (en) * 1987-08-04 1989-01-10 Science Dynamics Corporation Direct telephone dial ordering service
US5121945A (en) 1988-04-20 1992-06-16 Remittance Technology Corporation Financial data processing system
US4948174A (en) 1988-04-20 1990-08-14 Remittance Technology Corporation Financial data processing system
US4974878A (en) 1988-04-20 1990-12-04 Remittance Technology Corporation Financial data processing system using payment coupons
FR2639742B2 (en) * 1988-05-30 1992-03-13 Dassault Electronique TRANSACTION SYSTEM OF THE MIXED ELECTRONIC PURSE TYPE
US5265007A (en) 1988-06-07 1993-11-23 Huntington Bancshares Incorporated Central check clearing system
US4931793A (en) 1988-07-01 1990-06-05 Solitron Devices, Inc. System for providing a warning when vehicles approach a common collision point
US5054096A (en) 1988-10-24 1991-10-01 Empire Blue Cross/Blue Shield Method and apparatus for converting documents into electronic data for transaction processing
US5225978A (en) 1989-01-25 1993-07-06 Usisys Corp. Document processing system having integrated expert module
JPH02236664A (en) 1989-03-10 1990-09-19 Fujitsu Ltd Processor for note or check
US5080748A (en) * 1989-03-14 1992-01-14 Bostec Systems, Inc. Card assembly apparatus
US5305196A (en) 1989-05-01 1994-04-19 Credit Verification Corporation Check transaction processing, database building and marketing method and system utilizing automatic check reading
US5557515A (en) 1989-08-11 1996-09-17 Hartford Fire Insurance Company, Inc. Computerized system and method for work management
US6003762A (en) 1989-09-06 1999-12-21 Fujitsu Limited Transaction terminal for an electronic cashless system
US5349170A (en) 1989-10-10 1994-09-20 Unisys Corporation Image-based document processing system providing enhanced transaction balancing
US5122950A (en) 1989-11-02 1992-06-16 Moneyfax, Inc. Method of and system for electronic funds transfer via facsimile machines
US5111395A (en) * 1989-11-03 1992-05-05 Smith Rodney A Automated fund collection system including means to eliminate duplicate entries from a mailing list
US5198975A (en) * 1989-11-30 1993-03-30 Valley National Bank Apparatus and method for processing of check batches in banking operations
US5870724A (en) * 1989-12-08 1999-02-09 Online Resources & Communications Corporation Targeting advertising in a home retail banking delivery service
US5287269A (en) * 1990-07-09 1994-02-15 Boardwalk/Starcity Corporation Apparatus and method for accessing events, areas and activities
US5175682A (en) 1990-12-14 1992-12-29 Verifone, Inc. Check system and method including prioritizing checks for transmission to banks for processing
US5187750A (en) * 1991-03-15 1993-02-16 Unisys Corporation Archival document image processing and printing system
US5237159A (en) 1991-07-17 1993-08-17 J. D. Carreker And Associates Electronic check presentment system
US5383113A (en) * 1991-07-25 1995-01-17 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans
US6289322B1 (en) * 1998-03-03 2001-09-11 Checkfree Corporation Electronic bill processing
US5566330A (en) 1991-08-20 1996-10-15 Powersoft Corporation Method for forming a reusable and modifiable database interface object
JP2862036B2 (en) 1991-09-17 1999-02-24 三菱電機株式会社 Numerical control unit
US5136502A (en) 1991-10-02 1992-08-04 Fred Van Remortel System for funding, analyzing and managing health care liabilities
US5396417A (en) * 1991-11-01 1995-03-07 Capitol Cities/Abc, Inc. Product distribution equipment and method
JPH0721754B2 (en) 1991-11-08 1995-03-08 インターナショナル・ビジネス・マシーンズ・コーポレイション Graphical user interface
US5557518A (en) 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5640577A (en) 1991-12-30 1997-06-17 Davox Corporation Data processing system with automated at least partial forms completion
US5432506A (en) 1992-02-25 1995-07-11 Chapman; Thomas R. Counterfeit document detection system
CA2086694C (en) * 1992-03-05 1996-12-31 Steven K. Miller System, data processing method and program to provide a programmable interface between a workstation and an archive server to automatically store telephone transaction information
US5583760A (en) 1992-05-22 1996-12-10 Beneficial Franchise Company, Inc. System for establishing and administering funded and post-funded charge accounts
US5336870A (en) 1992-05-26 1994-08-09 Hughes Thomas S System for remote purchase payment transactions and remote bill payments
US5326959A (en) 1992-08-04 1994-07-05 Perazza Justin J Automated customer initiated entry remittance processing system
US5502576A (en) * 1992-08-24 1996-03-26 Ramsay International Corporation Method and apparatus for the transmission, storage, and retrieval of documents in an electronic domain
US5315508A (en) * 1992-09-03 1994-05-24 Monarch Marking System Label generating and data tracking system for processing purchase orders
ES2198407T3 (en) * 1992-09-30 2004-02-01 Motorola, Inc. SYSTEM OF DISTRIBUTION OF EMAIL MESSAGES.
US5283829A (en) * 1992-10-01 1994-02-01 Bell Communications Research, Inc. System and method for paying bills electronically
US5479494A (en) 1992-10-05 1995-12-26 At&T Corp. Virtual calling card system
US5424938A (en) 1992-10-13 1995-06-13 First Chicago Corporation Method and apparatus for providing access to a plurality of payment networks
US5373550A (en) 1992-10-13 1994-12-13 At&T Corp. Transmission of check images by way of a public switched telephone network
US5504677A (en) * 1992-10-15 1996-04-02 Pollin; Robert E. Automated payment system
US5966698A (en) 1992-10-15 1999-10-12 Pollin; Robert E. Automated payment system and method
EP0692119A1 (en) * 1992-10-22 1996-01-17 American Express Travel Related Services Company, Inc. Automated billing consolidation system and method
US5484988A (en) * 1992-11-13 1996-01-16 Resource Technology Services, Inc. Checkwriting point of sale system
US5350906A (en) 1992-11-25 1994-09-27 Brody Bill E Currency transfer system and method using fixed limit cards
DE59307854D1 (en) 1992-12-01 1998-01-29 Landis & Gyr Business Support Process for the compensation of services and / or goods and device for carrying out the process
US5311594A (en) * 1993-03-26 1994-05-10 At&T Bell Laboratories Fraud protection for card transactions
US5367581A (en) 1993-03-31 1994-11-22 Direct Data Systems Magnetic reader with read head biased against document by resilient deflection of circuit board
GB9313640D0 (en) 1993-07-01 1993-08-18 Ncr Int Inc Document transaction apparatus
US5570465A (en) 1993-07-22 1996-10-29 Tsakanikas; Peter J. Apparatus, method and system for printing of legal currency and negotiable instruments
US5551021A (en) 1993-07-30 1996-08-27 Olympus Optical Co., Ltd. Image storing managing apparatus and method for retreiving and displaying merchandise and customer specific sales information
US5666493A (en) 1993-08-24 1997-09-09 Lykes Bros., Inc. System for managing customer orders and method of implementation
US5444794A (en) 1993-08-25 1995-08-22 Sqn Check image capture system
US5940811A (en) 1993-08-27 1999-08-17 Affinity Technology Group, Inc. Closed loop financial transaction method and apparatus
EP0715740B1 (en) * 1993-08-27 2001-07-04 Affinity Technology, Inc. Closed loop financial transaction method and apparatus
JP3566739B2 (en) * 1993-09-30 2004-09-15 三省製薬株式会社 Stabilization method for skin external preparation
FR2710996B1 (en) 1993-10-06 1995-12-01 Gemplus Card Int Multi-application portable card for personal computer.
US5920847A (en) 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
US5465206B1 (en) 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
US6636615B1 (en) 1998-01-20 2003-10-21 Digimarc Corporation Methods and systems using multiple watermarks
US6574350B1 (en) 1995-05-08 2003-06-03 Digimarc Corporation Digital watermarking employing both frail and robust watermarks
US5583759A (en) 1993-11-22 1996-12-10 Huntington Bancshares, Inc. Mechanism for expediting the deposit, transport and submission of checks into the payment system
US5930778A (en) 1993-11-22 1999-07-27 Huntington Bancshares Incorporated System for expediting the clearing of financial instruments and coordinating the same with invoice processing at the point of receipt
EP1235177A3 (en) * 1993-12-16 2003-10-08 divine technology ventures Digital active advertising
US5446740A (en) 1993-12-17 1995-08-29 Empire Blue Cross/Blue Shield Method of and apparatus for processing data at a remote workstation
US5592377A (en) * 1993-12-18 1997-01-07 Lipkin; Edward B. Check cashing system
US5550734A (en) 1993-12-23 1996-08-27 The Pharmacy Fund, Inc. Computerized healthcare accounts receivable purchasing collections securitization and management system
US5509074A (en) 1994-01-27 1996-04-16 At&T Corp. Method of protecting electronically published materials using cryptographic protocols
US5870456A (en) * 1997-01-22 1999-02-09 Telepay, Inc. Automated interactive bill payment system using debit cards
US5715298A (en) * 1996-05-16 1998-02-03 Telepay Automated interactive bill payment system using debit cards
EP0667594A3 (en) 1994-02-14 1995-08-23 International Business Machines Corporation Image quality analysis method and apparatus
WO1995022113A1 (en) 1994-02-14 1995-08-17 Telepay, Inc. Automated interactive bill payment system
JPH07244702A (en) 1994-03-07 1995-09-19 Glory Ltd Check processor
US5748780A (en) * 1994-04-07 1998-05-05 Stolfo; Salvatore J. Method and apparatus for imaging, image processing and data compression
US20020170966A1 (en) 1995-07-27 2002-11-21 Hannigan Brett T. Identification document including embedded data
US5506691A (en) * 1994-03-23 1996-04-09 International Business Machines Corporation Method and apparatus for image processing at remote sites
WO1995027945A1 (en) 1994-04-06 1995-10-19 Morgan Stanley Group Inc. Data processing system and method for financial debt instruments
US5500513A (en) * 1994-05-11 1996-03-19 Visa International Automated purchasing control system
US5477040A (en) 1994-05-23 1995-12-19 Lalonde; Michael G. Structure for a method of facilitating charge transactions
US5832447A (en) 1994-05-24 1998-11-03 Envoy Corporation Automated system and method for providing real-time verification of health insurance eligibility
US5649117A (en) 1994-06-03 1997-07-15 Midwest Payment Systems System and method for paying bills and other obligations including selective payor and payee controls
US5603025A (en) * 1994-07-29 1997-02-11 Borland International, Inc. Methods for hypertext reporting in a relational database management system
US5592378A (en) * 1994-08-19 1997-01-07 Andersen Consulting Llp Computerized order entry system and method
US5826241A (en) 1994-09-16 1998-10-20 First Virtual Holdings Incorporated Computerized system for making payments and authenticating transactions over the internet
US5590196A (en) 1994-10-06 1996-12-31 Connotech Experts Conseils Inc. Secure payment method using facsimile
US5717989A (en) * 1994-10-13 1998-02-10 Full Service Trade System Ltd. Full service trade system
US5513250A (en) * 1994-10-13 1996-04-30 Bell Atlantic Network Services, Inc. Telephone based credit card protection
US5715314A (en) * 1994-10-24 1998-02-03 Open Market, Inc. Network sales system
US6073104A (en) 1994-11-09 2000-06-06 Field; Richard G. System for invoice record management and asset-backed commercial paper program management
US6181837B1 (en) 1994-11-18 2001-01-30 The Chase Manhattan Bank, N.A. Electronic check image storage and retrieval system
US5870723A (en) * 1994-11-28 1999-02-09 Pare, Jr.; David Ferrin Tokenless biometric transaction authorization method and system
US5679938A (en) 1994-12-02 1997-10-21 Telecheck International, Inc. Methods and systems for interactive check authorizations
US6298335B1 (en) * 1995-01-06 2001-10-02 Robert Bernstein Method of controlling payment of debts
US5742775A (en) 1995-01-18 1998-04-21 King; Douglas L. Method and apparatus of creating financial instrument and administering an adjustable rate loan system
US5784696A (en) 1995-02-24 1998-07-21 Melnikoff; Meyer Methods and apparatus for evaluating portfolios based on investment risk
US5717868A (en) * 1995-03-07 1998-02-10 Huntington Bancshares Inc. Electronic payment interchange concentrator
US5826245A (en) 1995-03-20 1998-10-20 Sandberg-Diment; Erik Providing verification information for a transaction
US5659741A (en) 1995-03-29 1997-08-19 Stuart S. Bowie Computer system and method for storing medical histories using a carrying size card
US5715399A (en) * 1995-03-30 1998-02-03 Amazon.Com, Inc. Secure method and system for communicating a list of credit card numbers over a non-secure network
US5677955A (en) 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US5657389A (en) 1995-05-08 1997-08-12 Image Data, Llc Positive identification system and method
US5615109A (en) * 1995-05-24 1997-03-25 Eder; Jeff Method of and system for generating feasible, profit maximizing requisition sets
US5708422A (en) * 1995-05-31 1998-01-13 At&T Transaction authorization and alert system
US5832460A (en) 1995-06-02 1998-11-03 International Business Machines Corporation Method and system for bill presentation and payment reconciliation
US5692132A (en) 1995-06-07 1997-11-25 Mastercard International, Inc. System and method for conducting cashless transactions on a computer network
US5703344A (en) 1995-06-30 1997-12-30 Visa International Service Association Electronic funds confirmation at point of transaction
US5794221A (en) 1995-07-07 1998-08-11 Egendorf; Andrew Internet billing method
US5802499A (en) 1995-07-13 1998-09-01 Cedel Bank Method and system for providing credit support to parties associated with derivative and other financial transactions
US5659165A (en) 1995-07-24 1997-08-19 Citibank. N.A. Customer-directed, automated process for transferring funds between accounts via a communications network
US5893080A (en) * 1995-07-25 1999-04-06 Bottomline Technologies, Inc. Disbursement system and method
US6223168B1 (en) * 1995-07-25 2001-04-24 Bottomline Technologies, Inc. Automatic remittance delivery system
US6788800B1 (en) * 2000-07-25 2004-09-07 Digimarc Corporation Authenticating objects using embedded data
US5870725A (en) * 1995-08-11 1999-02-09 Wachovia Corporation High volume financial image media creation and display system and method
US6026388A (en) * 1995-08-16 2000-02-15 Textwise, Llc User interface and other enhancements for natural language information retrieval system and method
US5852812A (en) 1995-08-23 1998-12-22 Microsoft Corporation Billing system for a network
US5864609A (en) * 1995-09-11 1999-01-26 At&T Corp. Method for establishing customized billing arrangements for a calling card in a telecommunications network
US5859419A (en) * 1995-09-28 1999-01-12 Sol H. Wynn Programmable multiple company credit card system
US5806048A (en) 1995-10-12 1998-09-08 Mopex, Inc. Open end mutual fund securitization process
US5689593A (en) 1995-10-13 1997-11-18 E-Tek Dynamics, Inc. Compact fiberoptic circulator with low polarization mode dispersion
US5699528A (en) 1995-10-31 1997-12-16 Mastercard International, Inc. System and method for bill delivery and payment over a communications network
US5757917A (en) 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
AU703984B2 (en) 1995-11-21 1999-04-01 Citibank, N.A. Foreign exchange transaction system
US6058380A (en) 1995-12-08 2000-05-02 Mellon Bank, N.A. System and method for electronically processing invoice information
US6088686A (en) 1995-12-12 2000-07-11 Citibank, N.A. System and method to performing on-line credit reviews and approvals
US5819238A (en) 1996-12-13 1998-10-06 Enhanced Investment Technologies, Inc. Apparatus and accompanying methods for automatically modifying a financial portfolio through dynamic re-weighting based on a non-constant function of current capitalization weights
US5802498A (en) 1996-01-11 1998-09-01 Comesanas; Jorge Computer-aided prepaid transmittal charge billing system
US6016482A (en) * 1996-01-11 2000-01-18 Merrill Lynch & Co., Inc. Enhanced collateralized funding processor
US6301379B1 (en) 1996-01-17 2001-10-09 Carreker-Antinori, Inc. Electronic check presentment systems and methods employing volatile memory datastore access techniques
AU713314B2 (en) 1996-02-09 1999-11-25 Citibank, N.A. Invoice purchase order system
JPH09231276A (en) 1996-02-27 1997-09-05 Canon Inc Charging device, communication device, and communication system
IT1285286B1 (en) * 1996-03-01 1998-06-03 Finmeccanica Spa DEVICE FOR AUTOMATIC CHECK READING.
US20020023055A1 (en) * 1996-03-01 2002-02-21 Antognini Walter Gerard System and method for digital bill presentment and payment
US5835899A (en) 1996-03-01 1998-11-10 Electronic Data Systems Corporation System and method for deriving financial responsibility identification
US5832463A (en) 1996-03-28 1998-11-03 Electronic Data Systems Corporation Automated system and method for checkless check transaction
US5835580A (en) 1996-04-04 1998-11-10 At&T Corp Method and apparatus for automated provisioning and billing of communication services
US6016484A (en) * 1996-04-26 2000-01-18 Verifone, Inc. System, method and article of manufacture for network electronic payment instrument and certification of payment and credit collection utilizing a payment
GB9610645D0 (en) 1996-05-21 1996-07-31 Ncr Int Inc Financial transaction system
JPH09325998A (en) * 1996-06-07 1997-12-16 Shimizu Corp Charge transfer processing system
US6076072A (en) 1996-06-10 2000-06-13 Libman; Richard Marc Method and apparatus for preparing client communications involving financial products and services
US5793861A (en) 1996-06-11 1998-08-11 Executone Information Systems, Inc. Transaction processing system and method
US5897621A (en) * 1996-06-14 1999-04-27 Cybercash, Inc. System and method for multi-currency transactions
US5848400A (en) 1996-07-01 1998-12-08 Sun Microsystems, Inc. Electronic check exchange, clearing and settlement system
US5884288A (en) * 1996-07-01 1999-03-16 Sun Microsystems, Inc. Method and system for electronic bill payment
US5770843A (en) 1996-07-02 1998-06-23 Ncr Corporation Access card for multiple accounts
US6088683A (en) 1996-08-21 2000-07-11 Jalili; Reza Secure purchase transaction method using telephone number
US6129273A (en) 1996-08-21 2000-10-10 Shah; Dinesh V. Method and apparatus for an automated, computer approved, check cashing system
US7039603B2 (en) 1996-09-04 2006-05-02 Walker Digital, Llc Settlement systems and methods wherein a buyer takes possession at a retailer of a product purchased using a communication network
US6108639A (en) 1996-09-04 2000-08-22 Priceline.Com Incorporated Conditional purchase offer (CPO) management system for collectibles
US6240444B1 (en) 1996-09-27 2001-05-29 International Business Machines Corporation Internet web page sharing
AU745141B2 (en) 1996-10-09 2002-03-14 Visa International Service Association Electronic statement presentment system
US6070150A (en) 1996-10-18 2000-05-30 Microsoft Corporation Electronic bill presentment and payment system
US6058381A (en) 1996-10-30 2000-05-02 Nelson; Theodor Holm Many-to-many payments system for network content materials
US5910896A (en) 1996-11-12 1999-06-08 Hahn-Carlson; Dean W. Shipment transaction system and an arrangement thereof
KR20000069550A (en) 1996-12-20 2000-11-25 챨스 에이치. 셀라 Method and system for processing electronic documents
US6085168A (en) 1997-02-06 2000-07-04 Fujitsu Limited Electronic commerce settlement system
US6149056A (en) 1997-02-06 2000-11-21 Mr. Payroll Corporation Automatic check cashing using biometric identification verification
US6111858A (en) 1997-02-18 2000-08-29 Virata Limited Proxy-controlled ATM subnetwork
US6070798A (en) 1997-02-21 2000-06-06 Nethery; Kee Purchaser generated transaction recording and negotiable instrument payment system
US6338049B1 (en) * 1997-03-05 2002-01-08 Walker Digital, Llc User-generated traveler's checks
US6041312A (en) * 1997-03-28 2000-03-21 International Business Machines Corporation Object oriented technology framework for accounts receivable and accounts payable
WO1998044441A1 (en) 1997-03-31 1998-10-08 Bellsouth Intellectual Property Corporation A system and method for associating services information with selected elements of an organization
US6014636A (en) * 1997-05-06 2000-01-11 Lucent Technologies Inc. Point of sale method and system
US6278981B1 (en) 1997-05-29 2001-08-21 Algorithmics International Corporation Computer-implemented method and apparatus for portfolio compression
US5897625A (en) * 1997-05-30 1999-04-27 Capital Security Systems, Inc. Automated document cashing system
US5987439A (en) 1997-05-30 1999-11-16 Capital Security Systems, Inc. Automated banking system for making change on a card or user account
US5903881A (en) 1997-06-05 1999-05-11 Intuit, Inc. Personal online banking with integrated online statement and checkbook user interface
US6061665A (en) 1997-06-06 2000-05-09 Verifone, Inc. System, method and article of manufacture for dynamic negotiation of a network payment framework
US6035281A (en) * 1997-06-16 2000-03-07 International Business Machines Corporation System and method of multiparty billing for Web access
US5945653A (en) 1997-06-26 1999-08-31 Walker Asset Management Limited Partnership System and method for establishing and executing functions to affect credit card accounts and transactions
IL121192A0 (en) 1997-06-30 1997-11-20 Ultimus Ltd Processing system and method for a heterogeneous electronic cash environment
US6110044A (en) 1997-07-15 2000-08-29 Stern; Richard H. Method and apparatus for issuing and automatically validating gaming machine payout tickets
US6292789B1 (en) 1997-08-26 2001-09-18 Citibank, N.A. Method and system for bill presentment and payment
US5910988A (en) * 1997-08-27 1999-06-08 Csp Holdings, Inc. Remote image capture with centralized processing and storage
US6044362A (en) * 1997-09-08 2000-03-28 Neely; R. Alan Electronic invoicing and payment system
US6128603A (en) 1997-09-09 2000-10-03 Dent; Warren T. Consumer-based system and method for managing and paying electronic billing statements
US6038553A (en) * 1997-09-19 2000-03-14 Affiliated Computer Services, Inc. Self service method of and system for cashing checks
US6000832A (en) 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
US5946669A (en) 1997-09-30 1999-08-31 Lockheed Martin Corporation Method and apparatus for payment processing using debit-based electronic funds transfer and disbursement processing using addendum-based electronic data interchange
US6009442A (en) 1997-10-08 1999-12-28 Caere Corporation Computer-based document management system
US6317727B1 (en) 1997-10-14 2001-11-13 Blackbird Holdings, Inc. Systems, methods and computer program products for monitoring credit risks in electronic trading systems
US5991750A (en) 1997-10-24 1999-11-23 Ge Capital System and method for pre-authorization of individual account transactions
US6128602A (en) 1997-10-27 2000-10-03 Bank Of America Corporation Open-architecture system for real-time consolidation of information from multiple financial systems
US5987435A (en) 1997-10-30 1999-11-16 Case Shiller Weiss, Inc. Proxy asset data processor
US6393409B2 (en) 1997-10-31 2002-05-21 Morgan Stanley Dean Witter & Co. Computer method and apparatus for optimizing portfolios of multiple participants
US5978780A (en) 1997-11-21 1999-11-02 Craig Michael Watson Integrated bill consolidation, payment aggregation, and settlement system
US6119106A (en) 1997-11-26 2000-09-12 Mersky; Randy Method and apparatus for facilitating customer payments to creditors from a remote site
US5943656A (en) 1997-12-03 1999-08-24 Avista Advantage, Inc. Methods and systems for computerized bill consolidating, billing and payment authorization, computerized utility bill consolidating, utility billing access and payment and utility provider consolidated billing systems
US5930773A (en) * 1997-12-17 1999-07-27 Avista Advantage, Inc. Computerized resource accounting methods and systems, computerized utility management methods and systems, multi-user utility management methods and systems, and energy-consumption-based tracking methods and systems
US6035287A (en) * 1997-12-17 2000-03-07 Omega Consulting, Inc. Method and apparatus for bundled asset trading
US6115690A (en) 1997-12-22 2000-09-05 Wong; Charles Integrated business-to-business Web commerce and business automation system
US6052674A (en) * 1997-12-23 2000-04-18 Information Retrieval Consultants (Europe, Middle East, Africa ) Limited Electronic invoicing and collection system and method with charity donations
US6098053A (en) 1998-01-28 2000-08-01 Citibank, N.A. System and method for performing an electronic financial transaction
US6029139A (en) * 1998-01-28 2000-02-22 Ncr Corporation Method and apparatus for optimizing promotional sale of products based upon historical data
US6304858B1 (en) 1998-02-13 2001-10-16 Adams, Viner And Mosler, Ltd. Method, system, and computer program product for trading interest rate swaps
US6078907A (en) 1998-02-18 2000-06-20 Lamm; David Method and system for electronically presenting and paying bills
US6405173B1 (en) 1998-03-05 2002-06-11 American Management Systems, Inc. Decision management system providing qualitative account/customer assessment via point in time simulation
US6105011A (en) 1998-03-19 2000-08-15 First Union Corporation Security system and method for business transactions with customers
US6081790A (en) 1998-03-20 2000-06-27 Citibank, N.A. System and method for secure presentment and payment over open networks
ID28328A (en) * 1998-03-24 2001-05-10 Telcordia Tech Inc METHODS FOR USING PHONE CALL CARD FOR BUSINESS TRANSACTIONS
US6006208A (en) 1998-03-25 1999-12-21 First Usa Bank, N.A. MICR line decoding logic system
US6721715B2 (en) * 1998-03-30 2004-04-13 Martin A. Nemzow Method and apparatus for localizing currency valuation independent of the original and objective currencies
US6064764A (en) 1998-03-30 2000-05-16 Seiko Epson Corporation Fragile watermarks for detecting tampering in images
US6173272B1 (en) * 1998-04-27 2001-01-09 The Clearing House Service Company L.L.C. Electronic funds transfer method and system and bill presentment method and system
US6098070A (en) 1998-06-09 2000-08-01 Hipersoft Corp. Case management for a personal injury plaintiff's law office using a relational database
US6073113A (en) 1998-06-29 2000-06-06 Sun Microsystems, Inc. Compatibility checking between instruments, operations and protocols in electronic commerce
US6418420B1 (en) 1998-06-30 2002-07-09 Sun Microsystems, Inc. Distributed budgeting and accounting system with secure token device access
US6825940B1 (en) 1998-07-01 2004-11-30 Ncr Corporation Method of processing documents in an image-based document processing system and an apparatus therefor
US6138118A (en) 1998-07-30 2000-10-24 Telcordia Technologies, Inc. Method and system for reconciling concurrent streams of transactions in a database
US6343279B1 (en) 1998-08-26 2002-01-29 American Management Systems, Inc. System integrating credit card transactions into a financial management system
US7236950B2 (en) * 1998-10-29 2007-06-26 Universal Card Services Corp. Method and system of combined billing of multiple accounts on a single statement
US6324524B1 (en) 1998-11-03 2001-11-27 Nextcard, Inc. Method and apparatus for an account level offer of credit and real time balance transfer
US6260024B1 (en) 1998-12-02 2001-07-10 Gary Shkedy Method and apparatus for facilitating buyer-driven purchase orders on a commercial network system
JP2000182086A (en) 1998-12-18 2000-06-30 Toshiba Corp Ticket issuing method and ticket collation method
US6233566B1 (en) 1998-12-31 2001-05-15 Ultraprise Corporation System, method and computer program product for online financial products trading
US6067524A (en) 1999-01-07 2000-05-23 Catalina Marketing International, Inc. Method and system for automatically generating advisory information for pharmacy patients along with normally transmitted data
US5987436A (en) 1999-01-26 1999-11-16 Halbrook; W. Bracey Obligated investment system
US6535896B2 (en) * 1999-01-29 2003-03-18 International Business Machines Corporation Systems, methods and computer program products for tailoring web page content in hypertext markup language format for display within pervasive computing devices using extensible markup language tools
US7062456B1 (en) 1999-02-09 2006-06-13 The Chase Manhattan Bank System and method for back office processing of banking transactions using electronic files
US6493685B1 (en) 1999-02-10 2002-12-10 The Chase Manhattan Bank Electronic account presentation and response system and method
US6609125B1 (en) 1999-03-23 2003-08-19 The Chase Manhattan Bank Funds transfer repair system
FI990660A (en) 1999-03-25 2000-09-26 Mecsel Oy Apparatus and method for buying a product from a vending machine
AU4238500A (en) 1999-04-13 2000-11-14 Richard J. Gagnon Method of obtaining an electronically-stored financial document
US6609113B1 (en) 1999-05-03 2003-08-19 The Chase Manhattan Bank Method and system for processing internet payments using the electronic funds transfer network
US6704714B1 (en) * 1999-05-03 2004-03-09 The Chase Manhattan Bank Virtual private lock box
US6227447B1 (en) 1999-05-10 2001-05-08 First Usa Bank, Na Cardless payment system
US6418430B1 (en) 1999-06-10 2002-07-09 Oracle International Corporation System for efficient content-based retrieval of images
US6338047B1 (en) * 1999-06-24 2002-01-08 Foliofn, Inc. Method and system for investing in a group of investments that are selected based on the aggregated, individual preference of plural investors
US6374235B1 (en) * 1999-06-25 2002-04-16 International Business Machines Corporation Method, system, and program for a join operation on a multi-column table and satellite tables including duplicate values
US6952682B1 (en) * 1999-07-02 2005-10-04 Ariba, Inc. System and method for matching multi-attribute auction bids
US6415259B1 (en) 1999-07-15 2002-07-02 American Management Systems, Inc. Automatic work progress tracking and optimizing engine for a telecommunications customer care and billing system
US6321212B1 (en) 1999-07-21 2001-11-20 Longitude, Inc. Financial products having a demand-based, adjustable return, and trading exchange therefor
US6418419B1 (en) 1999-07-23 2002-07-09 5Th Market, Inc. Automated system for conditional order transactions in securities or other items in commerce
US7340433B1 (en) 1999-07-30 2008-03-04 Orbian Management Limited System and method of transaction settlement using trade credit
US6578015B1 (en) 1999-08-31 2003-06-10 Oracle International Corporation Methods, devices and systems for electronic bill presentment and payment
US6578000B1 (en) 1999-09-03 2003-06-10 Cisco Technology, Inc. Browser-based arrangement for developing voice enabled web applications using extensible markup language documents
US20030233305A1 (en) 1999-11-01 2003-12-18 Neal Solomon System, method and apparatus for information collaboration between intelligent agents in a distributed network
US20020069134A1 (en) 1999-11-01 2002-06-06 Neal Solomon System, method and apparatus for aggregation of cooperative intelligent agents for procurement in a distributed network
US20010032139A1 (en) 1999-12-03 2001-10-18 Debonnett Allison P. Cybermoney network; a seamless internet commercial and investment bank account connectivity interface for payment and settlement of goods and services purchased via the internet
US6629081B1 (en) 1999-12-22 2003-09-30 Accenture Llp Account settlement and financing in an e-commerce environment
US6490568B1 (en) 1999-12-29 2002-12-03 First Data Corporation Automated system and method for monitoring financial transactions
US7177836B1 (en) * 1999-12-30 2007-02-13 First Data Corporation Method and system for facilitating financial transactions between consumers over the internet
US20010047329A1 (en) * 2000-01-05 2001-11-29 Ashby David C. Electronic exchange apparatus and method
US7028012B2 (en) 2000-01-31 2006-04-11 Polaroid Corporation System and method for ordering customized identification documents via a network
US20030105641A1 (en) 2000-03-17 2003-06-05 Woodson Lewis Electronic ticketing and validation system and method
US20020107770A1 (en) 2000-05-12 2002-08-08 Meyer Chadwick M. System for allocating funds in a plurality of stock portfolios
AU2001274979A1 (en) 2000-05-24 2001-12-03 Duocash, Inc. System and method for using existing prepaid card systems for making payments over the internet
US6941363B2 (en) 2000-05-26 2005-09-06 Fujitsu Limited Transaction management system and program for configuring online shopping system
JP2002056063A (en) * 2000-05-31 2002-02-20 Fujitsu Ltd Reception/distribution system, reception/distribution program and recording medium
US10185936B2 (en) 2000-06-22 2019-01-22 Jpmorgan Chase Bank, N.A. Method and system for processing internet payments
US7584125B2 (en) 2000-06-26 2009-09-01 Jpmorgan Chase Bank, N.A. Electronic check presentment system and method having an item sequence capability
US8417628B2 (en) 2000-06-29 2013-04-09 Jpmorgan Chase Bank, N.A. Electronic bill presentment and payment system and method
JP2002083241A (en) * 2000-06-30 2002-03-22 Aozora Bank Ltd Commodity price payment device, commodity price payment system, commodity price payment method and information storage medium
US8725620B2 (en) * 2000-07-10 2014-05-13 Nobuyoshi Morimoto System and method for negotiating improved terms for products and services being purchased through the internet
AU2001277025A1 (en) * 2000-07-25 2002-02-05 Michael A. Wilkman Universal transaction manager agent, systems and methods
EP1182625A1 (en) 2000-08-25 2002-02-27 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Introduction of an electronic payment transaction
JP2002087536A (en) * 2000-09-14 2002-03-27 Sharp Corp Service providing method of home delivery service using electronic tag
US7383223B1 (en) 2000-09-20 2008-06-03 Cashedge, Inc. Method and apparatus for managing multiple accounts
US7287071B2 (en) * 2000-09-28 2007-10-23 Vignette Corporation Transaction management system
US7249044B2 (en) * 2000-10-05 2007-07-24 I2 Technologies Us, Inc. Fulfillment management system for managing ATP data in a distributed supply chain environment
US20030046218A1 (en) * 2000-10-05 2003-03-06 Albanese Bernard J. System and method for protecting positions in volatile markets
JP2002133272A (en) * 2000-10-25 2002-05-10 Saikuron:Kk Method for providing information on barter trading
JP2002140505A (en) * 2000-10-31 2002-05-17 Mitsubishi Corp System and method for supporting dealings and computer- readable recording medium
WO2002039360A1 (en) 2000-11-08 2002-05-16 Orazio Pater Electronic payment system and method
US6970259B1 (en) 2000-11-28 2005-11-29 Xerox Corporation Systems and methods for forgery detection and deterrence of printed documents
US20020087468A1 (en) 2000-12-28 2002-07-04 Ravi Ganesan Electronic payment risk processing
US20020087469A1 (en) 2000-12-28 2002-07-04 Ravi Ganesan Technique of registration for and direction of electronic payments in real-time
US20020087452A1 (en) * 2001-01-04 2002-07-04 International Business Machines Corporation System, method and program product for improving broker's profits in electronic commerce
US20020107788A1 (en) 2001-02-05 2002-08-08 Cunningham Patrick Steven Application and payment database system for lenders and builders and a method therefor
US20020111837A1 (en) 2001-02-09 2002-08-15 Aupperle Bryan E. Verification method for web-delivered materials using self-signed certificates
US20020199182A1 (en) 2001-02-15 2002-12-26 Susan Whitehead Method and apparatus providing convergent solution to end-to end, adaptive business application management
US20020120537A1 (en) * 2001-02-28 2002-08-29 Dominic Morea Web based system and method for managing business to business online transactions
WO2002073349A2 (en) 2001-03-08 2002-09-19 Morgan Stanley Dean Witter & Co. Method and apparatus for trading assets, capital, and information
AU2002252280A1 (en) 2001-03-09 2002-09-24 Omnexus Americas, Inc. Marketplaces for on-line contract negotiation, formation and price and availability querying
US20020138398A1 (en) 2001-03-26 2002-09-26 Kalin Dan M. Automated bandwidth exchange node system
GB0107766D0 (en) 2001-03-28 2001-05-16 Hewlett Packard Co Improvements relating to developing documents
US7104443B1 (en) 2001-04-23 2006-09-12 Debitman Card, Inc. Method and system for facilitating electronic funds transactions
US7116361B2 (en) 2001-04-30 2006-10-03 Hewlett-Packard Development Company Image storage queue adapted to store images according to archival status
US7177840B2 (en) 2001-06-01 2007-02-13 Vectorsgi, Inc. Method and system for processing images for a check sorter
US20030018557A1 (en) * 2001-07-18 2003-01-23 Gilbert James A. Financial processing gateway structure
US7099845B2 (en) * 2001-08-16 2006-08-29 Ncr Corporation Electronic check presentment with image interchange system and method of operating an electronic check presentment with image interchange system
US20030097335A1 (en) 2001-11-21 2003-05-22 International Business Machines Corporation Secure method and system for determining charges and assuring privacy
AU2002359821A1 (en) 2001-12-21 2003-07-15 Xmlcities, Inc. Extensible stylesheet designs using meta-tag and/or associated meta-tag information
US7890393B2 (en) * 2002-02-07 2011-02-15 Ebay, Inc. Method and system for completing a transaction between a customer and a merchant
EP1345163B2 (en) 2002-03-15 2010-12-29 Computer Sciences Corporation Methods for analysis of writing in documents
US8407143B2 (en) 2002-03-27 2013-03-26 The Western Union Company International negotiable instrument payment
US20030225663A1 (en) 2002-04-01 2003-12-04 Horan James P. Open platform system and method
US7698182B2 (en) 2002-04-29 2010-04-13 Evercom Systems, Inc. Optimizing profitability in business transactions
US20030220863A1 (en) 2002-05-24 2003-11-27 Don Holm System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US7143344B2 (en) 2002-06-12 2006-11-28 Microsoft Corporation Transformation stylesheet editor
AU2003901043A0 (en) 2003-03-07 2003-03-20 Torto, Anthony Transaction system
WO2005026893A2 (en) 2003-09-05 2005-03-24 Sensitech Inc. Automated generation of reports reflecting statistical analyses of supply chain processes
US20050177480A1 (en) 2004-01-20 2005-08-11 Silicon Valley Micro C Corporation Intelligent billing system
US7567912B2 (en) 2004-02-11 2009-07-28 Tradebeam, Inc. Method and system for automatically detecting that international shipment movement has satisfied a threshold condition
US8554673B2 (en) 2004-06-17 2013-10-08 Jpmorgan Chase Bank, N.A. Methods and systems for discounts management
US20060095374A1 (en) * 2004-11-01 2006-05-04 Jp Morgan Chase System and method for supply chain financing
US7765105B2 (en) 2004-12-30 2010-07-27 Sap Aktiengesellschaft Graphically representing goods management in supply chain

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7155409B1 (en) * 1999-03-05 2006-12-26 Trade Finance Service Corporation Trade financing method, instruments and systems
US6347307B1 (en) * 1999-06-14 2002-02-12 Integral Development Corp. System and method for conducting web-based financial transactions in capital markets
US20010051919A1 (en) * 2000-03-14 2001-12-13 Mason Elaine Scott Early-payment discount for E-billing system
US20020082985A1 (en) * 2000-12-21 2002-06-27 Mackay J. Sott Method and system for converting existing or future trade credit obligations into a new obligation
US7496519B2 (en) * 2002-05-10 2009-02-24 U.S. Bank National Association Automated transaction processing system and approach

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190108560A1 (en) * 2016-04-15 2019-04-11 Eckehard Stolz Method for automatically financing bills
WO2019202367A1 (en) * 2018-04-18 2019-10-24 Cashworks Operations Ag Method and system for facilitating a decision about a money transaction
CN109615511A (en) * 2019-01-07 2019-04-12 北京锐融天下科技股份有限公司 A kind of supply chain banking software system and method

Also Published As

Publication number Publication date
US20110251965A1 (en) 2011-10-13
US8244625B2 (en) 2012-08-14
AU2003243251A1 (en) 2003-12-12
US20030220863A1 (en) 2003-11-27
EP1514210A1 (en) 2005-03-16
JP2005527046A (en) 2005-09-08
WO2003100689A1 (en) 2003-12-04
AU2003243251B2 (en) 2010-05-27
US8484129B2 (en) 2013-07-09
CA2483348C (en) 2016-07-26
EP1514210A4 (en) 2006-05-17
US8108296B2 (en) 2012-01-31
US20120278143A1 (en) 2012-11-01
CA2483348A1 (en) 2003-12-04
US20100274729A1 (en) 2010-10-28

Similar Documents

Publication Publication Date Title
US8484129B2 (en) System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US20230410165A1 (en) Supply chain finance system
US7437327B2 (en) Method and system for buyer centric dispute resolution in electronic payment system
AU2009200961B2 (en) Method and system for conducting a commercial transaction between a buyer and a seller
US8005730B2 (en) Expense tracking, electronic ordering, invoice presentment, and payment system and method
US7464057B2 (en) Method and system for multi-currency escrow service for web-based transactions
US8407141B2 (en) System and method for processing multiple methods of payment
US7519560B2 (en) System and method for electronic authorization of batch checks
US8571978B2 (en) Method and system for providing assurance and financing services
US20030220875A1 (en) Method and system for invoice routing and approval in electronic payment system
WO2014108910A2 (en) Products & services card and global card or payments network(s) mediated e-commerce & marketing service(s)
US8112355B1 (en) Method and system for buyer centric dispute resolution in electronic payment system
WO2001098957A2 (en) Financial transaction processing method and system

Legal Events

Date Code Title Description
AS Assignment

Owner name: JPMORGAN CHASE BANK, N.A., NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:JPMORGAN XIGN CORPORATION;REEL/FRAME:030435/0610

Effective date: 20080922

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION