System and method for electronic authorization of batch checks

A method of effecting payment. A system for effecting payment. Instructions to send a set of financial instruments to a set of recipients are received at a first system from an agent. A digital signature of the agent is created using a private key associated with the agent is added to the instructions. The agent is associated with a first entity. The instructions are transmitted to a second system. The second system in the instructions are verified using a public key corresponding to a private key associated with the agent. A set of financial instructions is created electronically and digital signatures created using a second private key are added to the financial instruments. The financial instruments from among the set of financial instruments are sent to respective recipients according to the instruments. According to one embodiment of the invention, the financial instruments are encrypted using public keys of respective recipients. According to another embodiment of the invention, terms are presented to the system administrator indicating that the entity shall be responsible for transactions effected by the agent before authorization is provided to the agent to effect creation of the checks with the digital signatures using the private key of the entity.

REFERENCE TO RELATED APPLICATIONS

This application is related to the following United States patent applications filed on even date herewith:

System and Method for Varying Electronic Settlements between Buyers and Suppliers with Dynamic Discount Terms, application Ser. No. 10/155,806, invented by Don Holm, Duc Lam and Xuan (Sunny) McRae;

System and Method for Electronic Payer (Buyer) Defined Invoice Exchange, 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, 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, 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 effecting payment. Instructions to send a set of financial instruments to a set of recipients are received at a first system from an agent. A digital signature of the agent created using a private key associated with the agent is added to the instructions. The agent is associated with a first entity. The instructions are transmitted to a second system. In the second system the instructions are verified using a public key corresponding to a private key associated with the agent. A set of financial instruments is created electronically and digital signatures created using a second private key are added to the financial instruments. The financial instruments from among the set of financial instruments are sent to respective recipients according to the instructions. In one implementation, the second key comprises a private key assigned to the first entity for which the recipients have access to a corresponding public key. In another implementation, the second private key comprises a private key assigned to the system for which recipients have access to a corresponding public key.

According to one embodiment of the invention, the financial instruments are encrypted using public keys of respective recipients. Alternately, respective financial instruments are encrypted with a dynamically generated session key. The dynamically generated session key is encrypted using the public key of the respective recipient and attached to the encrypted instrument. According to another embodiment of the invention, terms are presented to the system administrator indicating that the entity shall be responsible for transactions effected by the agent before authorization is provided to the agent to effect creation of the checks with the digital signatures using the private key of the entity. Alternatively, terms are presented to the system administrator indicating that the entity shall be responsible for transactions effected by the second system before authorization is provided to the second system to effect creation of the checks with digital signatures using the private key of the entity.

According to another embodiment of the invention, instructions are received at the second system from other agents associated with the first entity. The other agents have other private keys and sets of financial instruments are created electronically with digital signatures created using a private key other than the private keys of the agents. Such other private key may comprise a private key assigned to the entity, a private key assigned to the system or other private key in different embodiments of the invention. The financial instruments from among the set of financial instruments are sent to respective recipients according to the instructions.

Another embodiment of the invention is directed to a payment system. The payment system includes a first system associated with a first entity. The first system includes a resource received from an agent instructions to send a set of financial instruments to a set of recipients. The first system also includes a resource to hold a private key associated with an agent, and a resource to add a digital signature of the agent to the instructions using the private key associate with the agent.

The payment system, according to embodiment of the invention, also includes a second system operative to communicate with the first system. The second system includes a resource to verify the instructions using a public key corresponding to the private key associated with the agent. The second system includes a resource to create the set of financial instruments electronically including digital signatures created using a second private key. The second private key may comprise a private key assigned to the first entity for which recipients have access to a corresponding public key or, alternatively, a private key assigned to the system for which the recipients have access to a corresponding public key. The second system additionally includes a resource to forward financial instruments from among the set of financial instruments to respective recipients according to the instructions.

Another embodiment of the invention is directed to a method of effecting payment, including receiving from an agent at a first system instructions to send a set of checks to a set of recipients. A digital signature of the agent created using a private key associated with the agent is added to the instructions. The agent is associated with the first entity. The instructions are transmitted to a second system.

The instructions are verified at the second system using a public key corresponding to the private key associated with the agent. It is determined whether the agent has authority to send a set of checks with a second digital signature. The second digital signature comprises a digital signature of the entity or a digital signature of the second system according to various embodiments of the invention. It is determined whether checks among the set of checks are below a particular threshold. The set of checks is created electronically. Additional signatures from another agent or agents for checks among the set are obtained in response to attributes of the checks. The system administrator may specify the attributes of checks requiring additional signatures according to various implementations. Digital signatures created using a private key of the entity are added to the checks and checks from among the set of checks are sent to the respective recipients according to the instructions.

DETAILED DESCRIPTION

An embodiment of the invention is directed to a system that allows for authorization of batches of checks. The batches of checks, according to the embodiment of the invention, have a digital signature of the organization from which they are sent, digital signature of the system or other digital signature that can be identified by the respective recipients. The system accepts instructions from an individual agent, and based on these instructions, creates the batch of checks signed with the organization's digital signature, the signature of the system or other digital signature that can be identified by the respective recipients. The digital signature of the organization, digital signature of the system or other digital signature is created on a separate system not directly accessible by the agent. A system more directly accessible by the agent receives instructions from the agent and is caused to sign the instructions with a digital signature of the agent. In response to the instructions from the system accessible to the agent, the system not directly accessible by the agent creates and signs the batch of electronic checks with the digital signature of the organization. An advantage of this approach is that an agent is able to have a batch of checks signed even though the agent does not have direct access to the process of creating the digital signature on the checks. Security can be obtained through applying the agent's digital signature to the instructions for creating the batch of checks.

FIG. 1is a block diagram of an electronic batch check authorization system according to the embodiment of the invention.FIG. 1includes server102, server101, payee systems103and settlement system131. Server102includes agent logic104, agent private key105and batch instructions106. Agent104operates upon batch instructions106in conjunction to with agent private key105. Server101includes agent verification logic108, which is operative upon batch instructions107using agent public key109; encryption/signing logic114, which is operable upon batch checks110using entity private key115; encryption logic121, which is operable upon batch checks116using payees public keys122; and sender/routing logic127, which is operable upon sender queue123using global database128. Global database128stores agent public key109, payee public key122and routing information that allows for checks to be sent to respective recipients. Batch checks on server101include checks111,112, and113. Batch checks116include digital signatures,117on checks118,119and120. Sender queue123includes checks124,125and126.

Payee systems103are coupled to server101. Payee systems103include verification logic129and entity public key130. Entity public key130may be stored remotely on global database120, rather than being stored directly on payee systems103. Payee systems are coupled to settlement system131.

Server102includes agent logic104which receives instructions and data from an agent, which may be a software agent interfacing with ERP systems or software that receives information from a human user agent. Agent104causes a set of batch instructions106to be created, which are instructions to create a set of checks signed with a digital signature of the agent's organization or the system. Agent104causes batch instructions106to be signed with a digital signature using agent private key105. Agent private key105is a private key in a public/private key system. Items signed with the key can be verified with the corresponding key. Batch instructions106are uploaded, as batch instructions107, on to server101, which is not directly accessible by agent104.

Agent verification logic108acts upon batch instructions107using agent public key109to verify that the instructions were sent by agent104. Agent public key is used to verify a digital signature of the agent104. Additional verification and authorization may be performed by agent verification108. For example, a verification may be performed as to whether agent104has permission to create a batch of checks. Additionally, verification may be performed to determine whether particular checks within the batch are in a range of amount for which the agent has permission to create a batch-style check. According to other implementations, other verification schemes are performed upon the instructions such as for fraud detection and other purposes.

A batch of checks110is created from batch instructions107. Digital signatures are added to such checks using a private key of the organization, entity private key115. According to other implementations, private keys from different signing authorities may provide signatures on behalf of the entity. For example, a private key associated with server101may be used as entity private key115. Alternatively, another private key for which respective recipients have the corresponding public key may be used as entity private key115. The signing of the checks is performed through an encryption process, in which the content of respective checks is encrypted using a one-way hashing algorithm and then signed using the entity private key115. This encrypted content of the checks is appended to the respective checks, as shown in batch checks116with digital signatures117on checks118,119, and120. These digital signatures are available to then later be verified using the public key of the entity, for example entity public key130, in order to verify that the digital signature was created by the respective organization.

In order to help provide security, batch checks116are encrypted by encryption logic121using payee public keys122. In order to read the respective checks, the recipients use their private keys, according to the public key/private key encryption/decryption scheme. This helps to prevent a third party from being able to read and/or use the checks. According to other implementations, the respective checks are first encrypted with a dynamically generated session key that is then encrypted with the payee public keys122and attached to the encrypted document. This approach has certain efficiencies in certain implementations as compared to encrypting the entire check with the public key of the payees. The keys, such as agent public key109, entity private key115and payee public keys122may be stored in a global resource, such as global data base128.

The batch of checks is stored in a queue, sender queue123, in preparation for sending to respective recipients. Sender/routing logic127is operative upon sender queue123to schedule and send checks among the batch to respective recipients. Sender/routing logic127, according to the embodiment of the invention, schedules sending of the checks according to instructions among the batch107, which may call for a delay and different schedule dates upon which the checks are sent.

Checks from the batch are received by different respective entities. For example, here, entities are shown collectively as payee systems103. Such payee systems use verification logic129to verify that the checks were sent by proper sender. Verification logic129may also implement fraud detection, which can cross check information in the respective checks with the information stored when the checks were created. The information that is checked includes information created on server101as the checks were created, according to one implementation. After verification of the checks, payee systems are operative to notify settlement systems131, which settles payment. Settlement involves placement of the funds into the account of the payee. Alternatively, settlement is performed by reconciliation of debits and credits between payers and payees.

The items shown inFIG. 1may be implemented as software processes and data structures in a computer system. For example, server102, server101, payee systems103and settlement system131may represent separate computer servers or other systems. Such computer systems include computer hardware, according to one embodiment of the invention, such as processors, memory and communications electronics. The servers, according to one embodiment of the invention communicate via a computer network. Alternatively, the functions shown in the different respective servers may commonly performed by a single server or may be distributed among different servers. Logical functions such as agent logic104may be implemented as a software processes. For example, agent104may be defined in an object oriented program in scheme as agent object. Other implementations are possible. For example, agent104may be implemented as a software routine. Items such as batch instructions106, batch checks110, and sender queue123may be implemented as data structures stored in a computer memories or other storage device. Other implementations in software, hardware or other electronic technology are possible with respect to the functions and actions shown.

FIG. 2is flow diagram of electronic check authorization according to an embodiment of the invention. First, receive instructions from a user to send a set of checks (block201). The instructions are signed with the user's private keys (block202). This helps to ensure security, and in one implementation has the advantage of not providing the user with direct access to the entity's private key.

Next, the checks are signed with the entity's private key (block203). An advantage of this approach is that similar steps may be taken by other users in order to use the same private key of the entity. Use of the respective user's private keys helps provide security in one implementation. Other entities can recognize the digital signature of the entity by using the entity's public key, and these other entities do not need to know the different public keys or identities of the respective users who sent the batch instructions. Alternatively, the checks are signed using a private key assigned to the system on which the checks are signed. According to one embodiment of the invention, the checks are signed with a private key corresponding to a public key to which the recipients have access. The checks are optionally encrypted with the public keys of the respective recipients.

After they are signed, checks are sent to respective recipients based on the instructions (block204). The recipients receive the signed checks (block205). If the checks have been encrypted, they are decrypted. The checks are decrypted using the private key of the recipient. After receipt of the checks, the entity's signature is verified using the entity's public key (block206). Thus, the respective recipients are able to use a public key of the entity to verify the checks, even though the checks were created based on instructions signed with the user's private key. Alternatively, if the checks have been signed using another private key, the recipients are able to use the corresponding public key to which they have access to verify the checks, even though the checks were created based on instructions signed using the user's private key.

FIG. 3is a block diagram of a system for electronic check authorization and receipt according to an embodiment of the invention. The system inFIG. 3includes payer system302, server301, payee A system303, payee B system304and payee C system305. Instructions are sent from payer system302to server301to cause server301to create a batch of checks using the digital signature of the entity associated with payer system302. The checks are then sent to payee systems303,304and305.

Payer system302includes admin logic306, user logic308and agent logic310. Admin. logic306communicates with agent logic310and uses admin key307. Admin. logic also communicates with admin logic320of server301. Agent310using agent's key311, both of which are also located on payer system302.

The following is a description of certain relationships among the items in server301and between such items and certain other items shown inFIG. 3. Admin logic320of a server301communicates with admin logic306of payer system302and receives signatures using admin key307of payer302. Admin logic320communicates with assent records321. Verification logic323and rule processing logic329are operative upon instructions322. User signer logic327, batch signer328and encryption logic334are operative upon checks324. Batch signer uses entity key329, which is obtained from global database335. Encryption logic334uses information from global database335.

Scheduling/routing logic336receives checks324and uses information from global database335to send to respective payee systems303,304, and305. Recorder logic330and audit logic332store information regarding checks324in payment331and audit trail333respectively. Systems to which checks are sent include payee A system303, payee B system304and payee C systems305. Payee A system303includes decryption logic337, and signature verification logic338. Other payee systems include similar logic.

Agent logic310is authorized to create a respective set of instructions to send checks using the key of the entity associated with the payer's system through an administrative set up process. Admin logic306on payer system302is operative with admin logic320on server301in order to create such authorization. The setup involves admin306using admin key307to show that the respective entity agrees to the set up. The key is used to sign a document indicating the respective terms and conditions of the agent's use and the entity's responsibility for the agent's use of the batch check system. This consent is digitally signed by the administrator and using the admin key307. The digitally signed consent is stored in assent records321. Such records may be used in a case where the entity associated with payer's system302attempts to repudiate a transaction made by agent310. The assent records321help to show that the respective entity agreed that it would be responsible for the actions of agent310.

Server301creates a set of checks in response to instructions from payer system302. Agent logic310on payer system302creates a set of instructions312. Instructions312created by agent310with agent's key311are sent to server301and are received as instructions322. Instruction322are processed and verified by verification logic323. According to one implementation, verification logic323checks, using digital signature of agent310, as to whether the instructions were actually sent by agent310. Such verification may be performed through using the public key of the agent. Other types of verification for fraud detection may be performed. Rule processing logic339verifies various aspects of instructions in accordance with rules established as to the authority of the agent to send sets of checks using the digital signature of the entity. For example, in one implementation, checks only within a certain monetary amount range may be sent using such a process. Additionally, in another implementation, additional signature(s) are needed for checks in certain ranges of amount. Such signatures may be obtained through a user dialogue between payer systems302and server301, such as between user308and user signer logic327. User logic308user's key309to sign the respective document. Instructions322may include instructions regarding checks other than a set of checks for which the entity's digital signature is used. Such checks are shown inFIG. 3among checks324as non-batch checks325. A separate signature is used for such checks. User signer logic327is operative upon non-batch checks325to add such a digital signature to such checks.

Batch checks among326among checks324are signed by batch signer logic328using entity key329, which is a private key corresponding to a public key to which the recipients have access. For example, entity key329is a private key of the entity that is associated with payer system302. According to one implementation, entity key329comprises a private key assigned to the system on which batch checks are created and for which the recipients have access to the corresponding public key. After signature, checks in batch of checks are encrypted by encrypt logic334. The checks are encrypted to help provide security when they are transmitted. Encrypt logic334is operative upon checks324to encrypt such checks before sending. Encrypt logic334uses public keys of recipients and in global database335in order to perform the encryption.

Recorder logic330records the various checks created and stores such information into a payment file331. Such check information is available for verification, as may be performed for fraud detection. For example, according to an embodiment for the invention, payee systems, such as payee system A303, may verify information in payment file331to determine the authenticity of the respective check. Information regarding checks324also is recorded by audit logic332and stored in audit trail333. This information may be used for audit and accounting purposes by an entity associated with payer system302.

The checks are scheduled to be sent according to instructions322or other scheduling instructions. The checks are then sent to the respective recipients by scheduling/routing logic336. Scheduling/routing logic336uses information in global database335regarding addresses of the respective recipients. Such addresses may comprise emails addresses or other routing addresses. Checks are sent electronically to the respective recipients by e-mail, electronic data interchange (EDI) or other electronic means. Checks are received by respective recipients, for example, payee A system303. A check is decrypted using public key and private key process in decryption logic337in payee A system303. Signature verification takes place in signature verification logic338, in order to determine that the entity associated with payer system302actually has sent the check. Signature verification is carried out using the public key corresponding to the private key with which the check was signed. For example, signature verification is carried out using the public key of the respective entity that sent the check and digital signature.

The items shown may be implemented in various forms of computer and electronic hardware and software. For example, payer system302, server301, payee A system303, payee B system304and payee system305may be implemented on separate computer server systems. User computer system may include computer hardware such as a processor, memory, other storage in input/output (I/O). Functions shown such as admin logic306, agent logic310, and batch signer328may be implemented as a software processes. Such software processes may be implemented in various forms such as software objects or other types of software procedures or processes. Alternatively, functionality shown may implemented in other forms of electronic or computer hardware and/or software. Items such as global database335and payment file331may be implemented software data structures stored in computer memory including volatile memory and/or fixed hard drives or other forms of a memory or storage. Other implementations of the functions shown are possible and included within the scope of the invention.

FIG. 4is a flow diagram for electronic check authorization with additional signature according to an embodiment of the invention. Payment instructions are received on a user system (block401). A signature is received for the batch of checks in the user system (block402). This signature is typically from an agent and is a different signature than the one with which the batch checks are actually signed. The instructions are posted to the server (block403). Checks are created based on the instructions (block404). For checks in the set of checks created, it is determined whether each respective check is a batch check (block405). If a check is not a batch check, obtain the respective signature from the authorization employee (block406). Then after obtaining such signature, record payment data (413).

If a check is a batch check (block405), then next determine whether the signer of the instructions has batch check authority (block407). If the signer of the instructions does not have batch check authority, then obtain a signature from an authorizing employee (block406) and continue on to recording of the data (block413). If the signer of the instructions has batch check authority (block407), then determine whether the amount of the check is under the threshold set for such signer (block408). If the signer does not have such authority, if the check is not under such threshold, then obtain the respective signature of an authorizing employee (block406) and proceed to recording data (block413). If the check is under the threshold (block408), then perform a batch signature using the digital signature which the recipients are able to verify, such as a digital signature of the entity (block409).

Next, determine whether a second signature is needed (block410), and if such a signature is needed, obtain the signature (block406), and proceed to recording the data (block413). If such signature is not needed (block410), then determine whether audit approval is needed (block411). If audit approval is need (block411), then obtain the audit approval (block412) and proceed to recording data (block413). If an audit approval is not needed (block411), then proceed to recording the data (block413). The recording data (block413) may include recording payment data for use in fraud detection so that such data may be compared upon receipt of checks by payees with this data and data recorded may also include data needed for audit purposes. According to one implementation, payment data includes the name of the recipient, remittance information, amount, date and other identifying information, or various combinations of such information. Schedule the transmission of the checks (block414).

FIG. 5is a flow diagram of electronic check batch preparation, encryption, transmission and receipt according to an embodiment of the invention. Checks in a batch of checks are encrypted using public keys of the recipients, such as the batch of checks described previously in this application (block501). Next, transmission of the batch of checks is scheduled (block502). Checks from among the batch of checks are then received by recipients (block503).

When received, a check is decrypted (block504) using the private key of the recipient. The signature and identity of the payer of the decrypted check is verified (block505). Such verification, according to embodiment of invention, includes using a public key of the entity associated with the payer to decrypt the digital signature of the payer included in the check. According to another implementation, the respective public key corresponding to the private key used to sign the check is used to verify the digital signature of the payer included in the check. Next, perform fraud detection on the received check (block506). After such fraud detection, endorse the check (block507) and settle payment (block508). Settling payment may include the recipient sending the check to the recipient's bank and the recipient's bank sending a request of over a supplemental network. The supplemental network causes the payer's bank settle payment with the recipient's bank according to one implementation.

FIG. 6(a) is a user interface of role permission set-up according to an embodiment of the invention. User interface includes menus602, interface for a changing role limits or permissions603, interface for changing permissions for the role604and interface for changing bank account authorization for the role605. Menu602includes the following selections: users607, account608, suppliers609and control610. Currently item users607is selected. This menu item includes users611, new users612, roles613and new role614.

Interface to change role limits or permissions603includes a role name entry615, role description entry616, authorization box for user management authority617, authorization box for account management authority618, daily signing limit entry619, check signing limit621, no daily signing limit entry620and check cosigning limit622. Interface for entry of permissions for role604includes entry for view payment623, audit/approve release of payment624, payment625, import/sign payment instruction file (PIF)626, void payment627, hold payment628, stop payment629, create manual PIF630and rubber stamp PIFs631. Entry for bank account authorization for this role605includes account name column632, account number633, account number634, and account type635. In this example, row636includes “marketing” for account name632, which refers to account number 02664 (in column633) and checking description (in column635).

User interface601allows a system administrator to view and/or set up the attributes of a user with respect to the ability of a user to sign checks or take other actions. For example, a daily signing limit519, check singing limit621, and check co-signing limit622may be established for a particular role. This role, then may be applied to various users once it is established. The role has various permissions, such as shown in input for permissions for the role604. According to various embodiments of the invention, subsets of the such permissions may be selectable in a user interface. The advantage of such an approach is that a role may be established and used over a set of different users. Input606is typically shown when a role is assigned to a particular user.

FIG. 6(b) is a user interface of user permission authorization according to an embodiment of the invention. When the system administrator attempts to assign certain rights to a particular user, the system administrator must indicate that the entity who the system administrator represents agrees to certain terms and conditions. These terms and conditions are shown as terms and conditions652in window651. By clicking I agree, the administrator shows acknowledgement with agreement with the terms and conditions. Additionally, the system accepts the system administrator's password and use of the system administrator's private key to set up certain kinds of permissions. For example, to set up the particular user to be authorized to send batches of checks would require such authorization with digital signature according to an embodiment of invention.

Permissions for the role may include the permission to allow batches of checks to be signed using a digital signature of the organization, or in an alternative implementation, another digital signature that recipients can verify. Such digital signature would not be directly acted upon by the user, but would be caused to occur through a set of instructions signed with the user's digital signature. As shown here, such a permissions is entitled rubber stamp PIFs entry631. Upon selection of such permission, the associated role would have such capability. Then upon assigning the role to user, the system would receive an assent from the system administrator in which the system administrator uses the system administrator's digital signature to show agreement for such assignment

FIG. 7is a flow diagram of role permission set up according to an embodiment of the invention. An administrator is created for the entity. This administrator is able to set up various roles for use in the system associated with the entity. For example, the administrator is capable of setting up a role for a user or software agent to have permission cause sets of checks to be signed with the entity's digital signature. First create an administrator for the entity. Such a process may include additional verification that ensures that an individual has the appropriate permission from the entity to act as the administrator.

After the role of the administrator is created, a request to give a user permission to cause batch signatures of checks to occur using the digital signature of the entity, or in an alternative implementation, another digital signature that recipients can verify is received (block701). This request is received from the administrator of the entity. In response to such request, present terms to the administrator indicating that the entity is responsible for the user's actions (block703). Such terms may be presented in the form of a dialog box and require that the administrator sign assent to the terms using the administrator's digital signature. The terms for example may include language similar to the following:

“Automated ‘rubber stamp’ signature process authorization. By selecting this feature, Customer can (also referred herein as “you” and “your” is requesting that Facilitator enable the disburser application to allow automated digital signing and approval of payment instructions that are uploaded to the payment exchange system through a plug-in agent software (“ERP agent”). To complete this request, exchange company requires that you click the “I agree” button below and then digitally sign this request. The person accepting this agreement must be the primary disburser application administrator who has authority to authorized users and accounts in the disburser. You must accept this agreement from the workstation where your digital certificate is stored in order to complete the digitally signed form.”

Next, the assent to such terms with the administrator's digital signature is received (704). Such assent, according to the embodiment of the invention, takes place through the system administrator or the system receiving the acceptance of the agreement from the workstation where the digital certificate of the administrator is stored. Next, the assent is stored (block705). Such storage may take place by storing the digitally signed version of the terms and conditions with the digital certificate of the administrator. Instructions are then received to the created batch of checks with the user's digital signature (for the user for which the administrator has provided permissions) (block706). In response to such instructions, a batch of checks with the entity's digital signature (or, in another implementation, another digital signature that the recipients can verify) is sent according to the recipients in the instructions (block707).

FIG. 8is 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 as801, payee (vendor) shown as802, and financial institutions shown as850. 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 as828and A/P centric master vendor list shown as827. 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 as830, previous vendor histories of matching in the knowledge based shown as831, third party outsourced recommended matching proposal shown as832, and manual interactive selection from buyers shown as833. Each vendor is represented by several critical attributes in the global directory: addresses shown as838, real and alias accounts shown as839, and keys shown as840. Vendor entries are pre-populated with information uploaded from the buyer ERP system. The vendor enrolls via the online self-service enrollments835. Vendor also provides additional rules to match834, A/R remittance format attributes836, and notification rules/addresses837.

Accounts payable (A/P) buyer-centric enterprise software associated with payer system801includes several key unique functions. These functions include buyer defined electronic invoice exchange, routing/editing and approval, and dispute resolution. Payer system801includes invoice definition engine803, invoice804, HR organization data808, routing/editing logic805, dispute logic809, notifications logic812, disbursement logic813, dynamic terms logics/offers860, discount logic816and settlement logic817. Also included on payer system801are input output (I/O)810, processor811, entity key815, and payer central repository database827. The invoice definition engine803includes validation logic853, tolerance/replacement items855, interaction severity854, and several presentation forms856. This definition engine is controlled by payer helps provide clean invoice data from payees. The definition logics (853,854,855, and856) can be configured to specific payee or a specific group of payees.

Invoice definition engine803and its definition logics are exposed to payee via global directory and are operative with invoice definition/generation/validation818of payee system802. The routing/editing logic805includes 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 logic805can operate differently based on multiple attributes: document type, document value, discount value, etc. Routing/editing logic805acts on HR organization database808to define routing/editing/approval work flow based on employee information807and role values806. Invoice804is coupled into routing logic805. Routing logic805is coupled with employee logic807and role assignment806. Routing logic805is coupled with HR data808and with dispute logic809, notifications logic812and disbursement logic813of payer system801. Notification logic812is configured by the payer, and includes collaborative filtering, and mappings status and notification definitions between internal to external payees. These collaborative filtering and mappings can be designated to a payee or a group of payees.

Dispute logic809is 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 be finalized by payer and its members, and some finalized exchanges will require digital signature to ensure non-repudiation. The payer dispute logic809orchestrates with payee dispute logic822. Payer dispute logic, references, and history are stored in payer central repository827.

A/R web based centric software associated with payee system702helps provide an online self-service payee system. Payee system702includes a processor852and input/output (I/O)851. Such processor852and input/output851allow for communication with other entities such as payer system801, financial institutions850and global database828. Processor852and processor811of payee802and payer801respectively 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 database828may 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 system802includes invoice generation/validation logic818, invoice send logic821, dispute logic822, notifications logic823, receipt/validation logic824, discount logic825and settlement logic826. Invoices or other documents can be submitted to payer via multiple mechanisms. Three sample mechanisms are shown here: Web forms shown857, purchase order pre-populated invoice (PO flip)858, and electronic file submission via file mapping819. The Web forms857are 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 flip858uses 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 mapping819is 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 how 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 (857,858,819). The documents are validated based on the payer definition engine818. This definition engine818includes payer definition engine803and its components: validation853, severity854, tolerance855and presentation856.

Invoice generation/validation logic818is coupled with mapping logic819in communication with file data820. Invoice generation/validation logic818is coupled into invoice send logic821. Dispute logic822is coupled with dispute logic809of payer system801. Notifications logic823is in communication with notifications logic812of payer system801and discount logic825of payee system802. Receipt/validation824of payee system802is in communication with disbursement module813of payer system801. Settlement logic826is operative with discount logic825of payee system802and receipt/validation logic824. Global database828is available to notifications logic812and823, disbursement logic813, settlement logic817and826, invoice send logic821, receipt821and receipt/validation logic824. Global database828is in communication with payer database827through attribute match rules830, knowledge based history matching samples831, third party recommendation/proposal832and manual interactive matching by payers833. Global database828is in communication with payee database829through match rules834, enrollment logic835, remittance formats836and notification preferences837. Global database includes items such as address838, accounts839and public keys840. Payer database827is located with payer system801and payee database829is located with payee system802. Global database828is also available to financial institutions850.

Through invoice definition engine803a payer uses payer system801to 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 system802generates an invoice based on the defined invoice in invoice generation/validation logic818. The input data for the invoice is validated based on the invoice definition rules defined in payer system801. If file data is used to automatically map into an invoice, such mapping is performed in one embodiment of the invention by mapping logic819. Mapping logic819receives the file data820with information to be populated into respective invoices. File data820may 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 logic821to payer system801. 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 In voice Exchange, 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 system801as shown here with invoice804. 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 logic807is in communication with routing logic805to allow an employee to authorize, audit or view respective invoice or check information.

Routing logic805is also used to route checks or other documents to various employees for signature or approval using HR data808. Routing logic805uses HR data808to 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 database808. 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, application Ser. No. 10/155,853, invented by Bob Moore and Xuan (Sunny) McRae, and which is incorporated herein by reference in its entirety.

A user of payer system801may dispute an invoice or other payment request through dispute logic809. Dispute logic809is in communication with dispute logic822of payee system802. 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 logic809and822include the capability for individuals using the payer system801using payee system802to 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, 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 logic812communicates completion of various stages of approval or other issues of status regarding invoices and disbursement. For example, when an invoice is approved notifications logo812communicates a notification to notifications logic823of payee system802. Based on such notifications, a discount may be enabled through discount logic816, which is in communication with discount logic825of payee system802. For example, where an invoice is approved, a discount may be enabled based on an agreement or outstanding dynamic terms offers shown as860that 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 payer860or payee861. These dynamic terms rules860and861are 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. For additional information regarding discounts facilitated by the system, dynamic terms (860and861) and discount logic816and825please refer to US patent application entitled System and Method for Varying Electronic Settlements between Buyers and Suppliers with Dynamic Discount Terms, application Ser. No. 10/155,806, invented by Don Holm, Duc Lam and Xuan (Sunny) McRae which is incorporated herein by reference in its entirety.

To facilitate complete bill-to-payment functionality, the system inFIG. 8includes disbursement logic812and settlement logic817. Disbursement logic813includes 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 logic813makes 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 logic805to obtain a signature from employee logic807with role assignment digital key806.

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 logic814and disbursement logic813. Such batch processing logic814uses an entity key815, which is a private key of the payer's organization. Batch processing logic814requires 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 system802is in communication with disbursement logic813. Receipt/validation logic824receives 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 system802, such checks are decrypted. Additionally, the digital signature of the sender is authenticated in receipt/validation logic824. Such authentication is accomplished using the public key of the payer, which corresponds to the private key of the payer's organization (entity key815) that was used in batch processing logic814(entity key815). 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 logic817allows for settlement of payment between a payer system801and payee system802. 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 institutions850.

Settlement logic817supports 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 logic817is implemented via issuing requests to the settlement network. Such request can be file-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 database828is available for use by elements that send payment, such as disbursement logic813and settlement logic817. Global database828is 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 database828. Thus, invoice sends logic821is in communication with global database828.

Global database828includes 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 databases827, and matches are created between items, such as addresses or payment entities and payer827and respective items in global database828through a match generation process830. Such matched generation process830may include providing a user of the payer system801with a series of candidate matches between addresses stored on payer database827and corresponding spellings of addresses or payment entities in global database828. The user of payer system801is 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 database829and global database828can be performed so that payee system802can send items to the proper recipient using information in global database828. Enrollment logic835is available to enroll new entities as payees into the global database to make them available for use by payer system801or payee system802.

The links established are then available to allow for use of information in the respective payer database827and payee database829in order to find recipients to whom documents or payments are to be sent. In addition to address information838and account information839, according to one embodiment of the invention, public keys of various participants in the systems are stored in the global database828. Such keys are then available for use in order to determine the accuracy of a digital signature sent by a particular entity. Additional information regarding global database828and related logic and communication is contained in the United States Patent Application entitled Collaborative Vendor Reconciliation, application Ser. No. 10/155,797, invented by Duc Lam, George Muller, Chandra (CP) Agrawal, Baby Lingampalli, Pavel Login and Xuan (Sunny) McRae, which is incorporated herein by reference in its entirety.

In theFIG. 8system, invoices and other documents are exchanged between payers and payees over the public and internet networks880. To help provide security and privacy, before they are sent, invoices and other documents are signed with source private key, and encrypted with destination public key shown as881. 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 as882.

The system also can integrate with multiple enterprise resource planning (ERP) systems shown as862. 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.