Abstract:
There is provided a method, performed by a processor. The method includes obtaining accounting data from a first database, and sending the accounting data to a second database, wherein the second database is located remotely from the first database.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     An automated embedded data collection system enables a collection of business information, e.g., identity and trade data, directly through a small business&#39; accounting software applications. More specifically, business information is collected by leveraging software applications and processes to push trade and business identity data and/or financial credit data, directly from the small business&#39; accounting programs to a credit company&#39;s data storage facility. This manner of collecting business information enhances quality of collected data and increase accuracy and depth of responses to customer credit inquiries. 
     2. Discussion of the Background Art 
     Business information companies and directory providers do not currently use software applications to collect financial, trade, and credit data from small to medium businesses. However, there is tremendous value in such data, as access to such data would allow collection and/or credit agencies to understand credit-worthiness of many small to medium businesses with which the agencies transact business. 
     Business performance information, which includes, but is not limited to, accounts receivable or trade information, has become extremely important in today&#39;s business marketplace, both in making credit decisions and in establishing reciprocal trade relationships between companies. Banks, CPA firms, corporations, credit companies, insurers and other underwriters have a need to monitor business performance information of their customers in order to minimize risk and avoid financial surprises. Moreover, the stability of manufacturing and service providing companies is often dependent on one or more key component(s) or services suppliers. Financial or operating problems at these suppliers could cause a chain reaction that adversely affects their business partners. As a result, manufacturing and service companies also have a need to review business performance information of suppliers and other partner businesses upon which they are dependent in order to insure that their future business operations remain stable. 
     Financial information on publicly traded companies is easily obtainable due to standardization of financial record keeping in accordance with generally accepted accounting principles (GAAP) and quarterly filing and disclosure requirements imposed by the U.S. Securities and Exchange Commission (SEC). However, for partnerships and other private business ventures, obtaining accurate and standardized financial information, e.g., accounts receivable or trade information, is much more difficult. Private businesses typically maintain their own financial records on site, or through assistance of an outside accountant, using one of a number of commercial off the shelf (COTS) financial accounting software programs. Such software programs, for example QuickBooks®, are ubiquitously well known in the accounting profession. QuickBooks® is a registered trademark of Intuit, Inc., or one of its subsidiaries. All of these programs, in one form or another, maintain financial records including balance sheets, income statements, individual account statements and other well known financial records. 
     As a result of the decentralized and unreported nature of small or private business financial information, it is often difficult for interested parties to obtain standardized financial information on businesses with which they are or may be interested in doing business. It may also be difficult to perform relevant comparisons between similarly situated businesses. Typically, companies in such a position will utilize a financial data gathering firm, such as Dun &amp; Bradstreet, to generate a report summarizing any known financial information about the business of interest. Such a report has come to be known in the profession as a “D &amp; B.” A problem with this type of financial reporting is that information about a company, obtained by these financial information gathering firms, is largely obtained through solicitation from the company itself. Once this self-reported information gets into the information gathering firm&#39;s possession, the submitting company no longer has control over its distribution. As a result, companies are generally reluctant to provide full disclosure, and may even be incentivized to mislead companies seeking to gather information on them. Also, because financial data gathering firms must rely on the willingness of businesses to disclose information to them, it is unlikely that uniform information will be available for all reporting companies. As a result, a consumer of such information will have difficulty in making a balanced comparison between two or more similarly situated businesses based on financial metrics. Another problem with conventional financial data gathering firms is that the data collection method may be disjointed, consisting of various sources that must be manually assimilated into a format that is valuable to consumers of such information. This is a labor intensive process which increases the ultimate cost for such information and likely reduces its accuracy. 
     Accordingly, there is a need for an improved system for sharing financial information of businesses with interested parties which ameliorates or overcomes the deficiencies of known systems. 
     One such system for selective sharing of business performance information is disclosed in U.S. Patent Publication No. 2005/0240467, which discloses an automated system for allowing a submitter business to selectively share business performance information with requester businesses through a business performance information sharing data center computer system over the Internet. A submitter business uploads a data file including business performance information such as a trial balance report generated by the business&#39; own accounting software program. The uploaded file is converted from the submitter-defined format to a standardized format. Various business performance data analyses are performed on the standardized-format data including generating standardized business performance reports and analyzing the data in accordance with financial metrics. After the business performance data have been formatted and analyzed, the submitter will specify one or more companies authorized to view the business performance data including specifying a level of business performance detail, from a plurality of levels of detail, and/or a business performance time period for which that authorized company may view business performance information. 
     Although some companies collect trade and identity information via manual processes, there is, however, a need for an automatic system that collects trade and identity information. 
     SUMMARY OF THE INVENTION 
     There is provided a method, performed by a processor. The method includes obtaining accounting data from a first database, and sending the accounting data to a second database, wherein the second database is located remotely from the first database. 
     A system and method, as described herein, employed for collecting and retrieving financial transaction data from small to medium businesses directly from their financial accounting software, overcomes a substantial credit information deficiency that now exists in the credit industry and, allows for creditors and business partners to obtain more credit and business reports on small to medium companies. The preferred embodiment differs from the aforementioned conventional systems in that it is embedded directly into a customer&#39;s existing software application, as opposed to just providing a hosted site to which to upload data, and provides a trio of software, process, and end-user incentives for the purpose of gathering identity and trade information from business software applications. 
     Embedded data collection enables the automated collection of business information, including trade and identity information, directly through business software applications by leveraging business software applications and processes to push and pull data from a customer&#39;s software applications to a credit company. For example, at a determined frequency a plug-in to the business software application will trigger an extraction (pull) from the appropriate data sources and aggregate, organize, and encrypt this data—then the plug-in will send (push) this data to the credit company. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of an embedded data collection plug-in process. 
         FIG. 2  depicts various screen shots of an embedded data collection plug-in and retrieval process. 
         FIG. 3  is a diagram of a three-step process for plug-in installation and operation. 
         FIG. 4  is a block diagram of  FIG. 3 , step  1 , for registration and downloading of a plug-in. 
         FIG. 5  is a block diagram of  FIG. 3 , step  2 , for initial data transfer from customer to database supplier. 
         FIG. 6  is a block diagram of  FIG. 3 , step  3 , for periodic data transfer. 
         FIG. 7  is a flow diagram of a plug-in process. 
         FIG. 8  is a screen shot of a dialog prompting a user to proceed with installation of a plug-in onto a computer. 
         FIG. 9  is a screen shot of a dialog displayed by an accounting program. 
         FIG. 10  is a summary view of trade data. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       FIG. 1  is a block diagram of a process  100 . A system employing process  100  includes a processor, i.e., a computer  104 , having an associated memory with an accounting program  103  installed therein. Computer  104  is coupled to a database  106 , and also coupled, via a communications link, to a database  125 . Database  106  has accounting data  107  residing therein. Computer  104  maintains accounting data  107  by executing instructions that are embodied in accounting program  103 . Accounting data  107  may include, for example, business performance information, accounts receivable data, and trade information. The accounts receivable data may, in turn, also include accounts receivable aging data. 
     Database  106  is maintained by a first business entity, e.g., a business that produced accounting data  107 , and database  125  is maintained by a second business entity, e.g., a credit company that evaluates accounting data  107  to prepare a report for a creditor of the first business entity. Alternatively, database  106  may be maintained by an accounting firm that manages the books of several businesses, where accounting data  107  pertains to operations of the several businesses. 
     Although computer  104  is represented in  FIG. 1  as a standalone computer, computer  104  may be configured with a plurality of devices (e.g., processors, memories, servers) coupled to one another via a network. Many implementations of database  106  are possible. Some such implementations are a flat file, a relational database management system (RDBMS), or a collection of spreadsheets. 
     In step  105 , a plug-in  101  that interfaces with accounting program  103  is installed into computer  104 . Plug-in  101  is a program module of instructions for controlling certain functions of computer  104 . The functionality of plug-in  101  is described below. 
     In step  110 , computer  104  obtains accounting data  107  from database  106 , and prepares accounting data  107  for transmission to database  125 . More specifically, computer  104 , pursuant to instructions contained in plug-in  101 , invokes an application programming interface (API)  108  of accounting program  103  to locate, access, and extract accounting data  107  from database  106 , and prepares to send accounting data  107  to database  125 . For example, computer  104  will locate the appropriate sources of data, determined during the installation of plug-in  101 , to identify qualifying records, extract/select those records, and make additional extracts/selects from other tables to make this data a complete record (e.g., source name, details, current information, relevant aged data). Plug-in  101  may, therefore, locate accounting data  107  by using techniques such as, for example, parsing a text file, or querying records in a RDBMS, or extracting cells from a spreadsheet. 
     In step  115 , computer  104  sends accounting data  107  over a communication link automatically to database  125 . A pull might be, for example, scheduled to occur a pre-determined time or at a predetermined interval of time. Additionally, a user of computer  104  can initiate a transfer of accounting data  107  from database  106  to database  125 . 
     In step  120 , database  125  receives accounting data  107 . Database  125  may be managed, for example, by a credit company that creates or updates business records based upon accounting data  107 . 
     Although plug-in  101  is represented a being installed into computer  104 , plug-in  101  may be embodied as a machine-readable encoded program, i.e., a plug-in  101 A, and stored on a storage medium  130  for subsequent installation into computer  104 . Examples of storage medium  130  include, but are not limited to an optical storage medium, a magnetic storage medium, a magneto-optical storage medium, a flash memory medium and a ROM chip. 
       FIG. 2  shows four screen shots, i.e.,  205 ,  210 ,  215  and  220 , in an exemplary embodiment of process  100 . 
     Screen shot  205  is a view of a user&#39;s financial accounting software after plug-in  101  has been installed on computer  104 , and successfully loaded. 
     Screenshot  210  demonstrates the pushing or pulling of accounting data  107 , e.g, trade data, from accounting program  103 , e.g., a user&#39;s accounting program, to database  125 , e.g., a database of a credit company, on a monthly schedule. 
     Screenshot  215  demonstrates a capturing and storing of trade data, accounts receivable data, and/or financial data on a hosted website. 
     Screenshot  220  demonstrates an updating of database  125 , maintained by or for a credit company, with detailed trade data, accounts receivable data, and/or financial data sent to the credit company pursuant to instructions in plug-in  101 . 
       FIG. 3  is a diagram of an exemplary embodiment of a three-step process for installation and operation of plug-in  101 . 
     In step  305 , a user, e.g., a customer, downloads and installs plug-in  101  onto computer  104 . The download may be accomplished via a communications link. In this regard, the customer may visit an Internet website of a credit company that invites the customer to download plug-in  101 . The invitation may be presented in the form of an incentive such as an enrollment offer, or an advertisement. Additionally, the customer registers plug-in  101 . 
     In step  310 , an initial transfer of data between the customer and the credit company takes place. The customer uses accounting program  103  as would be done in the ordinary course of business. In step  310 , financial data accumulate as usual, but the data are also prepared for transmission to database  125 . 
     In step  315 , a periodic transfer of data between computer  104  and database  125  takes place. Computer  104  extracts, in the background and without a requirement for user interaction, accounting data  107  from database  106 , and sends accounting data  107  to database  125  over a communication link. The time at which, and the conditions under which, the extraction and upload are performed are governable by user-configurable triggers. Plug-in  101  is also user-upgradable. 
     After step  315  is completed, operation returns to step  310 . Operation remains at step  310  until a proper entry point into step  315  is again reached. 
       FIG. 4  depicts details of step  305 . In step  405 , the customer views an enrollment offer, such as an advertisement, for plug-in  101 . In step  410 , the customer registers to use plug-in  101  and provides registration information via accounting program  103 . In step  415 , upon successful registration, the customer is permitted to download plug-in  101 . In step  420 , the customer installs plug-in  101  directly onto computer  104 . 
       FIG. 5  depicts details of step  310 , wherein the initial transfer of data between the customer and the credit company takes place. In step  505 , in order to begin the initial data transfer, the customer executes accounting program  103 . Thereafter, in step  510 , the customer is prompted to provide data transfer permission and to set preferences. Such preferences can include an identification of which company files will be sent, and which specific customer records should be sent to the credit company. In step  515 , computer  104  locates and extracts accounts receivable data, trade data, or other financial information from database  106 . Thereafter, in step  520 , the extracted data are pushed to the credit company over a communication link. One way in which this push can be accomplished is with a secure HTTPS data transfer, either hardwired or wireless, over the Internet. In step  525 , the credit company receives the pushed data into database  125  to await processing. 
       FIG. 6  depicts details of step  315 , wherein the periodic transfer of data between the customer and credit company takes place. In step  605 , to initiate periodic data transfer, the customer executes accounting program  103 . In step  610 , computer  104  checks the last transferred data. If the last transferred data are older than a certain age, e.g., a month, then the current data are extracted and treated as explained below. If the last transferred data are not older than that certain age, then computer  104  will wait to perform further actions until the last transferred data are older than that certain age. Given data of proper age, then in step  615  computer  104  locates and extracts the correct accounts receivable data, trade data, and/or financial information from database  106 . In step  620 , extracted trade information is either pushed or pulled to database  125  over a communications link. As mentioned above, one possible way to perform pushing or pulling is to use a secure HTTPS data transfer over the Internet. In step  625 , the credit company then receives these data into database  125  to await further processing. 
       FIG. 7  is a flow diagram of a plug-in process  700 . 
     In step  705 , process  700  registers a user on an enrolment site. If the user requires registration help, then process  700  progresses to step  710 . If the user does not require registration help, then process  700  progresses to step  715 . 
     In step  710  the user can seek help from an enrolment help desk. After completion of step  710 , process  700  returns to step  705 . 
     In step  715 , process  700  determines if registration is complete. If registration is not complete, then process  700  returns to step  705 . If registration is complete, then process  700  advances to step  720 . 
     In step  720 , plug-in  101  is downloaded and installed. From step  720 , process  700  progresses to step  725 . 
     In step  725 , the user executes accounting program  103 . From step  725 , process  700  progresses to step  730 . 
     In step  730 , the user sets data-sending preferences. From step  730 , process  700  progresses to step  735 . 
     In step  735 , the user is prompted for permission to send accounting data  107  to the credit company. If permission is granted, then process  700  progresses to step  745 . If permission is not granted, then process  700  progresses to step  740 . 
     In step  740 , the data-sending preferences are sent to database  106 . 
     In step  745 , data extraction is initiated. From step  745 , process  700  progresses to step  750 . 
     In step  750 , data is transferred, by push or pull, to the credit company. From step  750 , process  700  progresses to step  755 . 
     In step  755 , the credit company receives, into temporary storage, the data pushed or pulled in step  750 . From step  755 , process  700  progresses to step  760 . 
     In step  760 , the credit company determines if the user is an approved provider. If the user is not an approved provider, then process  700  progresses to step  765 . If the user is an approved provider, then process  700  progresses to step  770 . 
     In step  765 , the user goes through a data provider approval process. From step  765 , process  700  progresses to step  755 . 
     In step  770 , the data received in step  755  are processed. From step  770 , process  700  progresses to step  775 . 
     In step  775 , the data processed in step  770  are stored in a database, e.g., database  125 . From step  775 , process  700  progresses to step  780 . 
     In step  780 , the data stored by step  775  are retrieved for use in preparation of information products for customers of the credit company. 
       FIG. 8  is a screen shot of a dialog prompting a user to proceed with installation of plug-in  101  onto computer  104 . The dialog provides the user with basic information on the benefits of using plug-in  101 . 
       FIG. 9  is a screen shot of a dialog displayed by accounting program  103 . A user of accounting program  103  is being prompted to supply authorization for access by plug-in  101  to records maintained by accounting program  103  pertaining to a particular business&#39;s trade data. The user is presented with a variety of options, each representing a different level of authorization to be granted to plug-in  101  to access the particular business&#39;s trade data. These options range from denial of access, to at-will read-write access. Additionally the user is presented with an option to allow or disallow plug-in  101  to access personal information of individuals associated with the particular business. 
       FIG. 10  is a summary view of trade data, e.g. data transferred by step  750  of process  700 . The summary view shows a statement date, the name of the entity that has transferred the data, e.g., the name of the entity from whose accounting program  103  computer  104  has retrieved the data, and an identification number used by a credit company to which the data are ultimately to be sent. Further, the summary view provides an entry for each customer of the user. The entry includes a customer name, an amount currently owed by the customer, amounts owed by the customer according to days late (that is, aging data or aging buckets, e.g. over 30, over 60 and so on), and a total amount due (i.e., a sum of current and overdue amounts). 
     While we have shown and described several embodiments in accordance with my invention, it is to be clearly understood that the same may be susceptible to numerous changes apparent to one skilled in the art. Therefore, we do not wish to be limited to the details shown and described but intend to show all changes and modifications that come within the scope of the appended claims.