Patent Publication Number: US-2004044951-A1

Title: Method for integration and reconciliation of electronic documents

Description:
[0001] This application is related to and claims priority from U.S. Provisional Patent Application S/No. 60/367,519, filed on Mar. 25, 2002. U.S. Provisional Patent Application S/No. 60/367,519 is incorporated by reference herein. 
    
    
     
       FIELD OF THE INVENTION  
       [0002] The present invention relates to a method for integrating and reconciling electronic documents. More specifically, the invention relates to a method for integrating and reconciling electronic representations of commercial documents not created within an electronic marketplace environment in which they are used, so that buyers and sellers in the marketplace environment have the ability to review, dispute, and resolve disputes, as well as execute payments between trading partners outside the marketplace environment.  
       BACKGROUND OF THE INVENTION  
       [0003] Previous methods of integration and reconciliation have not allowed electronic representations of commercial documents created within the enterprise environment, to be integrated and reconciled in a marketplace or third party hosted environment. It is therefore desired to have a method of integration and reconciliation that allows integration and reconciliation of commercial documents not created within the electronic marketplace environment in which they are used.  
       [0004] Previous methods of integration and reconciliation have also not accommodated asynchronous (time-independent) integration and reconciliation of commercial documents. It is therefore desired to have a method of integration and reconciliation allowing for asynchronous integration and reconciliation of commercial documents.  
       [0005] Prior integration and reconciliation methods have not made it possible to extend an invoice management and payment application to buyers and sellers not otherwise interacting within a marketplace environment while not altering transactions taking place in the marketplace environment. It is therefore desired to have a method of integration and reconciliation allowing extension of a invoice management and payment application to buyers and sellers not otherwise interacting with a marketplace environment while not altering transactions taking place in the marketplace environment.  
       [0006] Previous methods of integration and reconciliation have not allowed buyers and sellers using a marketplace environment the ability to review, dispute, and resolve disputes, approve as well as pay and remit with trading partners not in the marketplace environment. It is therefore desired to have a method of integration and reconciliation allowing buyers and sellers using a marketplace environment the ability to review, dispute, and resolve disputes, approve as well as pay and remit with trading partners not in the marketplace environment.  
       [0007] Prior methods of integrating external documents into a marketplace environment have been observed to disrupt validation of documents already within the marketplace environment. External documents are documents produced outside the marketplace environment in which the documents are used for integration and reconciliation. It is thus desired to have a method of integrating external documents into a marketplace environment that does not disrupt validation of documents already within the marketplace environment.  
       [0008] It is thus desired to have a method making it possible for buyers and sellers not otherwise involved in a marketplace environment to conduct business and integrate with an invoice management and payment application. It is also desired to have a method having broad applicability in enabling commercial documents from a wide variety of disparate sources, including external buying and sourcing applications, use-specific clients, such as spreadsheets, designed to prepare and transmit commercial documents, and marketplace environments. It is additionally desired to have a method to integrate such sources with an invoice management and payment application without requiring the sources to integrate directly or synchronously with a payment application.  
       SUMMARY OF THE INVENTION  
       [0009] The present invention relates to a method for integrating and reconciling electronic representations of commercial documents not created within the electronic marketplace environment in which they are used. The method allows buyers and sellers in the marketplace environment to have the ability to review, dispute, and resolve disputes, approve as well as pay and remit with trading partners outside the marketplace environment, in a third party hosted environment. Additionally, embodiments of the present invention provide methods of integration and reconciliation for electronic representations of commercial documents created within the enterprise environment, to be integrated and reconciled in a marketplace or third party hosted environment.  
       [0010] The present method enables invoices from sellers outside the marketplace environment to be used for payment with purchase orders created within the marketplace environment. The method also allows purchase orders from buyers outside the marketplace environment to be used for payment with invoices created within the marketplace environment. Additionally, the method provides for integration of purchase orders and invoices not created within a marketplace environment for use with an invoice management and payment application. The method also enables integration of external document sources without affecting the flow of documents in a marketplace environment. Finally, the method allows for convenient review and editing of documents entered asynchronously or incorrectly that are populated to suspense tables in an invoice management and payment application.  
       [0011] An embodiment of the invention is directed to a method for integrating documents. This method includes, obtaining an order document, for example, a purchase order (PO), from a purchaser enterprise system and writing this order document into an electronic format; obtaining an invoice document from a supplier enterprise system and writing this invoice document into an electronic format; and reconciling the order document and the invoice document in a third party hosted system. The order and invoice documents are typically created outside of a marketplace environment, while the reconciling is within a marketplace environment. This reconciling is typically performed electronically.  
       [0012] Another embodiment is directed to a system for integrating documents having a storage device and a processor. The processor is programmed to maintain in the storage device a database of at least one representation corresponding to an order document from a purchaser enterprise system; maintain in the storage device a database of at least one representation corresponding to an invoice document from a supplier enterprise system; and reconcile the at least one representation of the at least one order document and the at least one representation of the invoice document. This reconciliation results in an approval process where a payment process is invoked or a dispute process is invoked. In this dispute process, the issuer of the invoice document and the issuer of the order document or intended recipient of the invoice are placed into communication with each other, to ultimately move the invoice toward a payment mechanism, for example, an electronic settlement.  
       [0013] Another embodiment is directed to a computer-usable storage medium having a computer program embodied thereon for causing a suitably programmed system to integrate documents in a marketplace environment by performing the following steps when such program is executed on the system. These steps include maintaining a database of at least one representation corresponding to an order document from a purchaser enterprise system; maintaining a database of at least one representation corresponding to an invoice document from a supplier enterprise system; reconciling the at least one representation of the at least one order document and the at least one representation of the invoice document; and invoking an approval process or a dispute mechanism in response to the reconciliation of the at least one representation of the at least one order document and the at least one representation of the invoice document.  
       [0014] Another embodiment is directed to creating an invoice. This method includes obtaining at least one order document including at least one line item; electronically selecting at least one line item from the at least one order document to be used on the invoice; and electronically transferring the at least one line item into an invoice template. The at least one order document is for example, a purchase order (PO).  
       [0015] Another embodiment is directed to a system for integrating documents having a storage device and a processor. The processor is programmed to, maintain in the storage device a representation corresponding to at least one order document including at least one line item; select at least one line item from the at least one order document to be used on the invoice; and transfer the at least one line item into an invoice template.  
       [0016] Another embodiment is directed to a computer-usable storage medium having a computer program embodied thereon for causing a suitably programmed system to create an invoice document in a marketplace environment by performing the following steps when such program is executed on the system. These steps include, maintaining a representation corresponding to at least one order document including at least one line item; selecting at least one line item from the at least one order document to be used on said invoice; and transferring the at least one line item into an invoice template. 
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0017] Attention is now directed to the attached drawings, wherein like reference numerals indicate corresponding or like components. In the drawings:  
     [0018]FIG. 1 is a flowchart showing a system architecture and environment in accordance with the present invention;  
     [0019]FIG. 2 is a flowchart showing a method for integrating and reconciling electronic documents in accordance with the present invention;  
     [0020]FIG. 3 is a diagram of an embodiment of the present invention in use in an exemplary application;  
     [0021]FIG. 4 is a flowchart showing an embodiment of the invention;  
     [0022]FIG. 5 is a flowchart of the approval process of FIG. 4;  
     [0023]FIG. 6 is a flowchart detailing a process of an embodiment of the invention; and  
     [0024] FIGS.  7 - 15  are screen shots in accordance with examples of embodiments of the invention. 
    
    
     DETAILED DESCRIPTION OF THE DRAWINGS  
     [0025] The present invention relates to a process of integrating and reconciling commercial documents not created in a marketplace environment into an invoice management and payment application connected electronically to the marketplace environment. Embodiments of the invention are directed to web based matching and reconciliation between disparate, typically two, accounting systems, and commercial documents produced therefrom. These commercial documents can include, for example, purchase orders (PO&#39;s) and invoices.  
     [0026] Commercial documents are documents used in commercial sales and include such documents as purchase orders (PO&#39;s), invoices, receipts, order responses, purchase order acknowledgements, purchase order change requests, purchase order change acknowledgements, purchase order status requests, advance ship notices, advance ship notice acknowledgements, advance ship responses, change order requests, status checks, price/availability checks, remittance advice, electronic funds transfers, and forecasts. Documents, electronic documents, or electronic representations of documents refer to information stored on, or accessible via, a computer. This information may be a computer program, a text file, a Web page, or other computer-readable media.  
     [0027] Marketplace or marketplace environment refers to an electronic system that facilitates the purchase and sale of goods and services, principally through the creation and/or transmission of electronic documents between a buyer and a supplier, and subsequently into an invoice management and payment application. Invoice management application refers to an electronic means of reviewing electronic invoices for the purpose of review, dispute, dispute resolution, approval, payment and settlement. Payment application refers to an electronic means of reviewing electronic documents for the purpose of review, payment, and settlement of accounts within a marketplace environment.  
     [0028] Integration or integrating is a process by which electronic documents created either in the marketplace environment or outside the marketplace environment are evaluated and accepted, suspended, or rejected for processing by the marketplace, invoice management and payment applications. An electronic document that has been accepted for processing by an invoice management or payment application connected to the marketplace environment is integrated into an invoice management or payment application. The goal in integration is the creation and maintenance of a complete and consistent document set that 1) captures the essential features of the contract between buyer and seller, and 2) contains such supplemental information as is necessary to make the documents manageable by the buying application, selling application, and accounting systems within the buyer and seller. Selling application is any software that assists a seller in the offering of goods and services for sale by presenting content and by receiving and processing electronic documents received from the buying application of a buyer. Content refers to text, images, other media representations, and combinations thereof, containing features, specifications, and pricing of the product, service, or both, offered for sale.  
     [0029] Reconciliation or reconciling is a process by which complementary electronic documents are reviewed at a detailed level for compliance according to negotiated terms between seller and buyer. For example, the reconciliation process may include, but is not restricted to, line item part numbers match, where match refers to having values within agreed tolerances, line item quantities match, line item units of measure match, and line item prices match.  
     [0030] The method makes it possible to extend an invoice management and payment application connected to a marketplace environment to buyers and sellers outside the marketplace environment while not altering transactions taking place within the marketplace environment. The method may be used to offer buyers and sellers in the marketplace environment the ability to review, dispute, and resolve disputes, as well as pay and remit with trading partners outside the marketplace environment. A buyer is a business or individual that purchases, or desires to purchase, goods, equipment, or services from another company or individual. A seller or supplier is a business or individual that supplies, or desires to supply, goods, equipment, or services to another company or individual.  
     [0031] “Using the marketplace environment,” “in the marketplace environment,” or “in-marketplace” refers to events and entities directly participating in the marketplace environment such that an electronic document is generated within the marketplace environment. A buyer can be said to be “in the marketplace” if they use either a buying application to conduct business or the marketplace environment to route electronic documents. “In-marketplace” is meaningful to the process of integration to a payment application because in-marketplace electronic documents carry identifiers such as buyer and seller identification assigned in a buying application and selling application. If in-marketplace, then this information is already available to the payment application.  
     [0032] “Outside the marketplace environment” or “out-of-marketplace” refers to events and entities not directly participating in the marketplace environment such that an electronic document is not generated within the marketplace environment. A buyer outside the marketplace environment will not use either a buying application or the marketplace environment to route electronic documents. For such a buyer outside the marketplace environment, the only contact with the marketplace environment is through an invoice management or payment application. For out-of-marketplace, an electronic document is stored until the matching complementary electronic document, for example the invoice which corresponds to a particular purchase order, appears for integration, until which point as there is not sufficient information for the integration to take place. Thus, in-marketplace electronic documents are integrated immediately, whereas out-of-marketplace documents are stored until a complementary electronic document is matched and then integrated.  
     [0033] Although the method was developed on an Oracle® database running on Sun® E450 server hardware and EMC® Symmetrix® disk hardware running the Solaris® operating system, other compatible systems may be used. The software for the present method was developed using the Java programming language, but other languages may be used. FIG. 1 indicates an appropriate system architecture and environment for the present method.  
     [0034] In the present method, users of a buying application create purchase orders that are routed via the marketplace from the buying application to sellers, who fulfill the orders  1 , FIG. 1. Buying application is any software that assists a buyer in the procurement of goods and services by creating electronic documents and then electronically transmitting the electronic documents from the buying application to sellers, who receive and process the electronic documents.  
     [0035] Sellers deliver invoices  2 , using existing EDI software, or by using either a web application or template upload application. An invoice is a bill issued by a business or individual that has or will have provided products, services, or both to a customer. EDI software is any software that is used for the purpose of creating, transmitting, routing, receiving, or translating documents that conform to the IEEE x.12 specification for electronic documents interchange.  
     [0036] Purchase order documents are copied from the buying application to the invoice management and payment application via a process known as purchase order push (POP). A purchase order, or PO, is an authorization for a supplier to ship products at a specified price, and which generally becomes a legally binding contract once the supplier accepts it. Purchase order documents can be transferred via a POP from the buying application at any time, either synchronously or asynchronously. Such documents are stored in a database table known as the payment PO table within the invoice management and payment application,  3 .  
     [0037] Invoice documents are captured in several different input formats. Each invoice document submitted must contain a PO number, and if a PO corresponding to the PO number on the invoice can be found in the payment PO table, then the invoice will be populated into a database table termed the payment invoice table for later reconciliation, payment, and settlement via the invoice management and payment application,  4 .  
     [0038] If no corresponding PO can be found, then the invoice is stored in a database suspense table where it is stored until a matching PO is obtained,  5 .  
     [0039] A matching PO may be obtained via a POP from the buying application, extracted from the transaction event collector or other document-tracking utility in the marketplace environment, or submitted independently of the buying application,  6 .  
     [0040] When a PO, invoice, receipt, or other document is submitted (each document termed a submitted document) from outside the marketplace environment, an independent reconciliation process matches the submitted document to its complement (for example, invoice for PO, PO for invoice, and PO for receipt or other document) residing in the payment application processing tables,  7 .  
     [0041] If a matching complementary document is found, the submitted document is populated to the appropriate payment table for later reconciliation, payment, and settlement in the payment application,  8 . Complementary documents or complementary electronic documents are a set of documents, which must be viewed together in order to complete a transaction for accounting purposes. For example, regarding an invoice which corresponds to a purchase order for a particular transaction, the invoice and purchase order are complementary documents.  
     [0042] If no corresponding complementary document can be found, then the submitted document is stored in a database suspense table until a matching complementary document is obtained,  9 .  
     [0043] Each reconciliation process can run synchronously (with the arrival of a new PO or invoice document from any source) or asynchronously (via batch or cron job) to try to match documents in advance of migrating matching documents to their respective tables. A cron job means setting a specific action or series of actions to take place at a specific time, or periodically at a specifically designated interval.  
     [0044] When the matching process links an invoice, receipt, or other document to a matching PO, the matched document is migrated from the suspense table to its proper payment document table for processing by the payment application,  10 .  
     [0045] Additional documents such as receipts are added to the payment application by extending the model. For example, receipt documents are also captured from their various input formats. Each receipt submitted must contain a PO number, and if a PO corresponding to the PO number on the receipt can be found in the payment application PO table, then the receipt will be populated into a database table for later reconciliation, payment, and settlement in the payment application,  11 .  
     [0046] If no corresponding PO can be found, then the receipt is stored in a database suspense table until a matching PO is obtained,  12 .  
     [0047] Documents held in suspense tables for payment application documents can be made available for editing by the producer of the document in suspense within the payment application, with the appropriate reconciliation process triggered or run batchwise following the completion of editing of the suspensed document.  
     [0048]FIG. 3 shows an exemplary system, on which embodiments of the invention can be performed. Typically, the embodiments described herein are employed with a wide area network (WAN), for example, the Internet  100 . Connecting to the Internet  100 , for example are a computing device  102  (or devices) of a buyer (B), with one or more processors or microprocessors, this computing device typically being, a server, multimedia personal computer (for example, Pentium® based), workstation, or the like. Also connected to the Internet  100  are computing devices  104   a ,  104   b ,  104   n  of Sellers (S 1 -S n -representative of multiple sellers on the network). These computing devices  104   a - 104   n  are in accordance with those detailed immediately above.  
     [0049] A host server (H)  106  or third party server (with an address of www.abc.com, for description purposes, at block  107 ), or other similar computing device (similar to that detailed above), that performs embodiments of the present invention, as detailed herein, connects to the Internet  100 . This server  106 , for example, includes one or more processors or microprocessors, and also includes (internally or externally) structure, for example, storage media, for supporting databases, for example, for purchase orders  108  and invoices  109  (shown outside of the server  106  for emphasis).  
     [0050]FIG. 4 details a flowchart of an embodiment of the present invention. Initially, a database for purchase orders (POs)  108  (FIG. 3) is created, at block  202 , and a database for invoices  109  (FIG. 3) is created, at block  204 . These databases are typically created independently of each other, however, as detailed below, there are instances when an invoice will be created directly as result of a PO entering the PO database, here, for example, from the buyer&#39;s computing device  102 .  
     [0051] POs are created as detailed above, or any other way known in the art. For example, a PO is typically uploaded into the database and written into the database. The writing process separates the components of the PO into fields, that populate the database. These fields can be selected by the users, with exemplary fields including: PO number, supplier part number, manufacturing part number, unit of measure, quantity, amount, short description, cost center, shipping information, tax, amount per item. POs can be created by any known software, for example, customer procurement applications from SAP®, PeopleSoft®, Oracle®, CommerceOne®, Ariba®, as well as ProcureScout SM , a web based interface from ESCOUT, Inc., 850 NW Chipman Road, Lees Summit, Mo. 64063, that provide electronic PO documents in formats such as xCBL, CXML (commerce extensible markup language), CSV (comma separated values) and UBL (universal business language) from Oasis®.  
     [0052] Invoices are created as detailed above, and here, for example, in the computing devices  104   a - 104   n  of the sellers. These invoices are created using for example EDI software, or by other processes. The invoice can be created, for example, as an answer in response to a PO entering the PO database, block  207  or with a process in accordance with Flexible Invoicing Software, a web-based interface from ESCOUT, Inc. (detailed herein at FIG. 6), block  208 . These two exemplary methods for directly creating an invoice are typically real-time based, but can also be performed off-line.  
     [0053] Turning to FIG. 6, there is shown a process in accordance with the Flexible Invoicing Software, described above, at block  208 . The process begins, as the user, here the supplier (for example, corresponding to one of computing devices  104   a - 104   n ), goes to the World Wide Web (WWW), and sets their browser to the web site corresponding to the host server (H)  106 , here for example, the address www.abc.com, at block  302  to obtain a GUI (for example, the screen shot of FIG. 7), from where they will access the requisite PO, at block  304 . The user typically searches for the requisite PO based on one or more fields, for example, PO Number, PO status, Date Range. The PO is then retrieved from the PO Database  108 , at block  306 , and displayed on the user&#39;s browser, at block  308 .  
     [0054] With the PO now on their browser and monitor (here, for example, computing device  104   a - 104   n  corresponding to the user), the user selects the PO line items to be included on their invoice, at block  310 . These line items are transferred to, for example, an electronic invoice template or other similar electronic document (that will result in an Invoice) or representation thereof (for example, stored in a storage device either external or internal to the host server  106 ) so as to be “flipped” onto an invoice, and displayed in the user&#39;s browser (and monitor) at block  312 .  
     [0055] With the invoice now created, the user can modify the fields of the invoice (for example, by accessing the GUI of the screen shot of FIG. 8), before saving the invoice in the invoice database  109 , at block  314 . These fields include, for example, supplier part number, manufacturing part number, unit of measure, PO Number, Quality, Unit of Measure, Description, Unit Price, Supplier Part Number, Sales Tax Total, Shipping Total, Invoice Number. The invoice is now saved in the invoice database  109 , at block  316 , and the process resumes at block  204 .  
     [0056] Invoices can also be uploaded into the system by vendors or other service providers, at block  209 . These invoices can come from service providers using their own software that will provide standard invoice documents. Such software is available for customer procurement applications from, for example, SAP®, People Soft®, iProcure®, Oracleo®, CommerceOne®, Ariba®, in accordance with document standard formats such as xCBL, CXML, CSV and UBL, as detailed above.  
     [0057] These invoices, once provided to the database, are written into the database  109 . The writing process separates the components of the invoice into fields, that populate the database. These fields are typically in accordance with the fields listed above for PO&#39;s, and additionally including invoice number, with at least one, and typically multiple, corresponding fields, so that documents (PO&#39;s and invoices) can be matched for reconciliation.  
     [0058] The databases  108 ,  109  (FIG. 3) are then scanned (searched) for complimentary POs and invoices, at block  220 , typically by using comparison software, that, for example, compares corresponding fields in the respective POs and invoices. It is then determined if the complimentary documents, for example, PO and Invoice here, match, at block  222 . A match is determined in accordance with user defined rules. For example, FIG. 9 shows a screen shot where an invoice is matched in accordance with PO line items. The reconciliation process begins at block  222  and, for example, ends in the approval process, at block  234  (and blocks  270 - 282 ), as described herein.  
     [0059] If a match occurred, at block  222 , the Invoice (fields) are checked for variances for that particular PO, at block  224 . The checking for variances is performed, for example, with comparison software or the like. This situation typically occurs with invoices that are entered into the invoice database in response to contracts or for services performed, that do not have a matching PO, as they were not created as the result of a PO in the system.  
     [0060] If a match did not occur, at block  222 , the invoice is compared against non-PO generated rules, at block  226 , and the process moves to block  234 , the approval process, as detailed below. These non-PO generated rules may be directed to, for example, amounts, approved suppliers, approved account codes, etc.  
     [0061] Returning to block  224 , if there are not any variances, the process moves to block  230 . If variances are detected, they are compared against PO generated variances, at block  228 . These PO generated variances are in accordance with user generated rules. These variances can be, for example, differences at the line item layer, differences in the total amount.  
     [0062] The process now moves to block  230 , where it is determined if the invoice is suitable for the approval process, at block  234 . An invoice is, for example, not suitable, should it fall outside of the non-PO generated rules (block  226 ), or outside of the PO generated variances (block  228 ). Conversely, an invoice is suitable for the approval process if, for example, if it falls inside of the non PO generated rules (block  226 ), inside of the PO generated variances (block  228 ), or if there are not any variances (block  224 ).  
     [0063] If the invoice is sufficient, it is passed to an approval process, at block  234 . The approval process of block  234  is shown in detail in FIG. 5, and described in detail below.  
     [0064] If the invoice is not sufficient, the buyer (who has not issued a PO or the like in the case where the process comes from block  226 , and is therefore, a receiver (or intended recipient) of the invoice without a PO) or issuer of the PO, is notified, typically electronically, at block  240 . This notification is typically over the internet  100 , from the host server  106  to the computing device  102  of the buyer. The buyer then calls up a user interface (for example, through computing device  102 ), for example a graphical user interface (GUI) (for example, in accordance with the screen shot of FIG. 10), typically via the World Wide Web or other network, corresponding to the host server (H)  106  (FIG. 3) (here for example, by directing their browser to the address www.abc.com to access the host server  106 ) and obtains the requisite invoice, as shown in the screen shot of FIG. 11. The obtained invoice can now be approved (as shown, for example, by the screen shot of FIG. 12, within the circle  290 ) or disputed (not approved) (as shown, for example, by the screen shot of FIG. 13, within the circle  292 ), and as indicated by the receipt of a signal from the buyer at block  242 . Typically, through the GUI, the user will send the approval or non approval signal back to the host server (H)  106 , FIG. 3.  
     [0065] Where the invoice was approved, or edited and approved, the process moves to block  250 , where a payment process or payment mechanism, typically in the form of an electronic settlement is made. During electronic settlement, for example, electronic payment instructions are created and processed, typically by automated clearing house (ACH) software, or other conventional electronic payment system.  
     [0066] Where the invoice was not approved as detailed above, at block  242 , the process invokes a dispute mechanism, at block  244 . Here, the system, for example, in the host server (H)  106  and/or its associated software and hardware, records a dispute, for example, by recording data corresponding to invoice numbers, time, purpose, and stores them in a database, typically the invoice database  109 .  
     [0067] Typically, this dispute mechanism places the buyer (for example, through computing device  102 ), who issued the PO, into a communication, typically an electronic chat (typically in real time) over the Internet  100 , with the seller (for example, through the requisite computing device  104   a - 104   n ), who issued the invoice, at block  246 . For example, a dispute over the goods has been indicated by an entry at box  294  of the screen shot of FIG. 14. This electronic chat may be in accordance with any of the known chat or chat room programs. Alternately, the buyer&#39;s comments can be recorded in a discussion board for retrieval by the seller, who responds to this online dispute.  
     [0068] A signal is then received, at block  248 , as to the chat resolving or not resolving the dispute. If a positive signal is received, that the chat resolved the dispute, and the invoice is approved, the process moves to block  250 , where an electronic settlement is made, as detailed above. Should a negative signal be received, at block  248 , and the dispute not resolved, the process returns to block  246 , where it typically continues until resolution and electronic settlement, at block  250 .  
     [0069] Turning back to block  232 , and FIG. 5, the approval process is now discussed in detail. The start of the process is at block  270 . Initially, in accordance with user generated rules, it is determined if approval of the invoice is required, at block  272 . If approval is not required, as the invoice falls within the rules, the process moves to electronic settlement of block  250 , at block  274 .  
     [0070] If approval is required, as the invoice falls outside of the rules, at block  272 , the buyer (or issuer of the PO) is notified, typically electronically, as detailed above, at block  276 . Similar to that detailed above, the buyer will access the GUI of the host server (H)  106  (FIG. 3), and pull up the invoice. Similar to that detailed above, the buyer, through the GUI (see the screen shots of FIGS. 12 and 13), will indicate approval or disapproval of the invoice through the GUI, that will send a signal corresponding to the approval or disapproval of the invoice, that is obtained by the home server at block  278 .  
     [0071] If an approval signal is obtained by the host server (H)  106  (FIG. 3) at block  278 , the process goes to the electronic settlement of block  250 , at block  274 . If a disapproval signal is obtained by the host server (H)  106  (FIG. 3) at block  278 , another query is made to see if the buyer issued a hold signal, at block  280 . For example, the buyer can create a hold signal through the GUI as shown in box  295  of the screen shot of FIG. 15 (with additional comments within the circle  296 ). If so, the invoice will be held, typically in the invoice database  109  (FIG. 3), and after a preset time in the database, the process returns to block  276 , where the buyer is again notified of this held invoice. If the invoice is not to be held, as a signal not to hold the invoice was received (obtained, for example, by the host server  106 ), the process goes to the dispute mechanism of block  244 , at block  282 .  
     [0072] The process from block  222  through electronic settlement, block  250  can be run either synchronously (with the arrival of a new PO or invoice document from any source) or asynchronously (via batch or cron job) to try to match documents in advance of migrating matching documents to their respective tables, as detailed above.  
     [0073] The processes described above, all or portions thereof, can be embodied in programmable storage devices readable by a machine or the like, or other computer-usable storage medium, including magnetic, optical, or semiconductor storage, or other source of electronic signals. Some computer-usable storage media include discs, such as magnetic and compact discs (CDs) and the like.  
     [0074] The processes (methods) (including sub-processes) and systems (including components) described herein have been described with exemplary reference to specific hardware and/or software. These methods have been described as exemplary, whereby specific steps and their order can be omitted, and/or changed by persons of ordinary skill in the art to reduce embodiments of the above disclosed processes and systems to practice without undue experimentation. The processes and systems have been described in a manner sufficient to enable persons of ordinary skill in the art to readily adapt other commercially available hardware and/or software as may be needed to reduce any of the above disclosed embodiments to practice.  
     [0075] Thus, there has been shown and described a process for integrating and reconciling electronic documents. It is apparent to those skilled in the art, however, that many changes, variations, modifications, and other uses and applications for the above described embodiments are possible, and also such changes, variations, modifications, and other uses and applications which do not depart from the spirit and scope of the invention are deemed to be covered by the invention, which is limited only by the claims which follow.