WO2001041020A1

WO2001041020A1 - Server-based billing and payment system

Info

Publication number: WO2001041020A1
Application number: PCT/US2000/032729
Authority: WO
Inventors: Brian Hinton; Richard Domalewski
Original assignee: Bottomline Technologies Inc
Current assignee: Bottomline Technologies Inc
Priority date: 1999-12-03
Filing date: 2000-12-01
Publication date: 2001-06-07
Anticipated expiration: 2002-06-03

Abstract

A business-to-business server-based bill presentment and payment system is provided. The server includes a database for the establishment of a biller/payor community so that trusted business partners can maximize options related to bill presentment and payment. A linked web of billers and payors is established by biller/payor profiles. Dispute rules logic can be established by the biller to provide an automated, uniform adjudication process for the payor. Access control over the functionality of the server system is provided for separation of duties among payors with a payor organization. The server permits billers to submit electronic invoice data to a plurality of payors. Interface toolkits are provided to permit payors to view, select and sort invoices; as well as adjudicate invoices and authorize payment. A plurality of translation mechanisms and output options are provided to accept invoice data in a plurality of formats, output remittance data to the biller and invoice data to the payor, and generation of cashflow management reports.

Description

SERVER-BASED BILLING AND PAYMENT SYSTEM BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a server-based billing and payment collections system. More particularly, the present invention relates to a business-to-business system and methodology for internet-based billing and payment transactions between suppliers and customers. Particular utility for the present invention is in the presentation, adjudication, and/or payment of invoices between suppliers and customers over an internet-based transaction server, although other utilities are contemplated herein. 2. Brief Description of Related Art Traditional bill presentment and payment solutions between customers (payors) and suppliers (billers) include paper-based invoice presentment and payment. In this scenario, the steps required to send an invoice (on the biller' s side) and receive, and pay an invoice (on the payor' s side) relies on a series of paper-based procedures, sometimes across multiple, decentralized parties. For example, typical paper-based invoice presentment and payment relies on first distributing invoices via mail that typically takes 3-5 days to reach particular payors. In some large organizations, it is desirable (and usually required) to include separation of duties between invoice approval and actual payment, for audit purposes. Accordingly, invoices, once received, may go through several steps before payment is made. Upon receipt by an organization, the invoice must be approved by a purchasing manager, who determines if the invoice is accurate with respect to price, goods received, and/or discount terms. If not, this individual can, and usually will adjust the invoice directly, with handwritten adjustments to correct the invoice. Otherwise, payment is made to an otherwise unadjusted invoice. The invoice is then forwarded to the next individual in the accounts payable chain, until ultimately the invoice is authorized for payment. Another individual is typically responsible for creating and distributing a check to the biller, again by mail procedures. Upon receipt at the biller' s bank (or directly to the biller) the check must then go through further processing at either the bank or at the biller' s accounts receivable department. From distribution of the invoice by the biller to cash being posted by the biller' s accounts receivable (A/R), the typical time is two weeks or more. Moreover, any adjustments to the invoice made by the payor are not reflected in the biller' s A/R, and thus, an inherent discrepancy exists that cannot be resolved unless contact is made directly with the payor, further adding to the delay. On the payor' s side, information must be manually input into accounts payable (A/P). Additionally, payors are not given choices for payment methods since typically the biller accepts only one method of payment, i.e., company check, or some other pre-arranged payment option. In this conventional bill payment methodology, billers are disadvantageously unaware of the reasoning behind a payor' s refusal to pay an entire bill. Likewise, payors are usually unaware of potential discount terms, offers, or other deals not reflected in the invoice, and thus, often fail to maximize the relationship between buyer and seller. To alleviate some of the above-mentioned drawbacks of paper-based bill presentment and payment, several electronic solutions have been proposed. In U.S. Patent No. 5,699,528 issued to Hogan, a bill delivery and payment system is disclosed in which users are able to access a server computer on a communications network to obtain bill information and pay bills. The server computer hosts a website type interface for bill payors to access via the internet (or, worldwide web) using a personal computer. Bill information (forwarded from a biller) is provided in a user's mailbox, which is accessed by the interface to permit users to view the bill information and instruct the server computer to pay the invoice. Once a user has accessed an invoice, the user is permitted to include payment data of the payment type, for example, credit card and/or checking, payment amount, desired payment date, etc. Additionally, this bill payment system can provide a grievance process whereby a subscriber may put the entire or a partial bill amount in dispute. A similar example can be found in U.S. Patent No. 5,832,460 issued to Bednar et al. This patent discloses a system for creating, presenting, paying and reconciling bills electronically. The system includes an electronic bill presenter which receives bill data from billers and forwards this data to one or more bill payers. The bill payer can view the electronic bill data, and create an electronic bill payment instruction, that is sent to the bill presenter. The bill presenter forwards the payment instruction data to the appropriate financial institution for payment. This patent is primarily directed to consumers and small businesses, and is therefore not robust enough to support large-scale implementation of business-to-business communities of billers and payors. Another example is found in U.S. Patent No. 5,884,288 issued to Chang, et al. which provides a system and method for automated electronic bill processing by integrating a community of payors, payees, payor banks and payee banks interconnected by a computer network. In this system, a payor bank receives electronic bills specifying payment requests from one or more payors having an account at the payor bank. The payor bank places on hold the funds in the payor's account and then generates an electronic check that is transmitted to the payee. The payee receives an electronic check envelope that contains a number of electronic checks that are encrypted and digitally signed by the payor bank. The payee generates an electronic deposit including one or more endorsed electronic checks and a deposit slip. The electronic deposit is encrypted and digitally signed by the payee, and is transmitted to a payee bank. The payee bank authenticates the endorsed check and credits the payee's account accordingly. Still another example is found in U.S. Patent No. 5,963,925, issued to Kolling, et al., which provides an electronic statement presentment system. The system includes a central switch computer which coordinates templates storage, validation, routing and message passing between billers, work stations and consumer financial institutions. A template work station creates a template of static biller information to serve as a basis for the electronic statement. The template is stored in a template library at the switch. The switch validates the template by sending it to a template validation work station where batches of customer statement data are sent from a biller' s invoicing system along with a template identifier. The switch receives all the electronic statements from a particular biller during a giving billing cycle and then distributes those statements to an appropriate consumer financial institution for later delivery to the customers. Other examples can be found in U.S. Patent Nos. 5,920,847; 5,943,656; 5,956,700; and 5,383,113. However, each of the above mentioned references are largely directed to systems and methods for personal and/or small business bill payment, and are thus inappropriate for the needs of business-to-business communities, which require complex rules and rely on established relationships for bill presentment and payment transactions. These systems do not provide built-in relationships between billers and payors, which can be utilized to permit complex bill presentment and payment between suppliers and customers. Moreover, in the aforementioned electronic bill presentment and payment systems, feedback to a particular biller regarding an adjudicated invoice is not provided. Thus, accounts receivable (A/R) cannot be fully automated, since, if an invoice has been adjudicated by a payor, the incoming paid amount will differ from the outgoing billed amount, or, the payor simply places the invoice in dispute and pays an unseen adjusted amount. Moreover, since invoice adjudication is not controlled by the biller, the biller cannot be kept apprised of an adjudicated invoice, and must disadvantageously rely on assumptions that may not truly reflect the reasoning behind a payor's adjudication of an invoice. Additionally, on the payor's side of the transaction, these systems do not provide separation of duties, nor do these systems provide access control logic to invoice data, payment authorization, and payment options, to individuals within the payor's organization. Also, these systems do not provide inherent payor control over payment type and settlement date, since such control usually resides with the biller (or the biller' s bank). Thus, there exists a need to provide an electronic billing and payment system which serves the needs of business relationships by providing on-line bill presentment, bill review, authorization and payment origination processing. Additionally, there is a need to provide an electronic billing and payment system wherein an integrated platform manages related billers and payors in a manner to maximize biller/payor relationships, minimize delay, and permit billers to provide for and control numerous payment options and invoice dispute options, while allowing payors to manage and control payment types and invoice settlement dates. There further exists a need for payors to review and modify outstanding invoices and authorize funds transfer through a single platform, which also includes access control logic to limit and or define authorization to certain individuals within a business setting. There also exists a need to provide an electronic billing and payment system that provides integrated payables and receivables management. Additionally, a need exists to permit biller' s to define invoice adjudication rules and procedures so that payor's can take full advantage of adjustments on a given invoice, and billers can be fully apprised of invoice adjustments, so that billers' accounts receivables are kept up to date regarding any changes in a particular invoice. SUMMARY OF THE INVENTION Accordingly, it is an overall object of the present invention to provide an integrated platform for electronic bill presentment and payment and to establish a community of billers and payors so that trusted partners can automate the process of bill presentment, invoice adjudication, and payment authorization. It is another object of the present invention to provide an integrated electronic bill presentment and payment system and methodology which includes built-in relationships defined between billers (e.g., suppliers) and payors (e.g., customers) so that trusted partners can engage in bill presentment and payment through a unified network transaction interface. It is yet another object of the present invention to provide an integrated electronic bill presentment and payment system and methodology in which billers define dispute rules and adjudication options on a global and/or payor-by-payor basis, so that payors can take advantage of disputes and adjustment to invoices, and billers can keep apprised of any and all adjustments made to an invoice, and so that discounts and terms can be maximized between suppliers and customers. It is still another object of the present invention to provide an integrated electronic bill presentment and payment system and methodology which permits billers and payors to define robust payment options including credit card, ACH transfers, wire transfers and authorized debit transactions. It is yet another object of the present invention to provide an integrated electronic bill presentment and payment system and methodology in which payors can define access rights and responsibilities to numerous individuals within a payor's organization to permit separation of duties for audit trail purposes. A further object of the present invention is to provide an integrated electronic bill presentment and payment system and methodology in which payors are given a plurality of invoice payment options, and payors are given control over invoice settlement dates. Another object of the present invention is to provide a plurality of input/output translation options for both billers and payors. Thus, payors can specify a format for inputting invoice data into the server system and specify an output format for remittance data. Likewise, payors can specify an output format for invoice data. The output data format can be specified by the billers A/R package and the payors A/P package. Accordingly, the present invention solves the aforementioned shortcomings of the prior art by providing a secure, internet-based, interactive system for complex business- to-business transactions that permits companies to present billing information and accept payment over an internet server (e.g., extranet), all in electronic form. Through the integrated system, a biller can present an electronic invoice to a payor, using a password- protected mailbox dedicated to a payor. On the payor's side, the present invention provides a system to permit payors to review and/or modify outstanding invoices and authorize funds transfer directly on-line, within a single, integrated platform. Thus, unlike prior art bill presentment and payment systems, the present invention permits payors to dispute an electronic invoice directly online. On the biller's side, the present invention provides a system to permit billers to establish a priori dispute rules on a global and/or payor-by-payor basis, to allow payors to adjust an invoice to reflect discounts, price terms and/or quantity of goods received, so that payor's can maximize available discounts and/or price adjustments and billers are kept apprised of invoice disputes and reasons therefore. In one aspect, the present invention provides a server based bill presentment and payment system, comprising a biller and payor in communication with a network server. A database is provided containing data modules comprising a biller profile, a payor profile, dispute rules and access control. The server is operable to receive invoice data from the biller, translate the invoice data into a selected format, and store the invoice data on the database. The server is further operable to permit the payor to at least adjudicate the invoice data based on the dispute rules. In another aspect, the present invention provides a server-based bill payment and presentment system, comprising a network transaction server having an interface and a database and in communication with a plurality of billers and payors. The database comprising a payor profile and biller profile for each said payor and biller, and being adapted to link said biller profile and said payor profile based on a biller/payor relationship therebetween. The network interface receiving invoice data from said biller and permitting said payor to adjudicate said invoice and authorize payment. In another aspect, the present invention provides a server-based bill payment and presentment system, comprising a network transaction server having an interface and a database and in communication with a plurality of billers and payors. The database comprising a payor profile and biller profile for each said payor and biller and linking a plurality of payors with said biller using said profile data, and being adapted to link said biller profile and said payor profile based on a biller/payor relationship therebetween and thereby establishing a trading community of billers and payors. The network interface receiving invoice data from said biller and permitting said payor to adjudicate said invoice and authorize payment. In another aspect, the present invention provides a server based bill presentment and payment system, comprising a biller and payor in communication with a network server. A database is provided containing data modules comprising a biller profile, a payor profile, dispute rules and access control. The server is operable to receive invoice data from said biller, translate said invoice data into a selected format, and store said invoice data on said database. The server is further operable to permit said payor to at least adjudicate said invoice data based on said dispute rules, and to provide a payment instruction for the settlement of said invoice. In another aspect, the present invention provides a server based bill presentment and payment system, comprising a biller and payor in communication with a network server. A database is provided containing data modules comprising a biller profile, a payor profile, dispute rules and access control, said data modules being linked to one another to establish a trading community of billers and payors. The server is operable to receive invoice data from said biller, translate said invoice data into a selected format, and store said invoice data on said database; and further operable to permit said payor to at least adjudicate said invoice data based on said dispute rules, and to provide a payment instruction for the settlement of said invoice. In another aspect, the present invention provides a method for business-to- business bill payment and presentment, said method comprising the steps of: creating a plurality data modules comprising a biller profile, a payor profile, dispute rules and access control; linking said data modules to one another to establish a trading community of billers and payors; receiving invoice data from said biller, and translating said invoice data into a selected format, and storing said invoice data on a database; linking said invoice data to said data modules; and permitting a payor access to said invoice data to at least adjudicate said invoice data based on said dispute rules. Other features and advantages of the present invention will become apparent as the following Detailed Description proceeds, and upon reference to the Drawings, wherein like numerals depict like parts, and wherein: BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram representation of the electronic bill presentment and payment system of the present invention; Figure 2 is a more detailed block diagram representation of the bill presentment and payment system of Figure 1 with a focus on bill presentment and invoice settlement; Figure 3 is a more detailed block diagram representation of the bill presentment and payment system of Figure 1 with a focus on payor transactions; Figure 4 is a block diagram representation of exemplary functionality of the biller' s toolkit and the payor's toolkit of the bill presentment and payment system of Figure 1; Figures 5A-5G are exemplary screen shots of the preferred functionality of the network interface with the bill presentment and payment system of Figure 1 ; Figures 6A-6E are flowcharts depicting exemplary processes for the creation of the biller/payor database bill presentment and payment system of the present invention; Figure 7 is a flowchart depicting an exemplary invoice presentment process of the bill presentment and payment system of the present invention; and Figures 8A-8E are flowcharts depicting of the invoice review, invoice adjudication, invoice payment initiation, and invoice payment authorization processes of the bill presentment and payment system of the present invention. It will be appreciated by those skilled in the art/ that although the following Detailed Description will proceed with reference being made to preferred embodiments, the present invention is not intended to be limited to these embodiments. For example, it should be understood from the outset that although preferably the functional components of the preferred embodiments of the system of the present invention are embodied as one or more distributed computer program processes running on one or more conventional general purpose computers (e.g., IBM-compatible, Apple Macintosh, and/or RISC microprocessor-based computers), conventional telecommunications (e.g., modem and/or ISDN communications), and storage devices (e.g. disk array, direct access storage, etc.) networked together by conventional network hardware and software (e.g., LAN/WAN network backbone systems, etc.), other types of computers and network resources may be used without departing from the present invention. Furthermore, it should be appreciated from the outset that one or more of the functional components may alternatively be constructed out of custom, dedicated electronic hardware and/or software, with departing from the present invention. Thus, the present invention is intended to cover all such alternatives, modifications, and equivalents as may be included within the spirit and broad scope of the invention as defined only by the hereinafter appended claims. Detailed Description of Exemplary Embodiments With reference now being made to Figure 1 , the structure and operation of one exemplary embodiment 10 of the bill presentment and payment system of the present invention will be described. System 10 comprises a network transaction server 12, connected via a wide area telecommunications network (e.g., extranet and/or TCP/IP- based Internet-type of computer network) with a plurality of payors 14 and billers 16. As a broad overview, system 10 permits billers 16 to present invoices, in electronic form, to payors 14. Server system 12 permits payors 14 to access invoice data, adjudicate the invoice (if necessary), and pay the invoice, all from within the transaction server environment. Biller and payor each comprise an associated computer to access the server, and further comprise appropriate hardware and software (e.g., personal and/or mainframe computers provisioned with Internet wide area network communications hardware and software (e.g.,CQI-based, FTP, Netscape Navigator™ or Microsoft Internet Explorer™ HTML Internet Browser software, and/or direct real-time TCP/IP interfaces accessing real-time TCP/IP sockets) for permitting human users to send and receive data, and to control various operations of the server system 12, in real-time and/or batch-type transactions. Likewise, it is preferred that server 12 is a remote internet-based server that billers and payors can access through conventional communications channels (e.g., conventional telecommunications, broadband communications, wireless communications, etc.) using conventional browser software (e.g., Netscape, Internet Explorer, etc.). Thus, although not shown in the drawings, server 12, payors 14 and billers 16 are appropriately adapted to include such communication functionality and internet browsing ability. Additionally, those skilled in the art will recognize that the various components of the server system of the present invention can be remote from one another, and may further comprise appropriate communications hardware/software and/or LAN/WAN hardware and/or software to accomplish the functionality herein described. Although not shown in the drawings, the server 12 includes computer-readable memory to receive and store data and commands from the biller 16 and payor 14, via the network. The computer-readable memory is also used to store the components of the biller/payor database 110, and for storing the software associated with the transaction interface. Essentially, transaction server 12 includes a transaction interface 18 and a biller/payor database 20 for storing data related to the biller organization and payor organization, as will be detailed herein. A server administrator 22 is provided to establish the database 20, and to maintain the server system 12 and database system. One advantage of the present invention over aforementioned systems designed for individual bill payment is the built-in relationships between billers and payors, thus permitting suppliers and customers to effectuate complex transactions and bill payment options all from within the server environment, without having to resort to external and/or paper method to effectuate invoice distribution (presentment) and accounts receivables/payables management. Thus, it should be understood at the outset that payors 14 and billers 16 each subscribe to the electronic bill presentment and payment system 10 of the present invention. To do so, billers and payors each supply relevant data to the administrator 22, and the administrator relates billers and payors within the database 20 (described below) to establish a bill payment and presentment system. Additionally, the present invention can be adapted to provide output data 24 to the biller's bank (in the form of a payment instruction) and to both the biller and payor reflective of the invoice, adjudication (if applicable) and payment, for integration directly into general ledger (GL) applications locally residing on the biller's and payor's systems (for example, accounts receivable/payable programs (herein referred to as A/R and A/P)). As will be set out below, the biller/payor database 20 associates billers and payors and rules associated with the billers and payors to permit invoice presentment, invoice review, invoice adjudication and invoice payment transactions to occur from within the transaction server environment. To prevent unauthorized access to the database 20, the preferred embodiment includes firewall security 26 to shield the database to all but those users having explicit access to the data contained therein. The firewall security can comprise industry standard SSL encryption, Digital Certificates, etc., or may comprise custom and/or proprietary security protocols and algorithms. BILLER/PAYOR DATABASE: As noted above, before transactions between billers and payors occur within the server environment, billers and payors subscribe to the system by providing the server administrator 22 with relevant data for construction of the database 20. For understanding, the relevant data stored on the database are described herein as "data modules", although the data need not be stored discretely as shown in the figures, and may further comprise additional data not stated herein, as may be appropriate. As shown in Figure 1, the biller/payer database 20 is utilized herein to associate (i.e., relate) biller data with payor data and vice-versa, and is further utilized to store and retrieve output data in the form of payment data and/or output data to billers and/or payors. In the preferred embodiment, the interface 20 permits billers and payers to subscribe to the system by providing all of the preferred data (set out below) to the administrator 22 directly on-line, thus expediting the subscription process. Alternatively, billers and payors can subscribe to the system using conventional mail procedures and/or other procedures, for example, email communication, etc. Typically, the administrator 22 is part of the biller organization, since it is likely that biller's will host the transaction server described herein. However, it is equally contemplated that the administrator and host of the server system can include third parties not related to the biller or payor, or the payor could likewise administer and host the server system. Preferably, the biller (or the biller's representative or authorized agent) supplies data to the administrator 22 to create a biller profile 30 and dispute rules 32 data modules. Generally, the biller profile 30 comprises all of the relevant data associated with a biller, and preferably includes: the name (biller name), bank account(s), routing transit number(s), account number(s), and biller administrator (i.e., the individual(s) who are given limited access to the database to modify, delete or add to the biller profile). Each profile can, of course, include multiple accounts (including multiple account numbers) and multiple biller administrators. Moreover, different accounts can be available for different payors, i.e., payment accounts can be established globally or on a payor-by- payor basis, as may be desired. The dispute rules data module 32 is generally the mechanism by which a payor can adjudicate an invoice according to rules established a priori by the biller. Dispute rules are established by the biller on a global and/or payor- by-payor basis. The creation of dispute rules permits payors to take advantage of payment terms, discounts, and/or other adjustments without having to resort to unknown or undefined adjudication parameters. Preferably, the dispute rules are established in four levels: 1) general invoice adjustment, 2) price adjustment, 3) quantity adjustment, and/or 4) line item adjustment. The dispute rules are associated with each invoice at an appropriate data field location in the invoice, preferably utilizing pull-down menus within each data field that is accessible by the payor. This will be shown more clearly below, but, for example, price adjustment rules can be provided by the biller, so that a payor can adjust the price based on, for example, pre-arranged discount terms, field discount terms, quantity discount, short order price adjustment, damaged or partially damaged price adjustment, etc. To create the payor's association within the database, the payor (or the payor's representative or authorized agent) supplies data to the administrator 22 to create the payor profile 34 and access control 36 data modules. The payor profile preferably includes: name, payment option data (including, for example, credit card number, ACH credit data, wire transfer routing data, authorized debit data), contact data, user ID and user password data, etc. To accommodate multiple levels of invoice review and payment authorization, access control data module 36 includes a list of users, user IDs and passwords, and essentially comprises access logic to establish a chain of events for a given invoice. Essentially, access control defines who (within the payor organization) can change the payor profile 34, who can review an invoice, who can adjudicate and invoice, and who can authorize and make payment on an invoice. Access control also preferably automatically forwards an invoice along the payor's define chain of individuals, using password-protected mailboxes established within the server. The biller's data and payors data are associated in the database, and are related to one another, thereby establishing automated linkage between a plurality of billers and payors. Preferably, database 20 is a relational database. The type of data management technology applied in commercial data processing known as "relational" database technology is modeled such that all data is organized as though it is formatted into tables, with the table columns representing the table's fields or domains and the table rows representing the values of the table's fields or domains. Thus, data modules 30, 32, 34 and 36 are formatted as related tables. Data between tables can be related to one another, using, for example, pointer data. Data is logically organized as tables but is not necessarily physically stored as such. The relational database user (i.e., billers and payors) does not need to know how the database is physically constructed and can access and update data via a language interface or "structured query language" (SQL). As noted above, database 110 preferably comprises a relational database where the payor and biller profiles, access control logic and dispute rules are related between payors (customers) and billers (suppliers). For example, upon access of the system 10 by a payor (via login ID), the database will supply the relevant data for that payor and the biller, based on the data modules set out above. Additionally, the invoice data will include dispute rules, payment options, settlement date and other data for that payor in the appropriate, predefined, data field within the invoice. Moreover, the system advantageously permits multiple billers to be related to multiple payors, and vice versa, wherein rules can be applied globally or on a single basis. Another feature of the present invention is the ability to accept invoice data 28 from billers in a variety of formats, and convert the invoice data 28 into a "common", flat file- type data stream. Additionally, it is intended that invoice data and remittance data is forwarded (at an appropriate time in the payment process) to the payor and/or biller, respectively. Likewise, payment data is forwarded to the biller's bank. To this end, the present invention also preferably includes I/O translators 38 which map incoming invoice data into a flat file format, and store the translated invoice data 28' on the database 20. Additionally, I/O translators utilize maps to map invoice data and/or remittance data back to the payors and/or billers, respectively. Referring now to Figures 6A-6E, flowcharts depicting exemplary processes for the creation of the biller/payor database bill presentment and payment system of the present invention. For clarity, reference numerals of the various components of the system 10 shall be omitted. Figure 6C is an exemplary flowchart 130 depicting the creation the biller profile dispute rules. The system receives biller information from the billers 132. The type of information that is preferably supplied by the biller is described above, and includes all of the relevant data to accurately identify the biller and the biller's bank so that invoice data submitted to the system is properly routed based on the correct biller. To map incoming invoice data and to output remittance data, the system also receives biller's preferred I/O data format 134. This process is described in more detail below. As indicated above, part of the invention is the establishment of an on-line community of billers and payors. Thus, the system 10 also receives a list of payors who are to receive invoice data from billers 136. For each payor, or on a global basis, the system also receives dispute rules and reason codes from billers 138. All of this data is preferably linked together, and the server administrator creates the biller profile and dispute rules table 140. This information is stored on the database 142. Figure 6E depicts an exemplary flow chart for the input data mapping process 180 of the present invention. In this process, the server administrator receives invoice data input format from billers 182. Those skilled in the art will recognize that such data can be generated by billing system such as SAP, Oracle Financials, JD Edwards, People Soft, Great Plains, etc. The data outputted by these billing systems and input into the system can come in a variety of formats including raw data, print file format, and X-12 ANSI 810 (EDI). Likewise, it may be desirable to have remittance data forwarded back to the biller, once the invoice has been sent to the bank for settlement. To this end, the biller supplies preferred output remittance data format 184. Once the biller's input data format is established, the server administrator creates a map to translate the input data to the common flat file network format 186. This map is included as one of the I/O translators and is linked to the biller profile on the database 188. Also, a map is created to translate the network data format (i.e., flat file format) to the preferred remittance data format 190, which is also stored on the database 192. The maps and the links to the biller profile are stored on the database 194. It should be noted that the format for the remittance data can include and ANSI 820 instruction set, or the data format can be proprietary and/or specified by the biller's A/R system. Since the biller controls the bank to which payment data will be sent, Figure 6B depicts an exemplary flow chart 120 for the creation of a translator to translate the output data (payment data) in the appropriate format. The server administrator receives payment data output format from the biller or the biller's bank 122. This format typically comprises a generalized data stream but may also comprise an ACH-type payment data format. The server administrator creates a map to translate the network data to the appropriate payment data format 124. This map is stored on the database 128 and a link to the map is also stored in the biller's profile 126. To create the payor profile and access control logic, the system administrator also gathers information from the payor. Figure 6D is a flowchart 200 depicting an exemplary process for creating the payor profile and access control. The system administrator receives payor information from the payor(s) 202. As described above, the payor profile generally includes all the data necessary to identify the payor, process payment instructions and to link the payor with the biller. Such information can include, for example, name, payment option data (including, for example, credit card number, ACH credit data, wire transfer routing data, authorized debit data), contact data, user ID and user password data. As with the biller, it may be desirable to permit the payor to receive the invoice data, to be sent from the server system to the payor. To this end, the system also receives the payor's preferred I/O data format 204. As noted above, it is usually preferable to grant limited invoice access only certain individuals within the payors organization. To do so, payor login identifications and access control (e.g., password access) are identified 206. The access control logic is created 208, based on this information, and stored on the database 210. Also, to effectuate payments, the system receives the preferred billing method(s), provided by the payor 212. It should be noted that ultimately, the biller controls the method of payment, but it is preferred that the biller provide a plurality of payment options for the payor. With this data, the payor profile is created 214, and stored on the database. As will be described below, to view/edit invoices directly online, payors can choose a default HTML format for the invoice data, or can supply a preferred template in which the layout of the invoice data is proscribed by the template. Thus, the system can receive template data 218 and store this data on the database 220. In Figure 6A, the output data mapping process 100 (similar to that described above for the biller) is depicted. Like the biller, it is sometimes desirable to output the invoice data from the system to the payor. If this is so chosen by the payor, the system receives invoice data output format from the payor 102. The system creates a map to translate the network, flat file, format to the preferred output format 104, which is stored on the database 108, and linked to the payor profile 106. BILLER TRANSACTIONS: Once the database 20 is established, a biller 16 submits an invoice to the server system 12. Preferably, the biller sends the invoice in "send-only" mode to the payor. To ensure that the invoice data is accessible to all payor's and is common to the interface 18, a translator is provided which maps the input invoice data into a format appropriate for the network interface 18. Once the invoice data is properly mapped, and stored on the database 28', a payor 14 can now access the invoice. Figure 2 is a more detailed block diagram representation is a more detailed block diagram representation of the bill presentment and payment system of Figure 1 with a focus on bill presentment and invoice settlement. In this Figure and the discussion below, it will be assumed that the biller and payor have previously subscribed to the system and that the database 20 contains the appropriate biller's and payor's data. The biller 16 creates electronic invoice data 28, and submits this invoice data to the system 12, preferably over a conventional public network 60 communication channel. Typically, electronic invoice data is generated by the biller's A/P 48, in an ANSI xl2 (810) format which includes position sensitive data elements (data fields) for payor, invoice number, discount terms, payment terms, quantity, price, etc. However, since the 810 format can differ slightly between billers, the system translates the 810 invoice data into a "common" format that can be used by all payors who subscribe to the system, herein defined as "network format". Preferably, the network format is a "flat file" type data format with associated data fields for each of the data elements supplied in the invoice data. Alternatively, the invoice data format may be comprised of other conventional and/or proprietary formats. To that end, the translator 38 preferably includes a biller format to network format translator 38 A. Of course, the translator 38A could reside locally on the biller's system, or, as shown in the figure, be provided within the server environment. Once translated, the invoice data 28' is stored on the database 20. Once payment is authorized by the payor (described more fully below), the output queue 40 maintains both payment data 72 and remittance data 74. The payment data is forwarded to the biller's bank 66, via a secure private network 62. Once received by the biller's bank, an ACH transmission between a Federal Reserve ACH bank 68, the biller's bank 66 and the payor's bank 70, over an extremely secure ACH network. Essentially, this transactions debits and credits the appropriate accounts, and is understood by those skilled in the art. The remittance data preferably includes the original invoice data, plus any adjudication data that may have been entered by the payor and/or other changes initiated by the payor. Preferably, the remittance data 74 is translated from the network format into the biller's preferred format, as described above, using output translator 38B. The translated remittance data 52 is sent to the biller's A/R system 50, via the public network channel 60. As an example, the remittance data can be translated into an ANSI 820 format, an industry standard which places paid invoice data into predefined data fields, thereby permitting paid invoice data to be entered directly into A/R software packages capable of accepting ANSI 820 format data. Of course, other data translation methodologies can be incorporated, and the ANSI 820 translator is provided only as an exemplary translation routine. System 12 can be appropriately adapted to automatically translate and forward the remittance data into the biller's A/R package 50. Alternatively, system 12 can include a biller outbox (not shown) where invoice data is deposited, and retrieved by the biller on a scheduled and/or opportunistic basis. The biller 16 also preferably includes a biller's administrator 48 who is granted access to the database 20, via an login ID process (not shown), to modify, add and/or delete data from the biller profile 30 and/or dispute rules 32 data modules. Also, the biller's admin can utilize the interface 18 to view and/or purge current invoice data. To that end, the network interface includes a biller's toolkit to permit the biller 48 to view/edit/purge the invoice data 28' sent to payors. These actions are generally constructed as querries 56, and appropriately translated from network HTML instructions to SQL instructions 38D to querry the database 26. Likewise, data output from the database 20 is translated from SQL to HTML 38E. Thus, as will be described below, the interface 18, and more precisely, the biller's network toolkit 44, preferably includes appropriate functional components (using, for example, interface menus, windows and/or dialog boxes) to permit the administrator to access and control these components of the database. Referring briefly to Figure 4, the biller's toolkit 44, provided as part of the network interface 18, generally includes review, select, sort, purge and can generate reports (described below), all with respect to the invoice data 26. It is to be noted that except for subscription and changes to the biller profile and/or dispute rules, the biller does not need to access the server 12. Once submitted, the server system 12 preferably automatically determines the appropriate payor and biller data, based on the data for those billers and payors stored on the database. Thus, the biller is advantageously not required to follow or track an invoice once submitted, but may instead rely upon the profiles and rules established by the biller and payor. The preferred process 230 for invoice presentment is depicted in Figure 7. For clarity, reference numbers for those components of the server 12 and biller 16 described above are omitted. Using conventional and/or proprietary invoice generating computer programs, the biller generates an invoice and sends the invoice, in electronic form, to the system. The system receives the invoice data from the biller 232. Based on the biller identifier (for example, biller's IP address, biller's login ID, etc.) the translation map (previously created) is matched to that biller 234, so that the invoice data is properly translated into the common network format, i.e., flat file format 236. A certain level of information must be present in the invoice data. In other words, the invoice data must contain at least one payor (either defined a priori by assigned number, and stored in the payor profile and biller profile, or as a predefined data stream identifying the payor), at least one invoice stream, and at least one biller identifier data, although other data, for example, amount data, multiple line item account data, etc. Thus, the database querries the translated invoice data to determine if the invoice data has a certain minimum level of information 238. If the invoice data is sufficiently complete, it is stored on the database 240. If not, the invoice data is rejected, and the biller is informed of the deficient invoice data 242. If the server system is adapted with an email message engine, the fact that invoice data now resides on the database could trigger an automatic email be sent to the appropriate payor. More generally, the system could be adapted to inform the payor 244 of outstanding invoices. Once translated, the system links invoice data to the biller and payer, via the profiles 246. PAYOR TRANSACTIONS : Payor transactions, as will be described below, generally include invoice review and payment, and may further include invoice adjudication. Figure 3 depicts is a more detailed block diagram representation of the bill presentment and payment system of Figure 1 with a focus on payor transactions. To establish an effective separation of duties among payors, the payor 14 in Figure 3 depicts a plurality of individuals within the payor organization who have certain access rights to the invoice data. As a general matter, these individuals includes the following actors having defined multiple levels of access to various individuals: invoice review 76, invoice adjudication 78, payment initiation 80 and payment authorization 82. Each are intended to be distinct from an operative standpoint, but such access and control over the invoice data may reside in a single or multiple individuals. Each actor is established by the payor, in the payor profile 34, and each is assigned a certain level of responsibility regarding the invoice. In this example, assume that each actor 76, 78, 80, and 82 has increasing levels of responsibility within the accounts payables hierarchy and the each is assigned the ability to review, adjudicate, initiate payment and authorize payment, respectively. Each of these individuals access the server 12 via the public network 60, and must preferably go through a login identification process 90 to obtain a secure SSL socket 92, to access data on the database 20 (through the firewall 26). Additional individuals on the payor's side are similarly established. For example, a payor's administrator 84 can be established, and that individual can be granted access to the payor profiles and/or access control to view/update/change/edit this data. If the payor so desires the invoice data can be output to the payor's A/P 86. Payors 76, 78, 80 and 82 access the interface 18 to view, adjudicate, initiate and authorize payment of an invoice. To that end, the network interface includes a payor's toolkit 46 to permit the payor to accomplish these tasks. These actions are generally constructed as querries 72, and appropriately translated from network HTML instructions to SQL instructions 38F to querry the database 20. Data output from the database 20 is translated in one of two ways. Either the data is displayed directly as an HTML document, or the invoice data is coupled to a template supplied by the payor. Thus, the database can be adapted with and XML translator 38H and/or template data 381. Data flowing from the database 20 to the interface is appropriately translated from SQL to HTML (XML), and/or coupled to the template data 38G, to display the invoice data 74. Thus, as will be described below, the interface 18, and more precisely, the payor's network toolkit 46, preferably includes appropriate functional components (using, for example, interface menus, windows and/or dialog boxes) to permit the administrator to access and control these components of the database. If the payor has established a translation map to translate the data into the payor's A/P package, the system can be appropriately adapted with the translator 38J to accomplish this task. Referring briefly to Figure 4, the payor's toolkit 46, provided as part of the network interface 18, generally includes review, select, sort, adjudicate, initiate payment, authorize payment and can generate reports (described below), all with respect to the invoice data 26. Once a payor has accomplished their task with respect to the invoice data, the present invention also preferably includes email massage 88 capability. For example, if the invoice has been reviewed by actor 76, the invoice status flag 42 is updated to reflect this individual's activity, and an email message 88 is forwarded (preferably automatically) by the system to the next payor in the chain, i.e. actor 78, indicating that invoice data is awaiting further action. The email message can be sent via the public network 60. Email addresses for the payors 76, 78, 80 and 82 can be included as part of the payor profile 34 and access control 36, established by the payor 14, described above. Figures 8A-8E are flowcharts depicting of the invoice review, invoice adjudication, invoice payment initiation, and invoice payment authorization processes of the bill presentment and payment system of the present invention. Figure 8 A is a generalized flowchart 300, that preferably applies to the payors 76, 78, 80 and 82, described above, and are set out as payor n. Payor n logs on to the network server 302. That payor requests access to the invoice data 304, using the network interface. The system querries the access control logic to determine if that payor has the requested access 306. If not access to the invoice data is denied 308. If access is granted, payor n will attempt to perform some action on the invoice data (using, for example, the payor's toolkit depicted in Figure 4) 310. The system querries the access control logic and payor profile to determine if the given payer has been granted the requested level of access to perform the stated task 312. If the requested action is nit permitted for that payor, the request is denied for that action 314. If the action is permitted 316, then the payor will perform the action, as shown in the examples of Figures 8B-8E. Figure 8B is an exemplary flowchart 320 for invoice review 322. The system first determines the invoice format for the payor 324 that is displayed on the network interface, as specified in the payor profile. If the default view is HTML, the system will generate the invoice data in HTML format for display 326. If the payor has defined a template, the system will couple the invoice data with the template 328, and display both to the payor. The payor can access the payor's toolkit to sort invoice(s) for review 330. The sort can occur across multiple invoices, across payors, or by performed within a single invoice by date, amount, item number, etc. These are, of course, just examples of the various sort routines that could be offered to the payor. Once the review is completed, the invoice status flag is updated 332, and, if the system is so adapted, a message (e.g., email message) is forwarded to the next payor, indicating the current status of the invoice 334. Figure 8C depicts an exemplary flowchart 340 of invoice adjudication 342 performed by the payor. The invoice data is first displayed 344, either in HTML format or payor-specified template format, as described above. The system querries the database, and particularly the payor profile, to determine the specific dispute rules and reason codes permitted for adjudication for that payor 346. The system creates additional data fields in the invoice data table to insert the dispute rules 348. These additional data fields can comprise, for example, additional columnar data, drill-down menus, etc. The payor now has access to these dispute rules (and is thereby limited to the specified adjudication rules defined by the biller), which can be used to adjudicate an invoice 350. As noted above, invoice adjudication generally includes 1) general invoice adjustment, 2) price adjustment, 3) quantity adjustment, and/or 4) line item adjustment. The reason codes, defined by the biller, provide the descriptive aspect to one or more of these adjudication dispute rules. The payor will also select an appropriate reason code. Upon completion of this task, the system generates remittance data 352, and stores this data on the database. The remittance data (the output process of which is described above) preferably comprises both the original invoice data, plus any and all adjudication information. In this way, the biller remains fully apprised of both the existence and reason for an adjudicated invoice. The system updates the invoice status flag, indicating that this invoice has been adjudicated 356, and a message, if applicable, is forwarded to the next payor, along with an indication of the status of the invoice 358. It is often desirable to separate out the duty of payment initiation and actual invoice payment. To this end, and referring first to Figure 8D, an exemplary flowchart 360 of invoice payment initiation 362. As before, the invoice data is displayed 364. As part of the invoice data, payment methods are provided (described above), as defined by the payor. The payor is permitted access to the payment methods 366, for a particular invoice. The payor selects a payment method 368. Upon selection, the system updates the invoice status flag 370, and stores the updated invoice data on the database 372. It should be noted that part of the payment selection process preferably includes payor- selectable settlement dates. Thus, the payor can control accounts payable by specifying dates for settlement. Also, discount terms offered by the biller can be tied to a specific day, and thus, both biller and payor can maximize the benefits of early and/or timely payment. If appropriately adapted, the system forwards a message to the next payor, 374 to authorize payment. Figure 8E depicts an exemplary flowchart 380 of invoice payment authorization and settlement 382. Initially, the payor reviews the actions performed in payment initiation, typically to verify the payment method, settlement date, and, if appropriate, any adjudication information (not shown). Once verified, the payor stores the invoice data in the output queue 384. This invoice data now has the complete original invoice data, payment data (including, for example, settlement date, payment method, payment amount, account data, invoice number, etc.) and remittance data. Once placed in the output queue, no further action by the payor is required. At the settlement date, the payment data is extrapolated and sent to the biller's bank 386 (See Figure 2). If output data is desired, the system can also generate remittance data back to the biller 388 and invoice data back to the payor 390. Accordingly, the system translates the remittance data to the biller's A/R format (described above) 392, and the invoice data to the payor's A/P format 394. The status flag for that invoice is updated as being settled 396. EXEMPLARY NETWORK INTERFACE Network interface 18 converts the format of invoice data and commands received from the payor and biller (via the network) into formats suitable for processing and storage in the database by the and/or storage in computer-readable memory. Data and/or commands may arrive at the server system 12 in the following forms: comma delimited data fields within so-called "flat" files, textually-based data objects, HTML and/or XML commands, etc. The network interface preferably includes appropriate functionality to permit billers to present bills, and for payors to view, sort, adjudicate, and authorize payment. In the most preferred embodiment, the network interface is presented to billers and payors in a conventional HTML format, which includes appropriate drill-down data fields to accomplish the stated functionality. Further, multiple screens are provided which permit billers and payors access to the above-described features. By way of example, several shots of the functionality of the network interface 18 are depicted in Figures 5A-5G. In Figure 5 A, a screen shot 400 of the toolkit provided to the payor. In this example, payors can click on unpaid invoices 402, and unpaid accounts are displayed. In the example shown, the invoices are presented by biller 404, PO number 406, invoice number 408, due date 410, invoice status 412 amount due 414 and amount authorized for payment 418. Payors can extract further information for any of the invoices, or sort by any of the above-mentioned data fields, using extract/sort functionality 416. This example shows that payment has been authorized 412 for an invoice and payment has been approved 420 for another. Additional functionality 422 is provided, which is described in greater detail below. Figure 5B represents a screen shot of the interface for invoice adjudication 430. By selecting an invoice, payors can click a callout button to adjust the invoice 440. An adjustment window 432 appears, and payors are permitted to enter an adjustment amount 434 and a reason code 436 for that adjustment. Additional data 444 is displayed showing the details of both amount, discount and amount authorized. The payor can email the biller 438, to indicate an adjudicated invoice, or to inform the biller of unstated reasons for invoice adjustment. Figure 5C depicts a screen shot of the interface 450, this time from a perspective of separation of duties and workflow management among payors. In this screen, payors having various access can perform approval of invoice data. For example, as shown in 412, this payor is permitted to click on the invoice status field to changes the status from "invoice unapproved" to "invoice approved", by clicking on the "approve" field 452. This payor could also "approve all" of the outstanding, as indicated at 454. For account management, reports can be generated directly online. For example, as shown in Figure 5D, this screen shot 460 is generated for the payor to indicate the status of paid invoices for a particular biller. The payor can, at a glance, check the payment type 462, settlement date 468, the amount 464 and the check number 466. As described above, the system can be adapted to generate output data to both the biller and payor, the biller receiving remittance data, and the payor receiving invoice data. In the screen shot 470 of Figure 5E, payors can elect to have invoice data exported to the payors A/P package. The export options can include, for example, unapproved invoices 472, or settled invoices which generated payment 474. Either export can include a time window option 476, to specify the dates of interest. As described above, payors and billers can access the database to change biller/payor profiles. In the screen shot 480 of Figure 5F, a payor (with appropriate access) can edit/update the information contained in the payor profile. Another feature of the present invention is the generation of reports designed to assist both billers and payors to manage invoices through the system. The screen shot 490 of Figure 5G depicts a cashflow forecasting report 492 that can be generated by the system for the payor. In this example, the report can provide the payor with updated invoice status, payment history, discounts from a particular biller, payor administration status, etc. Of course, other reporting features and functions could be included without departing from the scope of the present invention, and Figure 5G is provided only as an example. Modifications to the present invention are possible. For example, preferably, each of the above-presented functional components of the payor, biller and transaction server are embodied as one or more distributed computer program processes running on one or more conventional general purpose computers networked together by conventional networking hardware and software. Most preferably, each of these functional components is embodied by running distributed computer program processes (e.g., generated using "full-scale" relational database engines such as IBM DB2™, SQLServer™, Oracle 7.3™ or Oracle 8.0™ database managers) on networked computer systems (e.g., comprising mainframe and/or symmetrically or massively parallel computing systems such as the IBM SB2™ or HP™ 9000 computer systems) including appropriate mass storage, networking, and other hardware and software for permitting these functional components to achieve the stated function. Preferably, these computer systems are geographically distributed and connected together via appropriate wide- and local-area network hardware and software. Alternatively, the aforesaid functional components may be embodied by a plurality of separate computer processes (e.g., generated via dBase™, Xbase™, MSAccess™ or other "flat file" type database management systems or products) running on IBM-type, Intel Pentium™ or RISC microprocessor-based personal computers networked together via conventional networking hardware and software and including such other additional conventional hardware and software as is necessary to permit these functional components to achieve the stated functionalities. In this alternative configuration, since such personal computers typically are unable to run full-scale relational database engines of the types presented above, a non-relational flat file "table" (not shown) may be included in at least one of the networked personal computers to represent at least portions of the invoice data. Preferably, these personal computers run the Unix, Microsoft Windows NT™ or Windows 98™ or Windows 2000™ operating systems. The aforesaid functional components of system 100 may also be comprised by a combination of the above two configurations (e.g., by computer program processes running on a combination of personal computers, RISC systems, mainframes, symmetric or parallel computer systems, and/or other appropriate hardware and software, networked together via appropriate wide and local area network hardware and software). Other modifications are also possible. For example, the present invention may be part of a larger computerized bill presentment and payment system comprising multi- database or multi-computer systems or "warehouses" wherein other data types, processing systems (e.g., transaction, financial, administrative, statistical, data extracting and auditing, data transmission/reception, and/or accounting support and service systems), and/or storage methodologies may be used in conjunction with those of the present invention to achieve an overall information management, processing, storage, search, statistical and retrieval solution for a particular biller organization, payor organization, or payment system, and/or for a cooperative or network of such systems. Still other modifications are possible. For example, the system of Figures 1 and 2 can be modified with output data to the biller that indicates that an invoice has been adjudicated (and the reasons therefore) but before the invoice is approved for payment. With this alteration, the server system is preferably adapted to automatically forward back to the biller a disputed or adjusted invoice for biller's review, and thereby immediately notifying a biller of a potential problem, and permitting the biller to prevent further authorization by the payor. After review, the biller can resubmit the adjusted invoice, and an additional data field can be provided to indicate biller's approval/disapproval of an adjusted invoice. The process for payment authorization can resume, as described above. Other modifications will become apparent to those skilled in the art, and all such modifications are deemed within the spirit and scope of the present invention, only as may be limited by the appended claims.

Claims

CLAIMS 1. A server-based bill presentment and payment system, comprising: a network server; at least one biller and at least one payor in communication with said server; a database containing data modules comprising a biller profile, a payor profile, dispute rules and access control; said server operable to receive invoice data from said biller, translate said invoice data into a selected format, and store said invoice data on said database; said server further operable to permit said payor to at least adjudicate said invoice data based on said dispute rules.

2. A network transaction system comprising in computer-readable memory: a network server, said server comprising a database; said database comprising data modules comprising at least one biller profile of at least one biller, at least one payor profile of at least one payor, dispute rules and access control; a mapping engine receiving invoice data from said biller, translating said invoice data into a selected format, and storing said invoice data on said database; and an adjudication engine permitting said payor to adjudicate said invoice data based on said dispute rules.

3. A system as claimed in claim 1 , wherein said server is operable to permit said payor to adjudicate said invoice data to reflect a manner of adjudication selected from the group consisting of: discounts, price terms, quantity of goods received, and more than one of the foregoing manners of adjudication in combination.

4. A system as claimed in claim 1, wherein said server is further operable to transmit to said biller data relating to invoice adjudication by said payor.

5. A system as claimed in either of claims 1 or 2, wherein said server is capable of connection to a network, and wherein said biller and said payor comprise hardware and software for connecting to said server via said network.

6. A system as claimed in claim 5, wherein said network is selected from the group consisting of: local area network, wide area network, internet, intranet, extranet, a TCP/IP-based network, a wireless network, an e-mail based network of e-mail transmitters and receivers, a modem-based telephonic network, and an interactive telephonic network accessible to users by telephone.

7. A system as claimed in claim 6, wherein said server is further operable to perform an action via said network selected from the group consisting of: transmitting to said payor said invoice data, adjudicating said invoice data, allowing said payor to pay said invoice data, more than one of the foregoing actions in combination.

8. A system as claimed in claim 6, wherein said server further comprises computer- readable memory receiving and storing data and commands from said biller and said payor via said network.

9. A system as claimed in claim 6, wherein said server is further operable to transmit to and receive from said biller and said payor data relating to said adjudication via said network.

10. A system as claimed in claim 6, wherein said server further comprises security to restrict unauthorized access to said database.

11. A system as claimed in either of claims 1 or 2, wherein said biller profile comprises data selected from the group consisting of: biller name, bank account, routing transit number, account number, biller administrator, and more than one of the foregoing data in combination.

12. A system as claimed in either of claims 1 or 2, wherein said payor profile comprises data selected from the group consisting of: payor name, payment option data, contact data, user identification, password, credit card number, automated clearing house credit data, wire transfer routing data, authorized debit data, and more than one of the foregoing data in combination.

13. A system as claimed in either of claims 1 or 2, wherein said invoice data comprises at least one payor, at least one invoice stream, and at least one biller identifier.

14. A system as claimed in either of claims 1 or 2, wherein said access control comprises a list of users, including a user identification and password for each user.

15. A system as claimed in either of claims 1 or 2, wherein said access control is operable to govern which users can perform actions selected from the group consisting of: changing said payor profile, reviewing said invoice data, adjudicating said invoice data, and more than one of the foregoing actions in combination.

16. A system as claimed in either of claims 1 or 2, further comprising password- protected mailboxes, and wherein said access control is operable to transmit said invoice data along a predetermined chain of users using said mailboxes.

17. A system as claimed in claim 1, wherein said server further comprises a data translator mapping said invoice data received from said biller to a predetermined format for storage on said database, and mapping said invoice data stored on said database into a predetermined format for transmission to said payor and said biller.

18. A system as claimed in either of claims 2 or 17, wherein the format of said invoice data received from said biller and the format for transmission to said payor and said biller are selected from the group consisting of: XI 2 EDI, ANSI 810, ANSI 820, UN/EDIFACT, NACHA, NACHA with X 12, NACHA with UN/EDIFACT, a print image file, an SQL-based data source, HTML, an extended markup language, a paper- based payment instrument, a check, a draft, a payment format, SWIFT, FedWire, PAYORD, a human-readable format and more than one of the foregoing formats in combination.

19. A system as claimed in either of claims 1 or 2, further comprising a biller's toolkit permitting said biller to view, review, select, sort, edit, purge, and generate reports from said invoice data.

20. A system as claimed in either of claims 1 or 2, further comprising a payor's toolkit permitting said payor to view, review, select, sort, adjudicate, initiate payment, authorize payment, select settlement date for payment, and generate reports from said invoice data.

21. A system as claimed in either of claims 1 or 2, wherein said server is further operable to provide a payment instruction for the settlement of said invoice.

22. A system as claimed in either of claims 1 or 2, wherein said data modules are linked to one another to establish a trading community of billers and payors.

23. A system as claimed in either of claims 1 or 2, wherein said database is further adapted to link said biller profile and said payor profile based on a biller/payor relationship therebetween.

24. A system as claimed in either of claims 1 or 2, wherein said server is operable to permit said dispute rules to be established on a payor-by-payor basis or globally.

25. A system as claimed in claim 2, wherein said adjudication engine is operable to permit said payor to adjudicate said invoice data to reflect a manner of adjudication selected from the group consisting of: discounts, price terms, quantity of goods received, and more than one of the foregoing manners of adjudication in combination.

26. The network transaction system of claim 2, wherein said mapping engine comprises a data translator mapping said invoice data received from said biller to a predetermined format for storage on said database, and mapping said invoice data stored on said database into a predetermined format for transmission to said payor and said biller.

27. A method for business-to-business bill payment and presentment, said method comprising the steps of: loading into computer-readable memory a database containing data modules comprising at least one biller profile of at least one biller, at least one payor profile of at least one payor, dispute rules and access control; receiving invoice data from said biller, translating said invoice data into a selected format, and storing said invoice data on said database; and permitting said payor to adjudicate said invoice data based on said dispute rules.

28. A method as claimed in claim 27, wherein said step of permitting said payor to adjudicate said invoice further comprises a manner of adjudication selected from the group consisting of: discounts, price terms, quantity of goods received, and more than one of the foregoing manners of adjudication in combination.

29. A method as claimed in claim 27, wherein said data modules and said invoice data are accessible to said biller and said payor via a network, and wherein said biller and said payor comprise hardware and software for connecting to said system via said network.

30. A method as claimed in claim 29, wherein said network is selected from the group consisting of: local area network, wide area network, internet, intranet, extranet, a TCP/IP-based network, a wireless network, an e-mail based network of e-mail transmitters and receivers, a modem-based telephonic network, and an interactive telephonic network accessible to users by telephone.

31. A method as claimed in claim 30, further comprising the steps of transmitting to said payor data relating to said adjudication via said network.

32. A method as claimed in claim 30, further comprising the step of providing security to restrict unauthorized access to said database.

33. A method as claimed in claim 27, wherein said biller profile comprises data selected from the group consisting of: biller name, bank account, routing transit number, account number, biller administrator, and more than one of the foregoing data in combination.

34. A method as claimed in claim 27, wherein said payor profile comprises data selected from the group consisting of: payor name, payment option data, contact data, user identification, password, credit card number, automated clearing house credit data, wire transfer routing data, authorized debit data, and more than one of the foregoing data in combination.

35. A method as claimed in claim 27, wherein said invoice data comprises at least one payor, at least one invoice stream, and at least one biller identifier.

36. A method as claimed in claim 27, wherein said access control comprises a list of users, including a user identification and password for each user.

37. A method as claimed in claim 27, wherein said access control is operable to govern which users can perform actions selected from the group consisting of: changing said payor profile, reviewing said invoice data, adjudicating said invoice data, and more than one of the foregoing actions in combination.

38. A method as claimed in claim 27, further comprising the steps of mapping said invoice data received from said biller to a predetermined format for storage on said database, and mapping said invoice data stored on said database into a predetermined format for transmission to said payor and said biller.

39. A method as claimed in claim 38, wherein the format of said invoice data received from said biller and the format for transmission to said payor and said biller are selected from the group consisting of: X12 EDI, ANSI 810, ANSI 820, UN/EDIFACT, NACHA, NACHA with X12, NACHA with UN/EDIFACT, a print image file, an SQL- based data source, HTML, an extended markup language, a paper-based payment instrument, a check, a draft, a payment format, SWIFT, FedWire, PAYORD, a human- readable format and more than one of the foregoing formats in combination.

40. A method as claimed in claim 27, further comprising the step of permitting said biller to view, review, select, sort, edit, purge, and generate reports from said invoice data.

41. A method as claimed in claim 27, further comprising the step of permitting said payor to view, review, select, sort, adjudicate, initiate payment, authorize payment, select settlement method and date for payment, and generate reports from said invoice data.

42. A method as claimed in claim 27, further comprising the step of providing a payment instruction for the settlement of said invoice data.

43. A method as claimed in claim 42, further comprising the step of outputting said payment instruction to said biller's bank.

44. A method as claimed in claim 42, further comprising the step of initiating an automated clearing house transaction between said biller's bank, said payor's bank, and a Federal Reserve automated clearing house bank.

45. A method as claimed in claim 42, wherein said payment instruction comprises a payment method and settlement date selectable by said payor.

46. A method as claimed in claim 42, further comprising the step of transmitting remittance data to said biller and invoice data to said payor based on said payment instruction.

47. A method as claimed in claim 42, further comprising the step of mapping said remittance data and said payment instruction into a predetermined format.

48. A method as claimed in claim 47, further comprising the steps of inputting and outputting said remittance data and said payment instruction in a format selected from the group consisting of: X12 EDI, ANSI 810, ANSI 820, UN/EDIFACT, NACHA, NACHA with XI 2, NACHA with UN/EDIFACT, a print image file, an SQL-based data source, HTML, an extended markup language, a paper-based payment instrument, a check, a draft, a payment format, SWIFT, FedWire, PAYORD, a human-readable format and one or more of the foregoing formats alone or in combination.

49. A method as claimed in claim 42, further comprising the steps of transmitting data to said biller indicating said invoice data has been adjudicated prior to providing said payment instruction, permitting said biller to prevent further authorization by said payor and readjusting said invoice data, and resubmitting said readjusted invoice data to said payor.