Method and apparatus for managing account receivables

BACKGROUND OF THE INVENTION

0001This invention relates generally to a web-enabled Accounts Receivable System (ARS) and more particularly to methods and apparatus for managing various functions related to accounts receivables, credit granting, collection, dispute management and reporting and remittance processing.

0002The accounting department of a business entity expends substantial resources managing account receivables. An accounts receivable function includes the tasks of credit inquiries, approving credit to new and existing customers, and analyzing payment history of existing customers. In addition to credit approvals, aging of the receivables, disputes and delinquencies, collections and proper application of the payments, and determining appropriate write-offs and appropriate reporting capabilities, also must be managed. These tasks are time-consuming and often take away resources of the corporation from its operations and other profitable activities. Completing several of these tasks also typically requires interfacing with outside agencies for credit approval and constant updates to the customer records.

BRIEF SUMMARY OF THE INVENTION

0003In an exemplary embodiment of the invention, a web-enabled Accounts Receivable System (ARS) provides a full range of trade receivables Credit & Collection services including credit evaluation, credit granting, customer collection and account reconciliation, remittance processing, application and banking, all account receivables (A/R) reporting, consolidation, including customer statement preparation and mailing, ending with direct feeds to a client's general ledger system (G/L) for the client's financial statement preparation. The system serves clients by allowing them to outsource their full accounts receivable (A/R) function while still retaining the important computer-to-computer links covering order shipping approvals (after credit evaluation), billing/invoice feeds, customer dispute monitoring and reporting (on-line), and final month-end G/L interface for receivables balancing.

0004The system includes five modules which include a Credit Inquiry Module, a Remittance Processing Module, an Accounts Receivable Claim Module, a Maintenance Module, and an Administration Module. These modules are integrated with each other and are capable of interfacing with a client's Order, Ship, Bill (OSB) system for smooth functioning. The ARS is further capable of automatically upgrading the software and systems templates to the client by downloading on a real-time basis as they are being implemented at a central site and as called for by a user.

BRIEF DESCRIPTION OF THE DRAWINGS

0005<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of an Accounts Receivable System including a server system and a plurality of devices;

0006<figref idref="DRAWINGS">FIG. 2</figref> is an expanded version block diagram of an example embodiment of an Accounts Receivable System;

0007<figref idref="DRAWINGS">FIG. 3</figref> is an example embodiment illustrating further additional detail of an Accounts Receivable System;

0008<figref idref="DRAWINGS">FIG. 4</figref> is an exemplary embodiment of a software architecture for the Accounts Receivable System shown in <figref idref="DRAWINGS">FIG. 3</figref>;

0009<figref idref="DRAWINGS">FIG. 5</figref> is a database structure within a database server of the Accounts Receivable System shown in <figref idref="DRAWINGS">FIG. 3</figref>;

0010<figref idref="DRAWINGS">FIG. 6</figref> depicts the functions of an Order, Ship, Bill (OSB) System and an Accounts Receivable System with reference to a business process;

0011<figref idref="DRAWINGS">FIG. 7</figref> depicts the functional relationship of the Accounts Receivable System integrated directly into a client's OSB system and general ledger (G/L) system;

0012<figref idref="DRAWINGS">FIG. 8</figref> is an exemplary screen layout of the Accounts Receivable System shown in <figref idref="DRAWINGS">FIG. 3</figref>;

0013<figref idref="DRAWINGS">FIG. 9</figref> is an activity diagram for performing a credit check through a Credit Inquiry Module of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>;

0014<figref idref="DRAWINGS">FIG. 10</figref> is an activity diagram of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>, for the invoice generation;

0015<figref idref="DRAWINGS">FIG. 11</figref> is an activity diagram of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>, for remittance processing;

0016<figref idref="DRAWINGS">FIG. 12</figref> is an exemplary embodiment of a screen layout of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>, which displays a payment application to a customer account;

0017<figref idref="DRAWINGS">FIG. 13</figref> is an exemplary embodiment of a screen layout of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>, which displays the creation of a parent heirarchy record or payor heirarchy record for the subsidiary customer;

0018<figref idref="DRAWINGS">FIG. 14</figref> is an exemplary embodiment of a screen layout of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>, which displays the manner in which payment that has been applied by Accounts Receivable System may be subsequently reversed;

0019<figref idref="DRAWINGS">FIG. 15</figref> is an exemplary embodiment of a screen layout of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>, which displays the reversal of a zero application and all other records;

0020<figref idref="DRAWINGS">FIG. 16</figref> is an activity diagram of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>, for the collection process;

0021<figref idref="DRAWINGS">FIG. 17</figref> is an exemplary screen layout of the Accounts Receivable System shown in <figref idref="DRAWINGS">FIG. 3</figref>, which displays customer interchange credit;

0022<figref idref="DRAWINGS">FIG. 18</figref> is an exemplary screen layout of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>, which displays customer information sorted by customer number;

0023<figref idref="DRAWINGS">FIG. 19</figref> is an exemplary screen layout of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>, which displays the detail aging of a given customer along with scratch pad notes;

0024<figref idref="DRAWINGS">FIG. 20</figref> is an exemplary screen layout of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>, which displays the payment history of a given customer;

0025<figref idref="DRAWINGS">FIG. 21</figref> is an activity diagram of the Accounts Receivable claim (ARC) procedure of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>;

0026<figref idref="DRAWINGS">FIG. 22</figref> is an exemplary screen layout of the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>, which displays the root cause analysis summarizing outstanding Accounts Receivable Claims; and

0027<figref idref="DRAWINGS">FIG. 23</figref> is a process flow chart for the ARS shown in <figref idref="DRAWINGS">FIG. 3</figref>.

DETAILED DESCRIPTION OF THE INVENTION

0028Exemplary embodiments of systems and processes that facilitate integrated Internet-based accounts receivables process management are described below in detail. The systems and processes facilitate, for example, electronic submission of information using a client system, automated transmission of information, and web-enabled monitoring and reporting and management of account receivables including a final month end general ledger interface for receivable balancing for client's users.

0029The systems and processes are not limited to the specific embodiments described herein. In addition, components of each system and each process can be practiced independent and separate from other components and processes described herein. Each component and process can be used in combination with other components and processes.

0030<figref idref="DRAWINGS">FIG. 1</figref> is a simplified block diagram of an Accounts Receivable System (ARS) <b>10</b> including a server system <b>12</b> and a plurality of devices <b>14</b> connected to server system <b>12</b>. <figref idref="DRAWINGS">FIG. 2</figref> is an example embodiment illustrating additional detail of ARS <b>10</b>. <figref idref="DRAWINGS">FIG. 3</figref> is an example embodiment illustrating further additional detail of ARS <b>10</b>. In one example embodiment, devices <b>14</b> are computers including a web browser, and server system <b>12</b> is accessible to devices <b>14</b> via the Internet. Devices <b>14</b> are interconnected to the Internet through many interfaces including a network, such as a local area network (LAN) or a wide area network (WAN), dial-in-connections, cable modems and special high-speed ISDN lines. Devices <b>14</b> could be any device capable of interconnecting to the Internet including a web-enabled phone or other web-enabled connectable equipment. Device <b>14</b> is capable of connecting directly to Order, Ship, Bill (OSB) System <b>20</b> located at the client site. Server system <b>12</b> is also capable of communicating with OSB system <b>20</b> either through a direct link or through one of devices <b>14</b> located at the client site and upload and download the data as required. Accounts Receivable System <b>10</b> is installed at a business entity site within a firewall <b>22</b> while OSB system <b>20</b> is located at client site outside firewall <b>22</b> of the business entity. Both systems are configured to download and upload required data through a secure connection for performing the required functions.

0031As shown in <figref idref="DRAWINGS">FIG. 2</figref>, system <b>10</b> includes a server system <b>12</b> and devices <b>14</b>. Server system <b>12</b> also includes a database server <b>36</b> including a data storage device <b>38</b>, an application server <b>40</b>, a web server <b>42</b>, a directory server <b>46</b>, a fax server <b>52</b> and a mail server <b>56</b>. A disk storage unit <b>38</b> is coupled to database server <b>36</b> and director server <b>46</b>. Servers <b>36</b>, <b>40</b>, <b>42</b>, <b>46</b>, <b>52</b>, and <b>56</b> are coupled in a local area network (LAN) <b>60</b>. In addition, device <b>14</b> includes a system administrator work station <b>64</b>, a customer service representative work station <b>66</b>, a credit officer's work station <b>70</b>, and a general function work station <b>72</b>. Work station <b>72</b> is utilized by someone having an authorized access to maintain and update ARS <b>10</b>. Work stations <b>64</b>, <b>66</b>, <b>70</b>, and <b>72</b> are connected to LAN <b>60</b>. Alternatively, workstations <b>64</b>, <b>66</b>, <b>70</b>, and <b>72</b> are coupled to LAN <b>60</b> via an Internet link or connected through an Intranet.

0032Each work station <b>64</b>, <b>66</b>, <b>70</b> and <b>72</b>, in the exemplary embodiment, is a personal computer including a web browser. Work stations <b>64</b>, <b>66</b>, <b>70</b> and <b>72</b>, are illustrated as being associated with separate functions only to facilitate an understanding of the different types of functions that can be performed by individuals having access to LAN <b>60</b>.

0033In an alternate embodiment, server system <b>12</b> is configured to be communicatively coupled to third parties, e.g., internal or external auditors <b>78</b>, and to various clients <b>80</b> located outside firewall <b>22</b>, via an Internet Service Provider (ISP) Internet connection <b>84</b>. The communication in the exemplary embodiment is illustrated as being performed via the Internet, however, any other wide area network (WAN) <b>86</b> type communication can be utilized, i.e., the systems and processes are not limited to being practiced via the Internet. In addition, and rather than a WAN, a local area network could be used in place of the WAN.

0034Each outside client <b>80</b> is connected to their own OSB system <b>20</b>. Outside client <b>80</b> also has a work station <b>88</b>, which is a personal computer including a web browser. Also, Work stations <b>88</b> are configured to communicate with server system <b>12</b>. Furthermore, fax server <b>52</b> communicates with outside clients <b>80</b> and any of the remotely located overseas clients including a device (not shown) via a telephone link. Fax server <b>52</b> communicates with other devices <b>64</b>, <b>66</b>, <b>70</b> and <b>72</b>, as well. Accounts Receivable System <b>10</b> is installed at a business entity site while OSB system <b>20</b> is located at the client site. Both systems <b>20</b>, and <b>10</b> are configured to download and upload required data through a secure connection, from each other, for performing the required functions. Continuous enhancements ensure compatibility to use new technology as it becomes available which ultimately reduce cost and improve efficiency.

0035As shown in <figref idref="DRAWINGS">FIG. 3</figref>, device <b>14</b> is a desktop (thin device or often referred as thin client). Thin devices, as used herein, are Intel compatible PCs with Pentium or higher processors and a minimum 36 MB RAM running Windows 95 or Windows NT 4.0 workstation and Internet Explorer 4.0 and above. Server system <b>12</b> includes an application server <b>40</b> with a Pentium processor and a minimum 64 MB RAM running Windows NT 4.0 server and an Internet Information Server <b>92</b>. The Business logic will reside in this layer in the form of Dynamic Link Libraries (DLL). An Oracle 7.3.2 database <b>94</b> on UNIX is used as a Database server <b>36</b>, which is part of server system <b>12</b>. Database server <b>36</b> is a server including a Pentium processor and a minimum 64 MB RAM running Sun Solaris. The database layer resides within database server <b>36</b>. Centralized database <b>94</b> containing a variety of information relating to clients and their customers, as described below in greater detail, is stored on database server <b>36</b> of server system <b>12</b> and can be accessed by potential users at one of devices <b>14</b> by logging onto server system <b>12</b> through one of devices <b>14</b>. Stored procedures are used to access database <b>94</b>. All database interactions are done through Active X DLL's. Devices <b>14</b> are internally connected to OSB System <b>20</b> located at the client site. Server system <b>12</b> communicates with OSB system <b>20</b> either through a direct link or through one of the devices <b>14</b> located at the client site to upload and download the data as required.

0036<figref idref="DRAWINGS">FIG. 4</figref> is an exemplary embodiment of the software architecture <b>98</b> of ARS <b>10</b>, database server <b>36</b> and application server <b>40</b> of Server system <b>12</b>. The Software Architecture used in ARS system <b>10</b> has a Web Browser such as IE 4.0 and above as the front end. The Web Browser downloads the ActiveX controls developed in VB5.0, which forms the User Interface.

0037Middleware in ARS <b>10</b> implements the business rules and database calls and resides on the NT application server. The middleware is in the form of ActiveX objects (DLLs). Middleware is a software that connects two otherwise separate applications. For example, there are a number of middleware products that link a database system to a Web server. This allows users to request data from the database using forms displayed on a Web browser, and it enables the Web server to return dynamic Web pages based on the user's requests and profile. Middleware retrieves data from Oracle database <b>94</b> residing on the UNIX server. IIS is used as the WebServer. Active Database Objects (ADO) are used for database access. Oracle 7.3.2 database <b>94</b> resides on the UNIX Server.

0038Security in ARS <b>10</b> is closely monitored because of confidential and proprietary client information. Security is maintained in the system by providing various authority access levels. These access levels exist for individuals with different authorities such as Headquarter authority, supervisor authority, credit evaluator authority, Collector authority and remittance processing authority. When the user logs onto the application, the user's authority is checked, and depending upon the user's authority the user is given access to select screens.

0039Apart from the above security, ARS <b>10</b> also maintains regular security that is normally involved in every Intranet application. In every Active Server page ARS <b>10</b> checks whether the user has logged in and if the user has logged in then system <b>10</b> also checks whether the user has come for the right Active Server Page from which the user is supposed to access. If none of the above criteria is satisfied then system <b>10</b> displays an error message “Invalid Access to Screen”. Also there is a session variable that checks if the logged on user is idle for more than a predetermined period of time and if so the user is automatically logged out of the application.

0040<figref idref="DRAWINGS">FIG. 5</figref> is database <b>94</b> structure within database server <b>36</b>. Database <b>94</b> is coupled to several separate components within server system <b>12</b>, which perform specific tasks. ARS <b>10</b> manages full range of trade receivables credit and collection services involving credit evaluation credit granting, customer collection and account reconciliation, remittance receipt, application processing, banking, receivables consolidation, and updating OSB general ledger. ARS <b>10</b> receives the pertinent information from client's OSB system <b>20</b> for processing and generating required journal entries with a variety of reports for financial monitoring, reporting and auditing purposes. The information retrieved and processed is stored in centralized database <b>94</b> for permanent as well as temporary access.

0041For example, server system <b>12</b> is divided into separate components such as, a download component <b>100</b> for downloading journal entries and a variety of reports, a display component <b>102</b> for displaying the journal entries and the variety of reports, a transmit component <b>108</b> for transmitting required information to the OSB system, and a printing component <b>112</b> for printing journal entries and the variety of reports downloaded and displayed by the respective server components. The system accepts commands from device <b>14</b>, e.g., by utilizing a peripheral to make a selection or by utilizing a voice command. Server system <b>12</b> includes a processing component <b>116</b> for searching and processing received requests against data storage device <b>38</b>. Furthermore, server system <b>12</b> also includes a retrieving component <b>120</b> to retrieve information from data storage device <b>38</b>. An information fulfillment component <b>122</b> downloads the requested information after retrieving from data storage device <b>38</b> to the plurality of devices.

0042The architectures of systems <b>10</b> as well as various components of system <b>10</b> are exemplary only. Other architectures are possible and can be utilized in connection with practicing the processes described below.

0043<figref idref="DRAWINGS">FIGS. 6 through 23</figref> illustrate the operational flow of ARS <b>10</b> including the interrelationship among various ARS <b>10</b> modules and the interface between ARS <b>10</b> and OSB <b>20</b>.

0044<figref idref="DRAWINGS">FIG. 6</figref> depicts the functions of OSB System <b>20</b> and ARS <b>10</b>, with reference to a business process <b>160</b>. OSB System <b>20</b> includes an Order Entry function <b>164</b>, a Shipping function <b>170</b> and a Billing function <b>174</b>. ARS <b>10</b> includes the remaining functions involved with accounts receivables of business process <b>160</b> including managing customer credits, receiving and processing payments against open invoices, balancing general ledger on a periodic basis, financial statement data generation for accounting and internal controls and preparing periodic reports to meet generally accepted accounting principles (GAAP) and Financial Accounting Standards Board (FASB) requirements. Clients <b>80</b> from their individual locations operate OSB system <b>20</b> and a General Ledger (G/L) system <b>180</b>. ARS <b>10</b> is operated at a remote location by a business entity, which has a group of professionals specializing in ARS <b>10</b>. In an alternative embodiment, ARS <b>10</b> is operated and managed at the clients' locations by the clients' own staff with training and system enhancements being performed by ARS <b>10</b> staff.

0045<figref idref="DRAWINGS">FIG. 7</figref> shows how ARS <b>10</b> interfaces with a client OSB system <b>20</b> and general ledger (G/L) module <b>180</b> to provide continuity to the client. ARS <b>10</b> receives the data from, and transmits the data to, the different components of OSB system <b>20</b> such as Order Entry <b>164</b>, Shipping <b>170</b>, and Billing <b>174</b>. Order Entry <b>164</b> processes the customer order by extracting data from Pricing component <b>176</b> and Inventory component <b>178</b>. ARS <b>10</b> also interacts with various other components <b>182</b> of client system as required. The integrity of OSB system <b>20</b> is critical for proper functioning of ARS <b>10</b> since ARS <b>10</b> uses the data received from OSB <b>20</b> to generate the general ledger entries as well as other management reports. ARS <b>10</b> manages several other aspects of business process <b>160</b> to properly populate the general ledger with pertinent receivable data on a periodic basis including processes involved with credit management.

0046<figref idref="DRAWINGS">FIG. 8</figref> is an exemplary screen layout of ARS <b>10</b>. ARS <b>10</b> involves credit granting, collection, remittance processing, and reporting/administration. ARS functions are organized into five modules: a Credit Inquiry Module <b>190</b>, a remittance processing Module <b>194</b>, an Accounts Receivable Claim (ARC) Module <b>200</b>, a Maintenance Module <b>204</b> and an Administration Module <b>210</b>. Remittance Processing Module <b>194</b> is sometimes referred to as a Cash Application Module. Credit Inquiry Module <b>190</b> provides to the user extensive customer and receivable related information in a variety of ways. Remittance Processing Module <b>194</b> involves processing of remittance payments, delinquency management and payment-related functions. ARC Module <b>200</b> manages customer disputes. Maintenance Module <b>204</b> is used to maintain and store various types of customer information. Administration Module <b>210</b> is used to handle security and high-level systems functions.

0047There is a high level of integration across all the modules. Although a user may enter a function attached to a particular module in ARS <b>10</b>, subsequent navigation takes the user back and forth across the different modules in ARS <b>10</b>. For example, a user applying a check in Remittance Processing Module <b>194</b> accesses Credit Inquiry Module <b>190</b> to conduct a customer search or to display invoice details. A user viewing a customer statement accesses Maintenance Module <b>204</b> to modify customer information, or Remittance Processing Module <b>194</b> to offset debit and credits together under the account, or ARC Module <b>200</b> to set up or display a dispute. A user searching for an invoice in Credit Inquiry Module <b>190</b> or setting up a reference between two invoices in Maintenance Module <b>204</b> accesses Remittance Processing Module <b>194</b> to display a list of duplicate invoices. Similarly, a user reviewing billing batches in Administration Module <b>210</b> accesses Credit Inquiry Module <b>190</b> to display invoice details.

0048Overall, ARS <b>10</b> provides a full range of credit and collection services for trade receivables including credit evaluation, credit granting, customer collection and account reconciliation, payment receipt, application and banking, account receivables (A/R) reporting, consolidation, including customer statement preparation and mailing, ending with direct feeds to the client's general ledger (G/L) system <b>180</b> for financial statement preparation. ARS <b>10</b> can produce journal entries to update G/L system <b>180</b> by using pseudo account numbers internally which are mapped and transferred to client's G/L system <b>180</b> via a file transfer protocol (FTP). ARS <b>10</b> provides an option to clients <b>80</b> to outsource their full A/R function while still retaining the important computer-to-computer links with OSB system <b>20</b> covering order shipping approvals (after credit valuation), billing/invoice feeds, customer dispute monitoring and reporting (on-line), and final month-end G/L interface for receivables balancing. Each module of ARS <b>10</b> is described in detail.

0049A. Credit Inquiry Module

0050Credit Inquiry Module <b>190</b> primarily involves credit evaluation at the time the customer account is set up, and credit maintenance activities. Credit Inquiry Module <b>190</b> also interfaces with various modules to access delinquencies, collections and write-offs.

0051Credit Inquiry Module <b>190</b> reviews pay history and performs credit inquiries. Pay history is a set of calculations based on a payment period from invoice date to date of payment received. ARS <b>10</b> sorts all data and compiles it into a report that compares the data over an eighteen-month period and displays it in six-month increments. Credit Inquiry Module <b>190</b> accesses a customer account and views a diverse supply of data used for customer analysis, credit management, and customer contact. Credit Inquiry Module <b>190</b> further includes search options.

0052Credit Inquiry Module <b>190</b> predicts remittance forecasts for a specific customer or account based on historic data. ARS <b>10</b> predicts overall cash forecasting for the client. Credit Inquiry Module <b>190</b> further performs audit verification for tracking all transactions at the customer level for account reconciliation.

00531. Credit Application Process [New Customer]

0054The client works with the business entity to establish approval criteria on new customer accounts and to choose client specific credit scoring options using scoring software programs contained in ARS <b>10</b>.

0055<figref idref="DRAWINGS">FIG. 9</figref> is an activity diagram for performing a credit check for an existing customer through Credit Inquiry Module <b>190</b> on a customer who has placed a purchase order through OSB system <b>20</b>. Once the customer places a purchase order, ARS <b>10</b> receives a request for approval <b>220</b> on a new account. ARS <b>10</b> procedures routes request for approval <b>220</b> to a designated credit officer <b>224</b> out of a plurality of credit officers <b>230</b>. Credit officers <b>230</b> are also sometimes referred to as collectors or collection representatives. Designated credit officer <b>224</b> performs an initial credit investigation <b>234</b> on request for approval <b>220</b> of the new account. Designated credit officer <b>224</b> automatically approves request for approval <b>220</b> if the order aggregates less than an amount specified by the client or if the order is from a specified known customer pre-designated by the client. If request for approval <b>220</b> is not automatically approved <b>240</b>, designated credit officer <b>224</b> performs a detailed credit investigation <b>244</b>.

0056Credit investigation <b>244</b> does not have a specified application; rather it involves a variety of tools such as Dun &amp; Bradstreet reports <b>250</b> and/or other credit reporting agencies <b>254</b>, trade references <b>260</b>, bank reports <b>264</b>, financial statements <b>270</b>, customer visits <b>274</b>, and survey of Mines and Industrials <b>280</b>. ARS <b>10</b> electronically interfaces with Dun &amp; Bradstreet or other credit reporting agencies for searching and identifying a customer by name, address and telephone number and obtaining Dun &amp; Bradstreet reports <b>250</b> or other credit reporting agencies reports <b>254</b>, thereby minimizing the time in the credit approval process.

0057Based on credit investigation <b>244</b>, designated credit officer <b>224</b> determines whether credit should be granted to the customer. Each designated credit officer <b>224</b> has limits to the credit authority, which are resident and strictly controlled within ARS <b>10</b>. Designated credit officer <b>224</b> cannot grant a credit line in excess of their delegated authority limits. ARS <b>10</b> restricts access for changing the credit limits of credit officers <b>230</b> only to specified authorized individuals within the business entity.

0058If the customer meets the pre-determined parameters of credit investigation <b>244</b> and if the credit is within the limits authorized to designated credit officer <b>224</b>, designated credit officer <b>224</b> approves the new account request. If the customer does not meet the pre-determined parameters of credit investigation <b>244</b> or if the credit requested by the customer exceeds the authorized limits of designated credit officer <b>224</b>, then ARS <b>10</b> personnel attempts to obtain security <b>290</b> such as personal guarantees <b>294</b>, inter-corporate guarantees <b>300</b>, PPSA <b>304</b> or conditional sales agreements <b>310</b>. For approval of various orders, a letter of credit <b>314</b> may be sought.

0059Once designated credit officer <b>224</b> makes a decision <b>324</b> to approve the order, ARS <b>10</b> assigns an approval number in the case of an existing account or an account number <b>326</b> in the case of a new customer account to the order and interfaces with OSB system <b>20</b> which performs Order Entry function <b>164</b>, Shipping function <b>170</b>, and Billing function <b>174</b>. An interface <b>330</b> completes the credit approval process.

00602. Customer Order Approval—[Existing Customer]

0061<figref idref="DRAWINGS">FIG. 10</figref> is an activity diagram which depicts the process for customer order approval and invoice generation <b>412</b> as well as credit approval and posting of general ledger entries on G/L system <b>180</b>. Activities are located in respective columns based on the system that performs the activity. The columns correspond to OSB system <b>20</b>, G/L (General Ledger) System <b>180</b> and ARS <b>10</b>.

0062OSB system <b>20</b> enters/receives a customer order approval request <b>414</b>. OSB system <b>20</b> makes <b>416</b> a decision to automatically approve customer order <b>414</b> if the amount of order <b>414</b> is less than or equal to the Order Control Limit (OCL) <b>422</b>. OCL <b>422</b> is initially established when the account is set up in ARS <b>10</b>. After the initial set up, there are three ways in which the OCL <b>422</b> can be adjusted. Designated credit officer <b>224</b> can change the limit, or can place a Hold Order or a Credit Referral on the account. If a Hold Order or Credit Referral is placed on the account, OCL <b>422</b> is automatically reduced to zero. These changes to OCL <b>422</b> are fed to the client's OSB system <b>20</b> in a pre-determined cycle.

0063If the amount of approval request <b>414</b> exceeds <b>424</b> the OCL, approval request <b>414</b> is deferred and designated credit officer <b>224</b> is informed of the deferral through ARS <b>10</b>. Designated credit officer <b>224</b> then makes <b>428</b> a decision to approve, decline or hold the approval request <b>414</b>. Since the information is fed back and forth between OSB system <b>20</b> and ARS <b>10</b> in pre-determined cycles, the time lag for a decision is short with the vast majority being automatically and instantly approved within the client's OSB <b>20</b> based on ARS <b>10</b> pre-approvals. Once approved, OSB system <b>20</b> ships product <b>430</b> and generates a final invoice <b>432</b>. The client's OSB system <b>20</b> manages pricing and stores this information together with customer discounting structures, etc., within OSB system <b>20</b> and subsequently generates a customer invoice (hard copy or electronic) for its customer. OSB system <b>20</b> also creates a batch file <b>436</b> and dispatches said batch file <b>436</b> to ARS <b>10</b> the same evening.

0064Batch file <b>436</b> includes basic information <b>440</b> pertaining to invoice <b>432</b>. Information <b>440</b> received electronically to ARS <b>10</b> includes information such as a date of invoice <b>442</b>, a due date of invoice <b>444</b>, a currency of invoice <b>446</b>, an amount of invoice <b>448</b>, a customer number <b>450</b>, a billing identification recognition code (IC) <b>452</b>, an invoice number <b>454</b>, other payment terms <b>456</b> and a customer purchase order number <b>458</b>, if available.

0065ARS <b>10</b> then uses batch file <b>436</b> to update the customer's statement <b>460</b> for collection and monitoring purposes. ARS <b>10</b> also posts a journal entry <b>462</b> for balancing of the client's G/L system <b>180</b> at the month end. ARS <b>10</b> finally produces an “assessed receivable” total <b>464</b>, which provides the client with the G/L interface numbers to balance its financial statement and outstanding receivables. As part of this function, ARS <b>10</b> produces aged trial balances, dispute reports, trending reports, and any other reports for use by the client in substantiating assessed receivable total <b>464</b>.

0066B. Remittance Processing Module

0067Remittance Processing Module <b>194</b> involves application of remittance payments, aging the receivables. Remittance Processing Module <b>194</b> has several capabilities including accepting funds in any foreign currency and translating the funds into the required local currency for reporting purposes. In one embodiment, the reporting is conducted in local currency. In an alternative embodiment, the reporting is conducted in foreign currency. Exchange gain and loss calculations are automatically generated by Remittance Processing Module <b>194</b> of ARS <b>10</b>. Remittance Processing Module <b>194</b>, under certain conditions, automatically applies and updates a customer's account through a series of algorithms. Appropriate individuals, as designated, based on systems' security levels, have the authority to ZAP a particular account. ZAP is a derivative of remittance processing which allows for offsetting of items within a customer's account. In these situations, updating of balance is performed automatically online.

0068Remittance Processing Module <b>194</b> displays the accounts and applies the received cash by Payor Hierarchy. Payor Hierarchy allows the user to access multiple accounts through one or more designated main accounts. Remittance Processing Module <b>194</b> also allows Auto Draft and Reverse Application functions in conjunction with Maintenance Module <b>204</b>. Auto Draft selects specific invoices in a customer's account to be paid, which are formatted into an electronic bank file for funds transfer. Through Reverse Application, ARS <b>10</b> reverses previously completed applications and associated general ledger entries on G/L system <b>180</b>, and restores the account to the original balance on-line.

0069The following steps explain the operational and the functional flow involved in managing Remittance Processing Module <b>194</b>.

00701. Payment Receipts and Application

0071<figref idref="DRAWINGS">FIG. 11</figref> is an activity diagram for remittance processing. In most cases, the customer remits to the business entity the payment <b>470</b> on invoices through checks, wire transfers, electronic deposits, credit cards or drafts. ARS <b>10</b> receives the payments <b>474</b> and deposits them <b>480</b> in client's bank account.

0072Remittance Processing Module <b>194</b> of ARS <b>10</b> generally applies payments <b>474</b> to the invoice(s) <b>440</b> to which the customer wishes the payment to be applied. If remittance instructions are not received by ARS <b>10</b>, the cash received is treated as On Account Unapplied Cash. ARS <b>10</b> automatically sends a letter to customers who have On Account Unapplied Cash. The letter asks for instructions on how to apply the cash (and may result in a call to the customer for information). The On Account Unapplied Cash moves with the aging buckets but does not reduce the delinquency amounts until it is applied, unless specifically cross referenced by designated credit officer <b>224</b> to a particular aging bucket. The cross-references done by designated credit officer <b>224</b> reduce the balance of the aging buckets that the On Account Unapplied Cash amounts are cross-referenced to in ARS <b>10</b>. ARS <b>10</b> maintains an audit trail of all cross-references made by designated credit officer <b>224</b>.

0073ARS <b>10</b> accepts payments <b>474</b> in multi-currency <b>484</b> and accounts for exchange gains or losses in the balancing process. ARS <b>10</b> also offers on-line remittance processing <b>490</b> so that concurrently with the application of the checks against the invoices, these invoices are shown as paid and the customer balance is updated in an on-line format. Remittance processing <b>490</b> allows for multi-account connectivity as depicted in <figref idref="DRAWINGS">FIG. 14</figref> herein. During remittance processing <b>490</b>, ARS <b>10</b> identifies any cash variances, exchange losses, discounts and concessions that are allowed. ARS <b>10</b> then automatically balances payment <b>474</b> by writing the journal entry so that the appropriate cash variance, exchange variance, discount or concession journal entry is included in the receivable totals balancing <b>494</b>. Remittance Processing Module <b>194</b> is balanced <b>494</b> in batch mode overnight and the appropriate journal entries are generated to update the receivable numbers in the client's G/L system <b>180</b>.

0074ARS <b>10</b> produces numerous reports and on-line screens which remittance processors use to reconcile the amounts of payments <b>474</b> received against the amount of cash applied and the amount deposited in the bank, so that any imbalance positions are immediately discovered. ARS <b>10</b> produces a current activity file on every transaction or edit to ARS <b>10</b> and also ties in the identification code of the person who made any change within ARS <b>10</b> at any time. This file is archived to a storage media.

0075<figref idref="DRAWINGS">FIG. 12</figref> is an exemplary embodiment of a screen layout of ARS <b>10</b>, which displays a payment application <b>510</b> to a customer account. Payment application <b>510</b> permits the operator to select a method <b>514</b> to apply the payment in a particular manner, such as by account descending <b>516</b>, a statement balance <b>520</b>, an invoice number <b>522</b>, a payment from oldest invoices <b>524</b>, pay by finder number <b>530</b>, an invoice search <b>534</b>, etc.

0076<figref idref="DRAWINGS">FIG. 13</figref> is an exemplary embodiment of a screen layout of ARS <b>10</b>, which displays the creation of a parent hierarchy record or payor hierarchy record for the subsidiary customer. Specifically, the customer record of a subsidiary <b>544</b> is interconnected to a payor <b>600</b>. This provides a merging of multiple accounts in order to obtain on-line aging of customer exposure and better facilitate remittance processing.

0077<figref idref="DRAWINGS">FIG. 14</figref> is an exemplary embodiment of a screen layout of ARS <b>10</b>, which displays the manner in which payment <b>474</b> that has been applied by ARS <b>10</b> may be subsequently reversed. A previous payment application is reversed in ARS <b>10</b> by providing information relating to a customer number <b>610</b>, a check reference <b>614</b>, a check number <b>620</b>, a lock box number <b>624</b>, a batch type <b>630</b>, and a batch number <b>634</b>.

0078In an alternative embodiment, information is automatically provided by data from other screens being used to populate select fields within reverse check screens.

0079<figref idref="DRAWINGS">FIG. 15</figref> is an exemplary embodiment of a screen layout of ARS <b>10</b>, which displays the reversal of a zero application and all other records. The screen layout identifies a customer number <b>640</b>, a finder number <b>642</b>, and an invoice number <b>644</b> through which the operator offsets certain items to an account of customer <b>640</b> and updates the records of customer <b>640</b> on-line.

00802. Concentration Monitoring

0081Designated credit officer <b>224</b> can monitor the account balances and activity on-line through ARS <b>10</b>. Periodically, reports are generated that indicate the accounts on which action is required during the following week. Accounts are included in the report if they meet any of the exception conditions which can be changed immediately through the use of tables. ARS <b>10</b> produces numerous reports from the individual account level up to the overall client level.

00823. Aging

0083The criteria and process used in ARS <b>10</b> aging are very definitive, with an item being classified as being past due on the day after its due date. The aging of accounts in the credit status system is automated such that customer remittances are applied on-line, and the customer's balance is updated immediately for credit control purposes. Invoices that are not delinquent are broken into two sections: Current and Not Due. Current means the invoice is due within 30 days from a defined closing date. Not-due means that the invoice is due at least 31 days from a defined closing date. Delinquent (or past due) means the invoice is unpaid at least one day after its individual due date. The main report used to identify aging is an Aged Trial Balances as well as a Trending Report.

0084Although the aging of accounts receivable has been described here in Remittance Processing Module <b>194</b>, in another embodiment, it can be accessed or interfaced from other modules such as Credit Inquiry Module <b>190</b>, ARC Module <b>194</b> or Maintenance Module <b>204</b>.

00854. Delinquency Management

0086The normal delinquency collection cycle takes place by designated credit officer <b>224</b> and is triggered by either a past due condition which is identified on a weekly exception condition run and/or an on-line inquiry screen showing a customer who has exceeded their credit line. Although there are a variety of reasons for making collection calls or reconciliation attempts, the principal reason is delinquency.

0087One of the biggest collection incentives are the targets imposed upon credit officers <b>230</b> for collections as a percent to available receivables (total receivable balance less not dues) as well as percent to forecasted collections (used to measure ability of credit officer <b>224</b> to set accurate targets) which are monitored and reported on a monthly basis for each credit officer <b>224</b> and which become a part of the yearly performance evaluation of credit officers <b>230</b>.

0088<figref idref="DRAWINGS">FIG. 16</figref> is an exemplary embodiment of a simplified activity diagram of the collection process. Once accounts have been identified as requiring collection calls or preliminary investigative calls, designated credit officer <b>224</b> begins the required collection activities <b>700</b>. These are reviewed based on collections as a percent to forecast and available amounts as well as delinquency ratios. Delinquent accounts are reviewed routinely by credit officers <b>230</b> with their particular District Credit Managers in order to increase the intensity and level of collection activity, if required.

0089Some customers require a high degree of account reconciliation which must take place between credit notes being issued, customer debit notes being deducted, ARC <b>654</b> being rejected and/or proof of delivery supplied, etc. This is done on a daily basis by designated credit officer <b>224</b> as he provides the expertise to effectively manage the portfolio so that the client's own internal measurements are achieved. There are, however, cases where concessions are made to the customer and these are normally taken up by the District Credit Managers who reviews the items in question with designated credit officer <b>224</b> and makes recommendations for concession write-offs to the Region Manager who further reviews and, if appropriate, requests sign-off by the Vice President-Finance of the client. The client has the option of delegating this to the personnel of the business entity.

0090ARS <b>10</b> has a variety of reports that monitor delinquencies such as an aged trial balance <b>710</b>, an on-line aged balance <b>712</b>, an on-line customer data summary <b>714</b>, an interchange <b>720</b> from various credit agencies, payment habit statistics <b>724</b>, ARS <b>10</b> generated collection letters <b>730</b> (also sometimes referred to as “dunning” letters), a credit scoring <b>734</b>, a parent hierarchy <b>740</b>, communications on scratch pad <b>744</b>, and other reports. Payment habit statistics <b>724</b>, also sometimes referred to as payment history reports, are on a per account basis, per credit officer <b>224</b> basis, per client basis, etc. These reports are generated either on-line or in a monthly format together with the weekly exception reports on collection calls that are required. They are distributed to designated credit officer <b>224</b> with monthly aged trial balance <b>710</b> being provided to the individual client involved. The “trending report” encapsulates <b>38</b> actuals of A/R information per month on a 13 month tracking trend on one sheet of paper with their top <b>25</b> customer abusers on the back page.

0091An account is defined as being past due or delinquent within ARS <b>10</b> on the first day beyond the agreed upon terms of sale <b>746</b>. For example, an invoice billed on Jan. 1, 2000 with a term of net 30 days becomes past due and delinquent on Jan. 31, 2000 and is reported in that format. ARS <b>10</b> extracts from the billing input file the term <b>456</b> that is associated with each individual invoice and, together with its table matrix which has been approved by the client, assigns the particular due date <b>444</b>. The aging on ARS <b>10</b> is measured on a day-by-day basis, which is an accurate measurement facilitating better follow-up on delinquencies.

0092Each month ARS <b>10</b> receives feeds from Dun &amp; Bradstreet and other credit reporting agencies. Ownership changes, rating changes, judgments, and large decreases in Paydex or Payment Index scores are reported to designated credit officer <b>224</b> in a hard copy report. Additionally, any promises to pay made by customers are input into ARS <b>10</b>. These promises also appear on-line and on the weekly exception reports.

0093Delinquent accounts are handled by a variety of methods depending on the size of the dollars past due and the customer history for delinquencies. Collection letters are used <b>750</b> for smaller accounts. Multiple Collection letters, of increasing (strength), may be generated after individual invoice due dates based on a variable criteria by client and at predetermined intervals. Larger or “at risk” customers typically do not pass through the collection letter process <b>750</b> and are directly contacted by phone when their accounts become past due.

0094Sometimes, a customer has delinquencies in the form of a reconciliation progress whereby a substantial portion of the account is paid within the normal industry standard payment terms and it is important that collection calls not irritate the customer. Designated credit officer <b>224</b> is responsible to manage the account through its life cycle and to build a customer service oriented rapport with that customer for the maximum benefit to the client. In some cases special arrangements such as having the customer pay down old balances with the purchase of new goods allows the customer to work down any outstanding obligations.

0095ARS <b>10</b> also reviews <b>754</b> other documentation pertaining to the delinquent account such as letter of credit <b>314</b>, export insurance, and other financing documents.

0096Past due accounts are managed by a variety of credit officers <b>230</b> and are, in various instances, placed for collection <b>760</b> with an outside collection agency and/or lawyer prior to the request for bad debt authorization. By this, an independent third party makes an unbiased attempt at collecting the funds before writing it off as a bad debt. Customers that are bankrupt or have receivers appointed are handled <b>764</b> in accordance with the appropriate law. Generally, ARS <b>10</b> transfers such accounts to active bad debt files (discussed below). Any cash collected through collection activities <b>700</b> is processed through Remittance Processing Module <b>194</b>.

0097<figref idref="DRAWINGS">FIG. 17</figref> is an exemplary screen layout of ARS <b>10</b>, which displays customer credit interchange. Although the screen layout displays an embodiment of Dun &amp; Bradstreet reports <b>250</b>, similar screens are also obtainable from other credit reporting agencies <b>254</b>. ARS <b>10</b> utilizes a risk code system <b>766</b> that assigns a value from 1 to 8 based on information from trade experiences, Dun and Bradstreet, and other credit reporting agencies. If no information is available, the account is coded “N”. These codes are used to override “off” switches that may be present, such as the switch to turn off collection letters, also known as Dunning letters (discussed later) or other exception conditions.

0098<figref idref="DRAWINGS">FIG. 18</figref> is an exemplary screen layout of ARS <b>10</b> which displays customer information sorted by customer number <b>768</b>. This information is accessed by designated credit officer <b>224</b> through ARS <b>10</b> during their detailed credit investigation <b>244</b> as well as on-going account review and monitoring. The customer information includes a name <b>770</b>, an address <b>772</b>, a telephone number <b>774</b>, a Dun &amp; Bradstreet rating <b>776</b>, a risk code <b>778</b>, an amount of highest credit <b>780</b>, a date of last sale <b>782</b>, the year-to-date sales <b>784</b>, the unshipped order <b>786</b>, a date customer was opened <b>788</b>, a balance <b>790</b>, a current balance <b>792</b>, a past due balance <b>794</b>, a name of parent <b>796</b>, a currency <b>798</b>, credit status <b>800</b>, and other information.

0099ARS <b>10</b> reviews individual accounts on an exception basis. There is also a more formalized procedure whereby ARS <b>10</b> establishes a periodic credit update review and alerts designated credit officer <b>224</b> within a pre-determined time period prior to the lapse of the date that a review is required. This review may be simply designated credit officer's <b>224</b> mental review of the account, payment status with ARS <b>10</b>, pay history, days to pay statistics, Dun &amp; Bradstreet on-line interface information, so that an approval is input in ARS <b>10</b> to change the review date for another year. ARS <b>10</b> checks any change in the credit requirement to the individual identification code of designated credit officer <b>224</b> making the change to ensure that the credit limit of the customer has not been increased beyond the delegated authority of designated credit officer <b>224</b>.

0100<figref idref="DRAWINGS">FIG. 19</figref> is an exemplary screen layout of ARS <b>10</b>, which displays the detail aging of a given customer <b>802</b> along with scratch pad notes <b>744</b>. Scratch pad notes <b>744</b> include telephone or other exchange with or from customer, information regarding credits to customer, or other information. The screen layout identifies a date <b>804</b> of the last check received from customer <b>802</b> and the aging of the accounts receivable balance <b>806</b> which classifies the balance as past due for 1–30 days, 31–60 days, 61–90 days, 91–180 days, 181–365 days and over 365 days.

0101<figref idref="DRAWINGS">FIG. 20</figref> is an exemplary screen layout of ARS <b>10</b>, which displays the payment history <b>810</b> of a given customer <b>802</b>. For customer <b>802</b>, the screen layout identifies the net sales <b>812</b>, the credit notes <b>814</b>, the highest credit granted <b>816</b>, a write-off amount <b>820</b>, a check returned for not-sufficient funds <b>824</b> and other information, all of which information is displayed by the current semester <b>830</b>, the last six months <b>834</b> and the prior six months <b>840</b>.

0102Although delinquency management of accounts receivable has been described here in Remittance Processing Module <b>194</b>, in another embodiment, it can be accessed or interfaced from other modules such as Credit Inquiry Module <b>190</b>, ARC Module <b>200</b> or Maintenance Module <b>204</b>.

01035. Bad Debt—Write Offs and Recoveries

0104ARS <b>10</b> provides a sophisticated method for tracking bad debts once they are written off. In essence, when a write off to bad debt takes place, a journal entry is input to ARS <b>10</b> which simply transfers a mirror image of that customer's bad debt statement out of the normal receivable statements, generates an automatic journal entry to the client's G/L system <b>180</b> and mirror images the customer statement on an internal “active bad debt file”. From the client's perspective the balance is treated as a write-off. All write-offs proposed by ARS <b>10</b> are signed off by the client's Vice President of Finance (or delegate). Bad debts principally generated from receiverships, bankruptcies, etc., are still treated as active bad debt customers. Such information is transferred to the active bad debt file on ARS <b>10</b> which does not impact the client's aged trial balances. Files are transferred to the management individual assigned responsibility for bad debt monitoring who, on a routine basis, follows up with the various trustees, receivers, collection agencies, etc., to generate some recovery. On receipt of a final disbursement letter from the trustee or receiver, or a decision is made that there is no chance of additional recovery, the District Manager prepares a recommendation to transfer these specific customers out of the active bad debt file and to consider them to be inactive bad debts, which are then consolidated and stored in off-site storage for tax and audit purposes.

0105ARS <b>10</b> produces monthly runs of outstanding active bad debt accounts which are controlled by the appropriate District Managers. All bad debts are signed by the District Manager, the General Manager and a client delegate of the Vice President Finance.

0106Bad debt provisions are calculated by ARS <b>10</b> for each year and then divided into quarters. The bad debt provision is set at the average net bad debts over the last six years. The provision is checked against actual bad debts each quarter, and provisions are also adjusted up or down each quarter, as required. Year-end bad debt provisions, as calculated on ARS <b>10</b>, are then recommended to the client.

0107Although the write-off process has been described here in Remittance Processing Module <b>194</b>, in another embodiment, it can be accessed or interfaced from other modules such as Credit Inquiry Module <b>190</b>, ARC Module <b>200</b> or Maintenance Module <b>204</b>.

0108C. Account Receivable Claims (ARC) Module

0109ARC Module <b>200</b> manages the Accounts Receivable Claim Process which involves identifying invoices as disputed, and sending notice of such disputes to the client for resolution through on line communication. Upon generation of a claim, ARS <b>20</b> tracks the status in multiple ways and ages disputed items until final resolution.

0110The following process description explains the details involved in dispute resolution and other aspects of operational functions involved in managing Accounts Receivable Claims.

01111. Dispute Resolution

0112<figref idref="DRAWINGS">FIG. 21</figref> is an activity diagram of the accounts receivable claim procedure. Disputes from customers are recorded <b>844</b> in ARC Module <b>200</b>, which are instantly logged in, numbered, and filled in with the appropriate word description to generate an accounts receivable claim (ARC) <b>846</b>. Based on the identification code matrix established for ARS <b>10</b>, ARC <b>846</b> is immediately available on-line <b>850</b> to the responsible person within the client <b>854</b> for resolution and on-line tracking <b>860</b>. Hard copies of individual disputes are also printed overnight <b>850</b> in batch mode on designated printers for each of the client's responsible persons if requested. These persons input comments <b>864</b> on-line with any credit notes that are issued to adjust the customer short payments so that prompt offsets take place for aging purposes. Designated credit officer <b>224</b> puts their comments <b>870</b> on ARC <b>846</b>. Should a customer dispute be disallowed or rejected, using ARC <b>846</b> the client writes to the customer wherein the letter is laser printed on ARS <b>10</b> and mailed or faxed from the business entity's pooled location using the business entity's mailing volumes and procedures. These letters are electronic and become a part of ARC <b>846</b> for follow-up and audit purposes. Once the dispute is resolved, designated credit officer <b>224</b> closes <b>874</b> ARC. Open ARC <b>846</b> is maintained, reporting stored <b>880</b> on-line for aging purposes until, collected, credited or written off.

0113<figref idref="DRAWINGS">FIG. 22</figref> is an exemplary screen layout of ARS <b>10</b>, which displays the root cause analysis <b>890</b> summarizing outstanding Accounts Receivable Claims. This screen layout identifies the customer, a responsible person <b>892</b> from the client for said customer and an aging <b>894</b> of the accounts receivable disputes balance for the customer. Aging <b>894</b> identifies if the balance is current, 2 months past due, 3 months past due, 4–6 months past due, 7–12 months past due or 12 months past due. Designated credit officer <b>224</b> or responsible person <b>892</b> identifies and inputs <b>896</b> the reason(s) for the dispute with the customer and the amount in dispute. In an alternative embodiment, the data is captured from the initial ARC setup during remittance processing. For example, the reason for the dispute may be a sales concession, invoice not per contract, pricing error, or other reasons unique to each client and maintained in tables.

0114D. Maintenance Module

0115Maintenance Module <b>204</b> is used to maintain various types of information about the customer. For example, Maintenance Module <b>204</b> maintains and allows modifications to the customer information such as name, telephone number, and address. As depicted in <figref idref="DRAWINGS">FIG. 14</figref>, Maintenance Module <b>204</b> also maintains and updates connectivity between separate accounts. Additionally, through Maintenance Module <b>204</b> a customer service representative, designated credit officer <b>224</b>, or any other representative of the business entity accesses or updates any information pertaining to the customer interface. Maintenance Module <b>204</b> is very flexible and is accessible from Credit Inquiry Module <b>190</b>, Remittance Processing Module <b>194</b>, ARC Module <b>200</b> or Administration Module <b>210</b>.

0116E. Administration Module

0117Administration Module <b>210</b> deals with normal system administrator's functions including the maintenance of the security of the system. Additionally, Administrative Module <b>210</b> is utilized in updating various data and tables both during a nightly batch process and during on-line processing. Managers and supervisors have authority to access Administration Module <b>210</b> to update various records relating to the clients and their customers.

0118<figref idref="DRAWINGS">FIG. 23</figref> is a process flow chart <b>900</b> summarizing the functionality of ARS <b>10</b>. The first step of the process involves interfacing <b>910</b> with OSB system <b>20</b> to exchange and download the required data. After receiving <b>920</b> the invoice data, ARS <b>10</b> processes <b>930</b> billing files. ARS <b>10</b> extracts <b>940</b> data from the received information and posts the data to ARS <b>10</b> where it is then available to authorized users of ARS <b>10</b> business entity and client system <b>14</b>. Data is then loaded <b>950</b> and displayed <b>960</b> on client system <b>14</b> or any other devices attached to ARS <b>10</b> for analysis and processing <b>962</b>. Once the payment is received <b>970</b> from the customer, the payment is posted <b>980</b> to a proper customer account through ARS <b>10</b>. ARS <b>10</b> personnel having the authority to adjust <b>990</b> or move the payment from one account to another, in the event of an error. Once the payment is posted and the account is updated, ARS <b>10</b> generates <b>1000</b> the required general ledger entries and transfers <b>1010</b> the same to post on client's G/L system <b>180</b>. ARS <b>10</b> then downloads and displays general ledger entries as well as other information relating to the client or client's customers on devices <b>14</b> or client's work station <b>88</b>. The information retrieved from OSB <b>20</b> as well as information generated by ARS <b>10</b> between various steps is stored in Database <b>94</b> on disk storage unit <b>38</b>.

0119While the invention has been described in terms of various specific embodiments, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the claims.