HK1081688A - Business analysis tool - Google Patents

Description

Business analysis tool

no marking

no marking

no marking

Background

1. Field of the invention

The present invention relates generally to the field of accounting and business management tools.

2. Background information

There are currently many commercially available accounting and enterprise management software programs, such as accounting programs, spreadsheets, and databases. However, the architecture used by these software programs does not support the acquisition, storage, organization, analysis, and planning of financial and non-financial business metrics (metrics) to the extent required by the management, vendor, creditor, stockholder, manager, and so forth. As a result, many programs are used in an attempt to provide the required information. However, much of the information needed is still not provided clearly and concisely and is not connected to or compared with information derived from other software programs being used because of incompatibilities and other obstacles.

One of the main reasons that current systems are unable to provide the required information is because the system architecture of all such systems is not designed to provide a comprehensive view of the company. For example, all accounting procedures are compiled based on a numbering system for accounting charts. Each account in the accounting title table is numbered and nested (nest) into the associated account. For example, if all asset accounts are numbered 100 through 199, the cash or escrow cash may be 100 through 109, the accounts receivable may be 110 through 149, the inventory may be 150 through 159, and so on. Using the account number to describe the meaning of the data in the account. This limits the meaning to a single point of view. However, there are many views in business organizations regarding financial and non-financial business metrics. For example, for financial accounting purposes under the GAAP rules, assets must be displayed as the lower of a fair market value or its cost. According to the tax regulations in the united states, the asset value must be its cost minus the allowed depreciation or amortization. Assume that company A purchased a marketable security $100,000 in month 7, and that company A still owns the security by day 12 and 31, but has a market value of $75,000. Under the GAAP rule, the company must reduce the $100,000 asset to $75,000 and show the $25,000 loss in the profit-and-loss table. However, according to the U.S. tax rules, a stock must hold a value of $100,000 because it has not yet been sold.

Accounting systems (Accounting systems) record only events that have occurred and they record only financial information. However, managing the business requires a foresight that links the company's experience (in the past) with its plans (in the future). Financial information must be linked and compared to non-financial measures to truly understand what is happening and to effectively manage the company's future. The above architecture of the accounting system does not support a comprehensive review of the company, nor do other systems currently available.

Summary of The Invention

According to an exemplary embodiment of the present invention, a single system is employed to obtain, organize, record, analyze and plan all required relevant financial and non-financial business metrics by the management layer, suppliers, creditors, stakeholders, managers, etc. of a company. This includes all internally generated metrics and external metrics, such as data related to economics, specific industries, weather conditions, and so forth.

According to an exemplary embodiment of the invention, certain data obtained by the system is stored in an accounting chart. Unlike the accounting subject table organized in a tree structure with accounts described in the background of the invention, the accounting subject table is organized in Account properties (Account Nature), Account types, Account classifications, and sub-classifications. This organization does not prohibit the use of accounts. When using them, the user can use the account number to look up, however, the account number is not used internally by the program and whether they are present is not important to the functionality and features of the system. The account nature is the most extensive grouping. In an account setting, this typically would include: assets (Asset), liabilities (liabilities), revenues (revenues), expenses (depends), Owner's equity (Owner's), or Cost of Sale (Cost of Sale).

The account type is a second level grouping. Which define the type of assets, liabilities, etc. The account types include: liquidasset (Liquid Asset), accounts receivable (Account receivable), accounts payable (Accont payable), transaction income (TradeRevenue), transaction expenditure (Trade Expense), Operating Cash Flow (Operating CashFlow), financing Cash Flow (financial Cash Flow), investment Cash Flow (InyengCash Flow), and so forth. Account classification further refines the type of accounting. The classification includes: customer or provider, type of expenditure (e.g., rent, utility, commission), etc. An example of an account classification is accounts receivable by jones.

Sub-classification is a further refinement of the accounting title table. It defines the type of classification. For example, one sub-category of commissions is the commissioner Brown, and so on. Using this method instead of the numbering method never requires renumbering and facilitates reorganizing the accounts into different structures when necessary or desirable. For example, a sub-classification can easily be changed to a type simply by dragging (or positioning) it to a different level location in the accounting chart. Additional functionality becomes apparent when an Alternate Control Account (Alternate Control Account) is applied.

According to an exemplary embodiment of the invention, the system uses attributes and alternative control accounts to map data to different accounting standards or accounting standard structures (such as the U.S. GAAP, U.S. tax, etc.) so that data can be entered once and then automatically reflected or posted into different accounts corresponding to different accounting standards supported in a particular implementation or configuration of a company of the system. This allows a user to view or report company data through a variety of different accounting standards, including custom standards designed for the company or company's industry.

An alternative control account is one that is used to characterize the values in the account differently for different accounting criteria and for consolidation purposes. The account nature, type, classification, and sub-classification for the alternative control account may be different from the default criteria. For example, if the default criteria is the United states GAAP and the user wants to see the US financial statement tax summary or see the account in the financial statement, he/she may do so without logging out of the system. The U.S. tax account for the aforementioned securities tends to hold $100,000, while the GAAP account for the securities shows $75,000. The system can also reconcile the difference in the two accounts by treating the $25,000 difference as a payout under the GAAP standard.

According to an exemplary embodiment of the present invention, the system allows a user to define a tag or label of additional information, referred to herein as an "attribute," that may be attached to a particular transaction or information unit. These attributes, and an attribute center (a collection of all instances of one or more attributes), allow the user to analyze and track the tagged information in a flexible, specific manner. One obvious feature of the described attributes is: new attributes can be added without changing the database or writing a special program to provide the source of the attribute-related data. For example, if the database includes some apples and some oranges, a new attribute called fruit may be added to automatically summarize the apples and oranges without requiring any database changes or procedures. The reverse is also possible, if the database shows some fruit, then using the attributes apple and orange, the fruit can be deconstructed.

According to an exemplary embodiment of the present invention, the attributes, activity attributes, virtual attributes, attribute group IDs, virtual attribute group IDs, attribute centers, and virtual attribute centers are used to analyze past performance and future performance options or goals. For example, the system uses attribute concepts to identify accounts, assets, or company behaviors that affect the performance options or goals.

According to an exemplary embodiment of the present invention, alternative navigation methods are possible because the architecture of the accounting title table is not limited to a tree structure of the numbers related to other accounting systems. A user wishing to use an account may do so. The accounts may be identified by alphanumeric names (e.g., accounts receivable jones) and may be arranged in a manner similar to financial statements including Beginning Balance Sheet, Income Sheet, Cash Statement, and end Balance Sheet. The arrangement may also include an equity table transfer and Adjustment table (Transfers and Adjustment Statement) to account for transactions that do not appear in the profit or cash Statement. In addition to presenting the control accounts in a financial resolution format, this arrangement has the benefit of showing a time-in-time relationship between the financial statements. For example, the initial accounts receivable plus any adjustments (adjustments) or transfers, plus any sales, minus any Collection (Collection) equals the end property liability statement accounts receivable. The matrix thus constructed is also a navigation tool that allows the user to drill down one level from any control account until the transaction level is finally reached.

According to an exemplary embodiment of the present invention, an automated accounting and business analysis system organizes information in a three-dimensional matrix with general ledger control accounts on one axis, ledgers (sub-ledgers) on a second axis, and time-dependent account details along the third axis. The system enables a user to "drill down" by clicking on or selecting a named element in the matrix to navigate through information and causes the system to display additional information about the selected element or to move from a detailed information display to a high level less detailed information display.

According to an exemplary embodiment of the present invention, a user of the system may select any one or more accounts represented in the system and one or more arbitrary historical dates for the selected account(s), such that the system will display, for each selected account, the status of the account on each selected date and/or the history of the account for the time period defined by the selected date.

According to an exemplary embodiment of the present invention, financial information may be consolidated into a consolidated Account (Consolidation Account) from the various accounts by evaluating each Account to determine Account types and Account properties, and then determining a Consolidation Number (Consolidation Number) for a particular combination of Account types and Account properties. Then, when the data for merging and entry into the merged account is extracted from each account, the merge number for an account is used to determine where information from the account will be placed into the merged account.

According to an exemplary embodiment of the present invention, non-financial business metrics may be obtained, organized, stored, processed in various ways, and may be compared and linked with relevant financial information. For example, when used by one manufacturer, the system collects (capture) the cost of raw materials purchased and the number of raw material purchases (non-financial data). The system also maintains a bill of materials (BOM) for all manufactured goods (non-financial data). By calculating the amount of material used for the finished product against the amount of raw material remaining in the inventory, the system can closely approximate the amount and cost of scrap material generated during the manufacturing process. It can thus link the cost of the waste produced with the cost of the product and predict the financial impact of the waste reduction procedure.

Brief Description of Drawings

Other objects and advantages of this invention will become apparent to those skilled in the art from the following detailed description of the preferred embodiments of the invention, when read in conjunction with the accompanying drawings, wherein like reference numerals designate like elements, and in which:

FIG. 1 shows an exemplary information navigation process according to one embodiment of the invention.

Fig. 2A-C illustrate exemplary information display formats according to various exemplary embodiments of the present invention.

FIG. 3 shows an exemplary process according to one embodiment of the invention.

FIG. 4 shows an exemplary process according to one embodiment of the invention.

FIG. 5 shows an exemplary process according to one embodiment of the invention.

FIG. 6 shows an exemplary process according to one embodiment of the invention.

FIG. 7 shows an exemplary process according to one embodiment of the invention.

FIG. 8 shows an exemplary relationship between a control account and an alternative control account that allow for populating a merged account according to an exemplary embodiment of the invention.

FIG. 9 shows an exemplary process according to one embodiment of the invention.

10A-C show examples of logical structures formed by links or relationships between properties, property groups, virtual properties, and virtual property groups.

FIG. 11 shows an example of future Posting (Posting), according to an exemplary embodiment of the present invention.

Fig. 12A-B illustrate characteristics of a smart account according to exemplary embodiments of the invention.

Description of The Preferred Embodiment

According to exemplary embodiments of the present invention, a computer-based enterprise management system incorporates the traditional functionality of the following business processes: management, financial planning & analysis, rate analysis, analysis of internal and external financial and non-financial business metrics, economic correlation analysis, sales forecasts, general ledgers, accounts payable, accounts receivable, cash management, budgets, inventory, warehouse management, human resources, batch cost calculation, display and graphics software, workflows and communications. In addition to the functionality described above, the enterprise management system provides enhanced ability to collect, record, organize, analyze, and plan corporate business activities. The reports include administrative accounting reports, financial reports that fully comply with the United states GAAP (recognized accounting principles), United states tax, International Accounting Standards (IAS), and/or any other reporting standard. Posting to a single accounting standard automatically posts to all other standards running on the system. Data input into any module is forwarded to another module, so that multiple re-inputs of data, for example, in different locations or environments, are not required.

Three-dimensional matrix display

According to an exemplary embodiment of the present invention, the system arranges the selected control accounts into a matrix format such that the control account titles have both a landscape and portrait meaning, as shown in FIG. 2A. Fig. 2A shows an example of the matrix format with control accounts and sub-accounts underlying them on the first and second axes. This allows the user to "drill" down through the control account and obtain or view the underlying details. For example, the net sales amount is shown in FIG. 2A as one of the control accounts. By clicking on a title or button labeled for sale, the user can drill down to a particular department's sales, product sales, and up to a specific transaction (transaction). The control accounts may be organized and/or viewed as a three-dimensional matrix with the control accounts (as in financial statements) on a first axis, the sub-accounts (details) on a second axis, and Time (Time) on a third axis. This structure allows the user to view financial statements and easily drill down to account details at any given point in time.

This capability is generally depicted in fig. 1, where a control account is displayed in a first step 102. At a next step 104, the user drills down by selecting a cell, such as a title or an account in one of the ledgers, to cause the system to display more detail about the selected item. At a next step 106, the user selects an item in the displayed details, and as such, the system will display additional details about the selected item. At a next step 108, the user may navigate or return to a level of less detail by making an appropriate selection. For example, the icons "+" and "-", may be suitably displayed according to known techniques, such that clicking or selecting the "+" icon moves the information display to a level of more detail, while clicking or selecting the "-" icon moves the information display to a level of less detail or wider view (broader view).

According to an exemplary embodiment of the present invention, the system is provided with an Internet interface to enable the system to act as a web server and to allow a client (such as a user operating a web browser) to access and view information in the system. For example, a company may set up a website that interested parties, such as potential investors, may access to view financial and/or business information about the company. The website may provide a web browser of the interested party with a matrix presentation as shown in fig. 2 and allow the interested party to easily view and "drill down" or browse the company's information as described above. The website interface of the system may also allow interested parties to use various system functions as described below via a web browser. Of course, the company may configure the system to allow interested parties to selectively access various system functions as well as company information or data, for example, to protect confidential or proprietary information.

Returning to fig. 2A, note that fig. 2A shows the elements in each control account arranged in an order consistent with the end-of-term balance sheet. And in particular to initial balance sheets, balance sheet transfers and adjustments, profit sheets, cash statements, and end balance sheets. The system uses a flow equation over time through these reports. The matrix shown in fig. 2A has been arranged in the order of the balance sheet. However, the conventional profit-and-loss tables and cash statements are in a different order. For example, typically the profit-and-loss table will display the cost of sales of the product after displaying the sales amount. The profit-loss table will then display gross profits (sales-product sales cost). But in the matrix shown in fig. 2A, a bad bill is introduced between the sales and the cost of the goods. In the accounting field, it is often appropriate to sort the cash statements so as to summarize (summarize) each of the operations, investments and financing cash flows separately. However, this is not possible because we have arranged the elements in the order of the balance sheet. According to an exemplary embodiment of the present invention, the user may reorder the matrix to display all elements in the order of a balance sheet, a profit sheet, or a cash statement according to the user's wishes. The ordering is reorganized as one button is clicked.

To emphasize that selecting the account elements shown in FIG. 2A depends largely on the specific application of the system to a particular class of questions and the user/company preferences, FIG. 2B shows an example of an alternative (and simplified) selection of alternative account elements. As can be appreciated by one of ordinary skill in the art, the system accepts various account element selections and rankings. The examples shown in fig. 2A-C are therefore illustrative and not limiting.

As shown in FIG. 2C, FIG. 2C shows a matrix representation of a control account including an indirect cash statement. Indirect cash statements may also be used in place of the direct cash statements.

Unlimited date comparison

According to an exemplary embodiment of the present invention, a user may select any date of a financial year to compare a) the end-of-term account value or the value of any account or group of accounts (including financial statements) on that date, and b) different accounts on the same date. The user may also select a pair of dates within the fiscal year to compare a) the value generated for any account or group of accounts (including financial statements) generated during the time period spanned by the date pair, and b) different accounts during the same time period. The user may also select a pair of dates and compare a) the end-of-term account values or the values of any account or group of accounts (including financial statements) on one of the dates with b) the same or different accounts on the other date. The dates may be within the same financial year, or may be in different financial years.

Fig. 3 illustrates an exemplary process in which the system receives a date selection from a user indicating a particular time period in a first step 302. For example, the user may indicate the end of the time period. At a next step 304, the system receives an account selection from the user. At a next step 306, the system displays the activity that occurred in the selected account during the indicated time period.

Fig. 4 illustrates another exemplary process in which the system receives an account selection from the user in a first step 402. This selection may indicate a single account, or may indicate a number of accounts. At a next step 404, the system receives a date selection from the user indicating one or more time points for each selected account. The user may also indicate whether he wishes to see account details within the time period (or time periods) limited by the time point, or whether he wishes to see the status of the account at each time point, for example when the user indicates a number of time points for an account. At next step 406, the facility system displays, for each selected account, the status of the account at the selected point in time for that account. If the user indicates a desire to see the activity of the account during the time period limited by the point in time, the system will display the activity.

For example, assume the following case: the management of the company wants to compare the cumulative sales (or expenses) for a certain department in the company from 4/1/1998 to 3/15/1999 with the cumulative sales for a period from 4/1/1999 to 3/15/2000. The user selects the department and the date, and the analysis tool then automatically calculates and provides the comparison. The following is also assumed: the management layer wants to compare sales (or expenses) within 5 days after the thanksgiving this year with sales within 5 days after the thanksgiving last year (which has different dates since the thanksgiving falls on different days every year). This is also done automatically after the user specifies the necessary information, such as the department and the date relating to a known event such as a recurring holiday, such as thanksgiving. In other words, the dates may be identified or designated in different ways than the numerical day, month and year identification. The comparison date may be a posting date (PostingDate), an occurrence date (incorred date), a shipping date, a receipt date, or any other date, and may also be identified or specified in a different way.

Attribute and attribute center

According to an exemplary embodiment of the present invention, attributes and attribute centric concepts and corresponding mechanisms are provided in the system.

An attribute describes a condition or characteristic of a value or string in a transaction or a control account or subaccount or other stored data. In one exemplary embodiment of the invention, the attributes are stored in an attribute table. The attributes have logical pointers to the attribute group IDs. The attributes and attribute group IDs may have a many-to-many relationship. The attributes may include one or more informational tags, such as a 10 digit alphanumeric tag. Attributes may be linked to any data input to the system, including financial and non-financial data, to provide a characterization of the data. Attributes may be automatically generated based on rules set by the user. Other attributes may be attached as the case may be. Some attributes are system designed and others are user designed. Examples of attribute types include:

1. cash flow (operation, investment or financing)

2. Cash indicator (cash in from ___, cash out for ___)

3. Balance sheet adjustment (PP & E sales, credit inventory, litigation settlement)

4. Account property attributes (spending, income, assets & liabilities) these account property attributes are further defined by two user-defined attributes.

5. Client, project, work related attributes

6. Sales and purchase indicators

7. Items related to tracking the amount of items, destinations, modification history, and the like.

In practice, the user may "tag" financial and/or non-financial indicators (e.g., business metrics) so that the tags may be used to extract and compare the tagged indicators. For example, costs, sales, and net profits associated with a particular project or a particular division within a company may be tagged or tagged with attributes (information tags) so that the performance of the project or division may be accurately assessed.

In general, examples of different attributes include, but are not limited to, attributes such as operating cash flow, fixed expenses, and the like, as well as user-defined attributes. For example, the attributes defined by the user may include tags linking all of the benefits and expenses of one or more particular geographic distributions, products, promotions, and the like. The system assigns attributes based on a set of rules established at the time of setup of the system, or at the time of setup of a particular accounting system subsystem in the system. Other attributes are assigned by the user as desired. One of the primary functions of an attribute is to provide a tag for later database lookup. This enhances the ability of the system to collect and analyze company experience and, thus, may enhance the company's decision making and planning process.

The activity attribute is an attribute that has been added with an action (action). For example, one attribute might be "order over $10,000". Instead, an example of an activity attribute is "send form letter 123 to a customer whenever the customer's order exceeds $10,000, and send a copy of the form letter to the department of collection at j.jones".

A virtual attribute is an attribute that includes two or more attributes or virtual attributes.

The attribute group ID is an informational tag (e.g., in a database entry) that is added to the transaction data or account or other data being described or characterized. In an exemplary embodiment of the invention, the property group ID includes a) a logical pointer to each property contained in its named property group, and/or b) a logical pointer to a definition having a link (e.g., a logical pointer) to the property group of each property in the group.

The virtual property group ID includes two or more property group IDs and/or virtual property group IDs.

An attribute center uses logical pointers to identify one or more accounts, voucher (vouchers) types, attributes, attribute group IDs, or any other data (such as customers, vendors, inventory items), or static information. In an exemplary embodiment of the invention, the attribute centers are stored in an attribute center table. The attribute center operates at a higher level than the attribute group ID. In an exemplary embodiment of the invention, it is not necessary to attach information tags to documents, accounts, or other data aggregated by the attribute center. The nature (nature), type, classification, or other characteristic of the aggregated data itself is used in the attribute center definition.

The virtual attribute center includes two or more attribute centers or virtual attribute centers.

The attributes, active attributes, virtual attributes, attribute group IDs, virtual attribute group IDs, attribute centers, and virtual attribute centers may be created at any time, such as "on the fly" creation. In an exemplary embodiment of the invention, only authorized parties may delete them from the system.

Each transaction or entry, such as the transaction or entry shown in fig. 10A, points to one or more property groups, such as by including the property group ID of the property group (or groups) in the transaction or entry field. Each property group points to each entry or transaction with its property group ID and also to the individual properties included in the property group. In an exemplary embodiment of the invention, each property group (including virtual property groups) points directly (and optionally indirectly) to (directly and/or optionally indirectly) each element or entity with which it is associated (e.g., any type of property group, a property group ID, any type of property center, etc.). Each attribute points to the property group or groups of which it is a member. In other words, each property points to each property group that includes it.

In an exemplary embodiment of the invention, an appropriate property group identifier is attached whenever a new entry is completed or a posting (e.g., a transaction) is made. The pointer is already in place when an attribute is linked to the property group ID (e.g., when an attribute is added to the property group named by the property group ID). For example, if five transactions meet the property condition at a particular time (e.g., at 3:00PM), then there are five pointers. If another transaction is entered at 3:01PM that also satisfies the property terms, then a sixth pointer is automatically added when the property group ID is attached to the transaction. There is no lookup in the sense that it is not necessary to lookup all data and discard irrelevant data. The pointers bring us directly to the relevant data, which can then be aggregated or otherwise processed as desired. The pointer is automatically defined by the property group ID.

Fig. 5 illustrates a general process involving attributes, wherein data is input into the system in a first step 502. At a next step 504 (which may be part of the data entry process or may occur after the data has been entered), the data is tagged (e.g., via an attribute). In a next step 506, data is extracted from the system database(s) via the tags for display and/or analysis purposes.

Consider a specific example where a given company has market operations in one or more locations in the country. To assist the company in analyzing operations at sinxinati, ohio, a spending attribute may be added to the spending transaction to indicate market test TV (television) advertising spending for sinxinati, ohio. During market testing, the corresponding revenue attribute is added to the SincinNati sales ledger to provide a link to the site's specific product sales. In this case, the attribute may be entered into the Purchase Order (PO) at the time of purchasing the tv time, for example. Then when a television station invoice is provided, personnel at the AP (account payable) department will check the invoice against the PO and enter the data into the accounting system.

Another example is a disbursement that is not billable to the customer, but which the management layer wishes to associate with the customer for P & L (profit & loss) analysis purposes.

For analysis purposes, according to one exemplary embodiment, the system automatically attaches an attribute to all inventory transactions and sales transactions. For example, in one exemplary embodiment of the present invention, the product code for the item (or items) contained in the inventory and sales transaction is automatically included within the sales transaction. This facilitates linking sales and advertising and supports detailed analysis of drill-down to sales and expenses.

The attribute may also be used in cases where a company changes products continuously or repeatedly, but does not change the product number. In one exemplary embodiment of the invention, attributes are added to track modifications and identify different versions of the product while the product number remains unchanged. In exemplary embodiments of the present invention, attributes are used to track transactional characteristics, such as operating cash flow, investment cash flow, and financing cash flow; adjusting an asset balance sheet; and payouts with certain characteristics, such as payouts that exceed a certain amount or vary by more than a specified percentage; and so on.

An attribute center is a collection of all instances of a single attribute, or a set of related attributes. Exemplary attribute centers include profit centers, cost centers, asset centers, liability centers, and equity centers and single portfolio (singleoccasting) centers for analysis or planning.

Virtual attributes, virtual attribute centers, and virtual GL's are also supported. An example of a virtual attribute is an attribute created by combining two or more other attributes. A virtual attribute center may be, for example, a combination of two or more attribute centers. For example, a virtual GL may be formed by creating a center of attributes (e.g., containing logical pointers to two or more GL accounts) that point to two or more GL accounts.

FIG. 10A shows a transaction being posted to a database. In this example, each transaction includes three elements or fields, including: alphanumeric labels in Other Transaction data (Other transactionidata) elements, monetary value in Transaction Amount (Transaction Amount) element, and alphanumeric labels in attribute Group id (attribute Group id) elements or fields. In other implementations or embodiments, a greater or lesser number of elements or fields are used. The block 1042 includes other transaction Data (OtherTransaction Data) element, the block 1044 includes a transaction amount (TransactionAmount) element, the block 1046 includes an attribute group ID element, and the block 1048 includes an attribute group.

For example, at transaction 1012, the other transaction data is the tag Indianapolis television, the property group ID is AG-1, and the transaction amount is $1,000. Other transactions shown in FIG. 10A include: transaction 1014, where "other transaction data" is the tag Sincinatit Co-op advertisement postscript, the Attribute group ID is AG-2, and the transaction amount is $ 1500; transaction 1016, where "other transaction data" is the tag Cincinnati sales product 1 chain 1, the Attribute group ID is AG-4, and the transaction amount is $ 700; transaction 1018, where "other transaction data" is the tag California product 1 sales, the Attribute group ID is AG-5, and the transaction amount is $3,000; transaction 1020, where "other transaction data" is the tag Indianapolis sales product 1 chain 1, the attribute group ID is AG-6, and the transaction amount is $1,500; transaction 1022, where "other transaction data" is the cost of labeling the Annellus newspaper, the Attribute group ID is AG-1, and the transaction amount is $ 1500; transaction 1024, where "other transaction data" is the tag Cincinnati end corridor (Aisle) presentation cost, the Attribute group ID is AG-2, and the transaction amount is $ 500; transaction 1026, where "other transaction data" is the label Indianapolis sales product 1 chain 2, the attribute group ID is AG-3, and the transaction amount is $2,500;

each property group ID corresponds to (or names) a property group having one or more properties, as indicated by the link between the property group ID in block 1046 and the property group in block 1048. For example, the property group AG-1 includes properties A, C, E and G, as well as the virtual properties shown in block 1028; AG-2 includes attributes A, C, D, H; AG-3 includes attributes A, B, G, J; AG-4 includes attributes A, B, H, I; AG-5 includes attributes A, B, K; and AG-6 includes attributes A, B, G and I. An illustration of the attributes A-L is shown in the chart key 1030 of FIG. 10A. Associating a given transaction with different attributes allows the transaction to be viewed in different ways. For example, transaction 1012 Indianapolis television shown in FIG. 10A (either separately or together with other similarly tagged transactions, e.g., in the form of a list or as the sum of transaction amounts for all similarly tagged transactions) may be considered a payout (C) or as a fixed payout (E).

Block 1028 contains virtual attributes each described by the name or label of the attribute to which it points or refers. As shown in FIG. 10A, new or additional properties (including virtual properties) may be added to one or more of the property groups. For example, FIG. 10A shows the attribute L being added to the attribute groups AG-1, AG-2. The set of attributes can be changed or adjusted at any time without any database changes or new database lookup procedures, or any modification of the posted transaction shown in block 1002. Of course, one or more attributes (including virtual attributes) may also be deleted from a property group.

In an exemplary embodiment of the invention, each transaction or entry has only one attribute group ID. As shown in fig. 10A, different transactions may have/be associated with the same property group (ID). In another embodiment of the invention, each transaction or entry may have a number of property group IDs.

Fig. 10B illustrates virtual attributes that can be created by combining attributes. For example, as shown in FIG. 10B, the virtual attribute 1058 (having the name or label "Product-1 Indianapolis Expense") is a combination of the attributes 1052 "Product-1", 1054 "outlay", and 1056 "Indianapolis" (e.g., containing logical pointers to and/or from each of them).

The virtual attribute may be deconstructed into its constituent parts. According to an exemplary embodiment of the invention, a formula or other condition is attached to an attribute, thereby allowing further deconstruction. For example, we can create an attribute "fixed spending over $1,000", and we can locate the only transaction in FIG. 10A that meets this criteria, the Sincinatium Co-op advertising post. All indianapolis payouts are fixed and the only other cincinnati payouts are less than $1,000. This deconstruction differs from known standard techniques in that a "fixed payout" does not occur in the transaction data.

FIG. 10C shows a chart illustrating an exemplary relationship between an attribute center and a virtual attribute center. In particular, the attribute centers point to one or more entries (each of which is associated with a property group), while the virtual attribute centers point to one or more attribute centers, and/or one or more entries, and/or one or more virtual attribute centers. For example, the attribute center AC-1 shown in FIG. 10C links the sales in Indianapolis for chain-1 and chain-2. This link provides the total sales of indianapolis. Virtual attribute center VAC-1 plus AC-1 and sincinagin sales to calculate trial sales totals. VAC-4 aggregates AC-2 and AC-6 to generate a profit (loss) for the time period.

The property groups may be predetermined by the system and assigned automatically. The property groups may also be user defined and may be assigned by the user.

Attribute locking

When a single user accesses any record within the form, some commercially available database systems lock the entire form, while other commercially available database systems only lock the specific record accessed by the user. In an exemplary embodiment, the present system uses a different locking procedure. One purpose is to make the present system portable to any ODBC (open database connectivity) without changing the code. Another object is to reduce the complexity and unnecessary overhead that may exist in common recalculation routines, such as those provided by database vendors.

According to an exemplary embodiment of the present invention, related records are locked across tables and even across databases by inserting a record into a Lock Table (Lock Table). The record contains the transaction primary key. No physical lock is applied to all logically related records. A logical lock is used instead of a physical lock for the associated record. The target record is physically locked and a logical pointer is provided to lock all related records (i.e., all records related to the target record). For each record to be changed, a physical lock needs to be inserted into a lock record. Logical locking inserts only one record lock and uses the logical pointer to lock all related records. Logical locking is much faster than physical locking.

According to an exemplary embodiment of the present invention, the format of the "lock table" record includes: a bond 1; a bond 2; a key 3; a key 4; a key 5; a user ID; a process; and a status. "Key 1" is always the nature of the primary key (e.g., "COA", or accounting statement). "Key 2" is always the identity or identifier of the company in question (e.g., "Demo Co"). "Key 3" is always the first part of the primary key. "Key 4" is always the second part of the primary key. "Key 5" is always the third part of the primary key. The user ID may represent an identification or identifier of the user that used the system and/or caused the record to be locked. A "procedure" indicates whether the reason for the lock is "insert", "update", or "delete". The "state" defines the process stage, verification mode or execution mode.

Programs that require insert, update, or delete operations will require the insertion of a "lock record" into a "lock table". A single lock record may lock all records (directly or indirectly) that relate to the primary key. This locking system is called "attribute locking".

For example, assume the following case: one of the processes is to update a "ledger" account. All records containing the same "ledger" number (attribute) will be locked while the current process is running, preventing another process from changing the content in the already locked records. This reduces or avoids locking redundancy. For example, 1-20 or even more records are included in a set of records having a particular attribute (ledger number) as part of the primary key. By linking all records with the same ledger number, a single "lock record" can lock many records. This improves the program efficiency.

The method works as follows. When an operation requires a change to an existing record, the process first tries to insert one or more "lock records" in the lock table for the record to be changed, depending on the number of attribute keys included. The update process will not start unless all attribute keys are successfully inserted. If the process cannot lock all the required records to allow speeding up of those records, the process again attempts to lock the records that were not successfully locked in the previous attempt. The number of retries depends, for example, on a default value or user-specified system settings. Once the process exceeds the number of allowed retries, the process deletes the "lock record" entries for all records it can lock from the lock table and returns a message "other users are currently locking records, please try again later".

A common routine called by a different procedure performs the changes to the record (e.g., inserting new data). A system table is provided, named "database table" and contains the following 11 fields: field 1-define table name; field 2-11-defines the primary key property. Each table in the database has an entry in the "database table" whose sequential primary key properties correspond to the primary keys in their physical sequence. For example, performing posting to an account includes updating the following records: a "checkout period" record (which contains 3 primary keys such as company ID, account code, checkout period); an "accounting title" record (containing 2 primary keys such as company ID and account code); and a customer record (if the account is a customer account) (which contains two primary keys, such as a company ID, an account code).

Instead of inserting three lock records into the lock table to lock the three records from different tables, one lock record may be inserted to lock all three records. The key is a "database table" for those types of records that have the same attribute code (e.g., "AAAA" representing the ledger to which all three records belong). Thus, instead of inserting three lock records (one for the checkout period, one for the accounting statement, and one for the customer), we insert a lock record that includes the "AAAA" attribute code + the company ID + the account code. By doing so, we lock three records in different tables with a single lock record. During an update operation, if another process attempts to update a customer record, then the process will try to insert "AAAA" + corporate ID + the account code into the "lock form" and will find it being used. Likewise, if another process attempts to update the checkout period for the same account, then the process finds that it is currently in use.

The locking mechanism, as described above, may be applied to different kinds of database systems in general.

Management layer based on "target & rule

Goal & rule based management is a powerful tool in the system that management can use to optimize company performance. Fig. 6 illustrates an exemplary process in general form. In a first step 602, data is input into the system. This may include normal, daily data entry performed by the accounting department of the company. At a next step 604, the data is tagged, for example at the time of entry or at a later time. In one exemplary embodiment, the tag includes the attributes as previously described. At next step 606, the system receives a set of objectives and rules, for example, established by the person who the company runs the analysis. For example, a rule may restrict or define a particular activity or feature of the company such that a possible variation or scenario must be within it. For example, a rule may specify a minimum cash balance that the company must always have, or a maximum throughput capability of a manufacturing tool or line. At next step 608, the system automatically identifies via the tags (including the tag mechanism of the property center) which accounts, activities, or characteristics of the company are relevant to the received targets and rule sets. At next step 610, the system models the identified accounts, activities, or features and identifies or displays those changes that will achieve the goal in a manner consistent with the rules. At next step 612, the system modifies the changes to the established model (modeled) at the direction of the user. In other words, the user may adjust the model to explore the likelihood of achieving the goal by the rule. The user may adjust any or all of the goals, rules, and identified/modeled changes.

By way of specific example, the company may use the system in the following manner.

1. Managers set goals and rules. For example: asset rate of Return (ROA) of at least 12% (2% improvement over current 10% rate of return); the accounts receivable turnover period does not exceed 37 days on average (44 current days); and the labor cost does not exceed 23% of the sales cost (currently 28%).

2. The attribute center mechanism of the system identifies those accounts that each contribute to the target value.

2.1 increase ROA. To increase the ROA, one or more of the following measures may be taken: reduced assets, and/or increased net revenue (by increased revenue and/or reduced expenditure). Since this particular goal is company wide, it will include every asset, income, and expense account within the company. If the goal is expressed relative to a particular product line or profit center, the system will identify and access only those accounts that have an impact on both the goal and the selected product or profit center.

In one exemplary embodiment, the system then determines which assets are likely candidates for shrinkage, and which revenues may be increased and/or which expenses may be decreased. To this end, the system may determine different combinations of assets, revenues, and expenses. An optimization scheme is then optionally developed, for example, by the system automatically using known optimization algorithms or techniques. Based on the optimization results, the system provides several alternatives to achieve the goal, such as showing how improvements or changes in each field contribute to achieving the goal. The system may also develop optimization protocols at the direction or direction of the user, with any mix of user guidance and automated optimization techniques. For example, at one extreme, the user manually selects all options or actions (actions) to establish a solution that achieves the goal, while at the other extreme, the system automatically generates a suggested solution without user guidance or intervention; between these two extremes, all intermediate combinations of cooperative functions between the systems are equally possible and available in one exemplary embodiment of the present invention. Finally, the management layer then selects from the suggested solutions or creates a new solution.

2.2. Reduce the turnover period of accounts receivable. To reduce the accounts receivable turnaround period from 44 days to 37 days, it is desirable to reduce the amount of A/R (accounts receivable) that should be received from the payback account (accounts that pay on average over 37 days). To accomplish this, the management layer may increase collection by taking one or more of the following measures to a) increase communication with the customer by letter and phone, b) increase incentives to prompt the customer for timely payment, and C) create or increase barriers to overdue payment (e.g., by raising the overdue payment fee and/or adjusting future services based on payment of the current debt). The management layer may also reduce the accounts receivable turnaround period by one or more of completing the reimbursement of the old a/R, stopping and remitting customer business, asking for c.o.d. payments or pre-payments, and partial payments to the old invoice.

In one exemplary embodiment of the invention, since the goal of reducing the accounts receivable turnover period includes a particular class of customers, an attribute center is used to identify those customers, i.e., those paying more than 37 days after receiving an invoice. The corporate credit department personnel then interview these customers to determine the reason for the overdue payment. The meeting may reveal that the customer has batched his payment to the vendor, while the company's invoice arrived after the deadline of the customer's particular batch. In this case, the accounts receivable turnaround may be reduced by providing the company's invoice to the customer early enough (e.g., on or before a particular expiration date) to be included in the customer's batch. In other cases, the meeting may reveal that the customer is playing "float" (the money belonging to the company) and, in fact, is temporarily borrowing money from the company without paying interest. In these cases, the company may consider other solutions (e.g., establish incentives, obstacles, etc.) to address this situation. The meeting may also reveal other circumstances, such as the customer's credit rating should be downgraded, and so on. By analyzing the condition of each customer, additional information may be obtained and evaluated to indicate the appropriate response of the company to the customer. Based on these kinds of factors, and based on the importance of the customer and the extent to which the customer is overdue (days over 37), the management layer may develop a policy or standard response that includes a series of actions to automatically send a solicitation message to the customer, hand the customer to a collection agency, check out the customer, and so forth. The attribute mechanism of the system allows the company to use the system to automatically perform or initiate these actions, and/or to automatically detect a situation and alert a user so that a manager can initiate or agree to an action appropriate to the detected situation.

2.3. And labor cost is reduced. To reduce labor costs from 28% to 23% of sales costs, a reduction in the number of hours of labor per product and/or a reduction in labor costs per hour is required. The number of hours of labor per product can be reduced, such as by redesigning the product, automating the production, removing production or assembly constraints, or increasing productivity (e.g., via training, reorganizing the process, etc.), or a combination of any of the above. Labor costs/hour may be reduced, for example, by reorganizing labor allocations, reducing labor wages, reducing additional benefits from labor, purchasing outside labor (export labor requirements), or a combination of any of the above.

Because these activities or factors affect the labor cost of manufacturing and/or selling the company's products, the attribute center of the system may advantageously identify those activities and factors that contribute to the labor cost of all products, broken down into various tasks or factors as a percentage of the sales cost (i.e., normalizing all product costs). The organization of this information may provide important hints to indicate the most likely candidates for reducing labor costs, as well as to identify the products with the lowest and highest relative costs. Once the most likely candidates are identified, the costs of the various alternatives that reduce the costs can be analyzed to see which one produces the most effective solution.

Multiple accounting structures

According to one exemplary embodiment of the invention, the default accounting standard is the united states GAAP. However, there are often alternative accounting standards that are required by or useful to the company. These standards include accounting standards for tax returns, and those required in international business. In many cases, accounts are treated in one way for financial reporting purposes and in another way for tax purposes. The system allows the user to configure the system to automatically handle these complications or complexities.

An exemplary process for achieving this is depicted in fig. 7, where a set of tags is established in a first step 702. For example, the tag may include the aforementioned attributes and attribute center, as well as a traditional identifier from a known accounting standard. At a next step 704, an accounting standard is established using tags from the set of tags. Of course, tags may be added to the set when the criteria are constructed, or may be considered part of the criteria being constructed. The standards may be custom or proprietary standards designed for a particular company or industry, or may be commercially known standards. When the criteria are known or available, then the criteria can be "constructed" in the system, for example, simply by inputting taxonomies or comprehensive definitions into the system. At next step 706, an alternative control account (to be described in further detail below) is defined that is related to the accounting criteria. The alternative control account is used to link different accounting standards or to assist in mapping data between different accounting standards. At a next step 708, data is input to the system. At this point, either as input or later, the data may be tagged or identified/characterized to the system as appropriate. At next step 710, the entered data is posted to a set of accounting criteria accounts, which may be the set selected by the user or may be a default set. At a next step 712, the entered data is posted to an alternate control account corresponding to a different accounting standard according to the link or identified relationship between the aggregated accounts and the alternate control accounts of the different accounting standard at step 710. At a next step 714, the user selects an accounting criteria, such as a criteria by which the user wishes to view or report the entered data. At next step 716, the system retrieves the data using the tags referenced in the selected accounting criteria, and at step 718 generates a report or display of information that organizes the retrieved data in a manner consistent with the selected accounting criteria. For example, based on the retrieved data and the alternate control account associated with the selected accounting criteria, the system generates a report in accordance with the selected accounting criteria.

For example, for the purposes of GAAP financial statements and tax returns, the company may wish to have access to different depreciation schedules, for example because the company must treat asset valuations differently for the United states GAAP as compared to tax.

By way of specific example, if the company purchases a negotiable security worth $100,000 the year and stops the security worth $80,000 by the end of the company's financial year, then it is the correct practice to receive a $20,000 loss and to subtract the security as $80,000 according to GAAP in the United states. However, the company must still display the security as a $100,000 valuation under tax regulations. The security cannot be sold until it is sold.

In addition to the "official" standards, the company may wish to develop its own standards or may use different standards that are more appropriate for the company's business operations and management and provide information that other "official" standards may not provide. For example, the company may want a different standard that more accurately reflects the actual market value of the company. Intangible assets are either paid out or displayed at cost, for example, according to the united states GAAP, Tax (Tax) or international accounting standards. Thus, for example, inventions and patenting of valuable technology are not displayed at all on a company's book, or if displayed, it is displayed at cost (if the development takes place within the company). However, if the company purchases another company's patent at market value for the same technology, the market value will appear in the company's book. In fact, whether developed and patented internally or purchased from others who developed it, the asset has the same value for the company in question.

In addition, assets purchased by the company may actually be up-valued (added-value), but are required to be depreciated according to the united states GAAP, tax and international accounting standards. Office buildings or buildings are a good example of assets that should be technically depreciated, but which in fact can be added in value in the market.

In another example, when a company purchases a computer to increase employee productivity, the computer is treated as an asset and devalued within its "age". This spreads the cost of the computer over the period of time that the computer has value to the company. In another aspect, training of the employee is expended during training when training the employee to operate a computer. When assessing the company's own financial performance, it may be more appropriate to capitalize the employee training in the same way as a computer and distribute the employee training costs over the time that the training is beneficial to the company. By paying for the training during training, the company underreports its assets and hears more.

Additionally, the company may want to account for or estimate the value of a workgroup for the company that can generate profits or revenues for the company. Such corporate assets have market value, but generally the "official" accounting standards do not recognize such assets, and as a result the corporate accounting records (those strictly conforming to the "official standards") do not reflect the value of the workgroup. At the same time, expired or voided inventory may have a market value that is well below its manufacturing cost. The currently used "official" accounting standards generally require that the expired inventory be displayed on an account book at a cost, and thus add to its value.

The system supports different standards (e.g., customized standards that provide a more accurate or useful representation of a company's economic value and financial performance.

This method also includes clearing accounting because the value of a company and its assets change significantly when in the clearing mode. In any case, the real value of the company is important information for the management layer and is what the creditor and stockholder would like to know. To gain the ability for the system to report automatically under multiple accounting standards (including, for example, the U.S. GAAP, tax and international standards, among others), two mechanisms are used. One is the aforementioned attribute and the other is an alternative control account.

The user may wish to define how many alternative control accounts define how many. A set of alternative control accounts are connected to an accounting standard. For example, when the user chooses to use a statement of tax accounting standards, the depreciated asset account uses the depreciated schedule identified for tax returns. When the user chooses to use statements of different standards (e.g., the U.S. GAAP, International or economic accounting standards), the same these depreciated asset accounts use depreciation schedules identified for the different standards. The depreciation schedules for different standards may use different depreciation rates appropriate for the respective standards. For example, when the user selects the financial accounting standard, the corresponding schedule (schedule) would indicate that employee training is considered amortized assets, while schedules for the U.S. GAAP, tax, and international reporting standards would indicate that employee training is an expense. The alternative control account mechanism operates as follows. When the user posts a transaction to a default accounting standard (or is organized as a set of accounts that meet a default accounting standard (e.g., GAAP in the United states), the transaction is automatically posted to all other accounting standard bookings for the company, in other words, the alternate control account associated with the different accounting standards that the company wants to support. For example, the company may maintain a separate set of alternative control accounts for each of tax standards, international standards, standards specifically developed for use within the company, standards for the company's industry, and so forth. According to an exemplary embodiment of the present invention, input to any one of the alternative control accounts may be reflected appropriately into the other alternative control accounting (and into the default accounting criteria of the control account set).

According to an exemplary embodiment of the present invention, the date collected in the general ledger is the posting date of the corresponding transaction, event, or the like. In addition to providing GL and related reports based on the posting date, in an exemplary embodiment of the invention, the system maintains a GL based on the date of occurrence (Incurred), the date the event actually occurred. For example, sales within the last few days of the month are typically posted to the next month because they were posted after the first day of the next month. Accounting based on the date of occurrence can be quite helpful in determining commissions, depreciation, amortization, and the like. The date of occurrence accounting may be considered another alternative accounting standard. When a transaction or event is displayed to the user, either or both of the occurrence date and the posting date are displayed, depending on user-indicated preferences or according to default settings of the system.

According to an exemplary embodiment of the present invention, the system may perform future posting. That is, the system may post the transaction to a future date. One important application of this feature is the allocation of prepaid expenses or prepaid revenue. In the case of prepaid payments, the company pays in advance for the service or product. Allocating the payout to the period in which it is used is typically a complicated matter in prior art systems. Because the system in this embodiment of the invention can post in the future, it is fairly straightforward to allocate the payout to the correct time period.

In general, sometimes companies pay for or receive payment for services or products that have not yet been delivered. This is commonly referred to as prepaid expenditure or prepaid revenue. For example, when a company pays an annual insurance fee, it pays the coverage (coverage) that it has not received, and the insurance company has received money before providing the coverage. In another example, there are supplies that the company may purchase for use during 3 months, 6 months, or even 12 months (not referring to inventory that will be sold to customers or capital goods for producing a product or service). One reason a company may purchase a large quantity of consumable supplies is to spend less when purchasing supplies in large quantities than when purchasing supplies in small quantities on an as needed basis. Tracking such transactions so that they can be handled correctly each month can be a difficult task.

For example, if the company pays an annual fee for insurance, a pre-paid allocation of insurance expenses should be made monthly. Monthly posting becomes a difficult task when there are many prepaid charges on staggered start dates. At this point, the pre-payment is completed by posting to a future date, thereby eliminating the difficulty. The same is true for prepaid revenue. For example, the company receives payment for work that will be completed within a period of time. The allocation of pre-payment for sale during the appropriate time period is handled in the same manner as the pre-payment.

In another example on a larger scale, consider the recent problems of Global crosslinking (Global communications) corporation. Global bridging enters a long term lease to lease its black fiber to other carrier services. Global Cross receives a large total payment when entering a contract. Global trading reports the one-time total payment as revenue on the quarter it was received, thus expanding the revenue of the company in the interim. The effect of this technique can be masked as long as sales increase from quarter to quarter. Just as the GCs report revenue from the one total payment they receive, they enter the long-term lease of other black optical fibers where they are lessees and complete the one total payment to the lessor. In fact, sometimes they rent optical fibers from companies that are the objects of their renting of optical fibers. However, the rental payout (e.g., a one-time total payment by Global crosslinking to the lessor) is assigned to the time period in which the fiber is used by Global crosslinking. The gain is accelerated and the payout is delayed. The effect is evident. When revenue begins to drop, Global Crossing is at the cliff side where revenue is reduced and the rise is paid out. If Globalcrossing treats expenditure and income in the same way, the stock of Globalcrossing will not be fraudulently high (hype) in the early stage and its income will not disappear in the later stage.

According to exemplary embodiments of the invention, the system has a built-in (build-in) mechanism for automatically allocating revenue and expenses to periods when the business occurs. This is possible because the system can post to a future time period. Posting in the future has the effect of showing any advance payments as a balance sheet of the assets with the corresponding balance. The revenue sheet effect is when the revenue or expenditure occurs during the period in which it is earned or used. The direct cash statement effect indicates the actual period of time for which the collection or payment was completed. This is fully disclosed.

FIG. 11 illustrates an example of future period Posting (future Period Posting) in accordance with various exemplary embodiments of the invention. Fig. 11 represents the case where the customer is issued an invoice of $600 for 6 months of service at the beginning of the 6 months, and the associated entry is posted for future in the 6 months. For example, the $600 amounts are equally divided to post the respective $100 amounts (in the future) into the sales and A/R (accounts receivable) for each of 6 months. Other entries are also appropriately posted, such as in the deferred income category, where the amount entered equals the $600 amount minus the sum of the present and past A/R amounts. In particular, FIG. 11 shows the account by the end of the third month, where the customer paid the $600 invoice. The arrows pointing from the entry "Bank $ 600" in the collection portion of FIG. 11 to the A/R entries in the first, second, and third months indicate that those postings are now paid. For the remaining 3 months that have not passed, when entered into the prepaid income category, $300 of $600 payments are displayed in the third month's entry and properly posted to the prepaid income allocation and prepaid income category for each of months 4-6. For example, $100 is listed in the prepaid revenue allocation category or entry, and the prepaid revenue for each of the last three months represents the remainder of the $300 prepaid corresponding to the respective service that has not yet been delivered. Arrows in the invoice posting section of FIG. 11, which link the deferred returns, deferred A/R, deferred expenses, and deferred profits of the previous month to the sales, A/R, expenses, and profit entries or categories, respectively, of the next month, indicate where the decrement was posted. For example, in month 1, $600 of the total sales or contract value $100 is entered into the sales and A/R for month 1 (e.g., according to the double entry bookkeeping practice), while the remaining $500 value is reflected in the deferred income and deferred A/R entries or categories. In month 2, the value reflected in the deferred income and deferred A/R is $400, since $100 of the $500 value from month 1 was used for the sales and A/R of month 2.

The transaction shown in figure 11 is simply reversed when prepaid spending is considered.

According to an exemplary embodiment of the invention, the system may "shadow" another accounting system. This may be useful, for example, to ensure proper operation of a new system, such as when the company is transferred from an old accounting system to a new accounting system or structure, and wishes to temporarily maintain accounts in both the old and new systems simultaneously. According to this embodiment, when an entry is entered into the old system, the entry is automatically reflected or entered into the new system. This mechanism may be established, for example, using the techniques described in this disclosure (e.g., using the alternative account or the alternative control account described herein).

Fig. 12A-B illustrate features of a smart account according to one exemplary embodiment of the invention. Smart accounts may be used in conjunction with or independent of alternative accounts. The smart account includes rules such that when a transaction is posted to the smart account and the smart account identifies attributes (e.g., voucher type) related to the transaction covered by the set of rules of the smart account, the smart account processes the transaction in accordance with the rules. In an exemplary embodiment of the invention, the user may create a smart account by examining the boxes (boxes) associated with a given account and then entering or defining the rules that the smart account will apply to transactions posted to it. For example, the rules may indicate that all or a portion of the transaction is to be reflected or posted to other accounts as well. Thus, when a user posts a transaction to a default account or accounting criteria, the smart account mechanism may automatically enter the transaction into other accounts corresponding to other accounting criteria. For example, in FIG. 12A, accounts 1-3 and 5 are smart accounts that post transactions to IAS account A, B, C, E, respectively. The IAS account C may be a smart account that distributes the value entered to the account E, F according to a predetermined formula.

FIG. 12B shows another application of the smart account concept, where PP & E (plant, property & equipment) transactions or items are depreciated or classified differently according to the US GAAP rules and US tax rules. For example, as shown in FIG. 12B, the 5-year straight-line depreciation method is used to depreciate the item according to the U.S. GAAP rules, while the 200% decreasing balance is used to depreciate the same item according to the U.S. tax rules. This may be accomplished using a smart account. A similar comparison is shown in the lower portion of fig. 12B, where securities purchased by a company that have suffered a loss of market value or an increase in market value are used.

A voucher type (which is implemented in an exemplary embodiment of the present invention using attributes, e.g., the voucher type may be an attribute or a virtual attribute, etc.) may characterize an entry. For example, an entry may be tagged with a voucher type, and the smart account may have a rule set that causes the smart account to process the entry according to rules in the rule set associated with the voucher type. For example, rules for one voucher type can include posting to a particular other account, posting a portion of the transaction amount to another account, and so forth. In other words, the smart account has a rule set that defines the actions to be taken when identifying a particular attribute (any kind of attribute, including voucher type) associated with a transaction or entry. For example, a rule set for a smart account might include the following rules: 1. voucher type a, posting the amount to account 1; 2. voucher type B, posting 0.5 times the amount to account 3; voucher type C, posting 0.3 times the amount to account 4, posting 0.7 times the amount to account 5; and so on. Of course, any sort of mathematical manipulation may be applied to the amount before it is posted to one or more other accounts. For example, refer to the different depreciation schedules of FIG. 12B. In one exemplary embodiment of the invention, the action is taken when the transaction is first posted to a smart account.

The user may explicitly specify the voucher type when the user enters the system. For example, the user may make a selection from a menu offer (offer) as part of an input dialog. Also, the voucher type can be associated with a particular input screen or dialog selected by the user when entering the transaction, where different input screens or dialogs correspond to different kinds of transactions or vouchers. For example, a user may select an input screen suitable for entering a meal as a business expense, and the input screen will automatically associate the appropriate voucher type or other attribute with the input.

For example, voucher type 2 can be defined to identify a business meal expense. The smart account may have the following rules: when a transaction or voucher (the voucher may be a particular type of transaction or entry) having voucher type 2 or corresponding attributes is received for posting in a smart account, the transaction amount is reflected or posted to an account that tracks a reducible commercial payout. Thus, when the transaction is posted to a smart account, the smart account will identify the voucher type 2 associated with the transaction and apply the rules to track the appropriate portion of the transaction as a reducible commercial expenditure. For example, when defining voucher type 3 to characterize a transaction that is a business meal expense, the corresponding rules in the smart account rule set may specify that half of the meal fee is to be posted to a tax reducible business expense account.

In an exemplary embodiment of the invention, a plurality of rules may be defined for each voucher type or attribute, and each rule may include a designated account and an action to be performed on the transaction (including posting it to the designated account), with or without additional mathematical processing. A mathematical process is performed in the above example because only half of the transaction amount for a business meal expenditure is posted to an account that tracks reducible expenditures. Thus in the above example, the rule includes a reference or is associated with voucher type 3, specifies the reducible business expense account, and indicates that half of the transaction amount (business meal expense) should be posted to the specified account. Multiple voucher types can be defined and used. One voucher type can include a description of the kind of information or transaction to which the voucher type is applied, for example as a help reference that the user can use to understand the system.

The smart account may be located in any suitable location within a hierarchy or structure of accounts and/or accounting criteria, and the like. Logic and processing is defined at the account with a smart account and is performed as part of posting to the account.

A voucher may include multiple entries relating to a single transaction. For example, in dual-entry bookkeeping, two entries are made for each transaction or event, and a voucher may include all entries related to the event. The voucher type can be an attribute, or can be a sub-attribute (e.g., part of an attribute definition). In one exemplary embodiment of the invention, a transaction may be tagged or associated with multiple voucher types.

Traffic metrics

In accordance with exemplary embodiments of the present invention, in addition to aggregating, analyzing, and planning financial data, the system also links non-financial business metrics to their financial results (financial sequences). This allows each company sub-company, division, or department to view the business metrics that are meaningful to them.

For example, the sales department of the company wants to see sales units, sales ($ or%), market share by region or salesperson, growth relative to a previous or reference period, sales support cost for the customer, sales ($or #) per $ of the advertisement, and so on.

The manufacturing branch wants to see a) manufacturing efficiency, b) the percentage of total capacity used during a specified time period, and C) the percentage of raw materials or labor that produce finished marketable goods (saleablogoes).

In an exemplary embodiment of the invention, the system tracks the usage of the feedstock and thus may compare the amount of feedstock for each product multiplied by the number of marketable products to the amount of feedstock actually used. The difference is waste that can be evaluated, for example, to reduce the amount of waste produced per unit of product, to highlight the value of the waste to the recycler or material handler, and so forth. For the operator, calculating yield (yield) may provide an efficiency measure, and financial issues (financial observations) involved in improving yield may be analyzed (e.g., to explore whether replenishment of trucks and personnel is required if yield increases by a certain amount). The system also records the manufacturing capability and may compare the actual production to the manufacturing capability, for example, in accordance with the user's requirements for the system.

Exemplary embodiments of the system include specialized graphical screens that display the required metrics and their financial results in real-time. According to exemplary embodiments of the invention, the user may instruct the system to generate financial statements and other statements that include any business metrics required by the user.

As noted throughout this disclosure, exemplary embodiments of the system link financial and non-financial data directly together in an accounting system. This combination provides various benefits heretofore unavailable. One example is the keeping of the inventory. There are three basic categories of inventory: raw materials, semi-finished products (WIP), and finished products (FG). An exemplary embodiment of the system maintains an inventory of parts (pieces) or components in the inventory and the value of those parts. When the material is moved to the WIP, labor is increased, increasing the value of the material/component. When all of the labor has been added to the WIP element, it is moved to the FG. For each part, the system tracks the labor content (lab content) of the part when it is in WIP (or classified as WIP) and when the part is reclassified from WIP to FG.

According to an exemplary embodiment of the invention, the system may calculate a marginal cost of the inventory, wherein the marginal cost is a sum of variable costs associated with the inventory and does not include a fixed or indirect cost. For example, the indirect costs may include rental costs for houses and equipment. For example, the marginal costs may include the power required to run the machines that make the product, the cost of materials necessary to make the product, and any inventory taxes that may be imposed. The marginal cost of inventory may be useful when making business decisions. For example, if manufacturing and selling a first product includes a fixed cost, the corporate management may consider placing a price for a second product more aggressively because the profit for the second product is the sales price minus only the marginal cost (rather than a fraction of the indirect cost). In another example, the corporate management layer may use the marginal cost of inventory to set a minimum size of a production line (production run) such that a first portion of the production line includes indirect costs and the remainder of the production line is therefore considered to have a higher marginal profit margin.

Merging programs

For large companies with multiple business units, consolidating accounting is a very difficult task. Each business unit may have a different accounting system and often a different accounting chart. Known methods of merging include mapping one set of accounting sheet numbers to another set of accounting sheet numbers. This is an ongoing process as accounts are always added, deleted, transferred or renumbered.

According to exemplary embodiments of the present invention, two methods of consolidated accounting are provided, which may also be consolidated across multiple standards. For example, once the appropriate alternative control accounts are defined, one exemplary embodiment of the system automatically incorporates the U.S. GAAP, U.S. tax, and IAS (International accounting standards) within the system.

In the first merge procedure, it is assumed that both the Parent company (Parent) and the business entity use the system. If the GL account of a business unit is consistent with the merged GL, then the GL account from the business unit is directly mapped to the merged GL. However, there may be many accounts in a business entity GL that must be split or merged/combined to fit, or otherwise be consistent with, the merged GL. Alternative accounts can be used to accommodate such differences. An alternative account is provided and assigned for each business unit GL account other than the merged GL. The alternative account is mapped to an appropriate consolidated account so that the input into the business unit GL (general ledger) is the input into the consolidated account. The merging is done in real time if a real-time connection is provided between the business unit and the parent company. If the database transfer (transfer) is done on a batch basis, the consolidation is done automatically when the batch data is received. In an exemplary embodiment of the invention, the consolidated GL or the consolidation of the general ledger or the trial balance table only includes (but includes all) aggregated information from the accounts of the business units GL. The transaction details under the summary information are contained in accounts receivable and accounts payable modules, which may be located in the business unit, for example. In an exemplary embodiment of the invention, the user may select how much, and/or what type of data is to be reflected from the business units GL into the merged GL.

Fig. 8 shows an example where several business units each have some GL accounts different from the merged GL. As shown in FIG. C, the business units "division 1", "division 2", and "division 3" each have six GL accounts numbered 1-6. However, as shown in FIG. C, the division 1 has alternative accounts only for the GL accounts 2,5 (alternative accounts Alt-2, Alt-5). The division 2 has alternative accounts only for said GL-accounts 1, 6 (alternative accounts Alt-1, Alt-6). The division 3 has alternative accounts only for said GL-accounts 3-6 (alternative accounts Alt-3, Alt-4, Alt-5, Alt-6). In other words, the division 1GL accounts 1, 3, 4, and 6 are consistent with the merged GL, but accounts 2,5 are not. Thus, alternative accounts Alt-2, Alt-5 are provided. In the division 2, the GL accounts 1, 6 are not consistent with the merged GL, so alternative accounts Alt-1, Alt-6 are provided. In the division 3, GL accounts 3-6 are not consistent with the merged GL, so alternative accounts Alt-3, Alt-4, Alt-5, Alt-6 are provided.

The merging may be done in a similar manner if one or more of the business units are not using the system. The GL of the business unit can be transmitted and imported into the system by installing a Universal Converter (as described in co-pending application No. _____ entitled Method for Adding Metadata to data, entitled "Method for Adding Metadata data", filed at 3.4.2002 by the U.S. patent and trademark office, claiming priority to provisional application No. 60/312,788 in accordance with section 35 of united states constitution chapter 119 (35 u.s.c. § 119), and incorporated herein by reference) at the business unit. The generic converter outputs data in a file structure or format recognized by the system, for example in an XBRL (extensible business reporting language) compatible format. The GL for each business unit may then be transmitted to and automatically input into the system. Alternative accounts for each account may be formed in the same manner as previously described so that data entered into one book set may be automatically posted or reflected in any other book set of the company. All individual accounts are maintained independently and the consolidated book is maintained as well. This method may provide real-time consolidation, for example when linking the service unit data through a network.

In the second merge procedure, the account number is not used for merging. Instead, each account is provided with a merger number based on the nature of the account and the type of account number. The merge number indicates where data from the account with the merge number should be placed in the merge GL. In effect, the merge number maps data to the merge GL. Based on the nature and type of the account, the system may automatically pick a merger number for the account. Fig. 9 shows an exemplary process consistent with the second merge procedure.

In a first step 902 of fig. 9, the system determines the account type and account properties for each account.

Examples of different account properties include, but are not limited to, assets, liabilities, owner equity, profits, expenses, and sales costs.

Examples of different account types include, but are not limited to, cash, accounts receivable sales, other benefits of accounts receivable, inventory, stock stocks, semi-finished product stocks, accounts payable (e.g., purchases for stock), accounts payable (traceable), sales, MSGA payable (market development, sales, management (General)), MSGA expenditures, taxes, and so forth.

In the next step 904 of FIG. 9, the system assigns a merge number to the account based on the account attributes and account number type of the account. For example, the system may use a table that maps different combinations of properties and types to specific merge numbers. If no combination is found in the table, the system may request that the user indicate an appropriate merge number, and may remember the indicated association between the merge number and the particular property/type combination for future use or reference.

At next step 906, the system extracts information from the account. At next step 908, the system places the extracted information into a consolidated account or set of consolidated accounts based on the consolidated number of the account from which the information was extracted.

In other words, once the merger numbers are assigned to accounts, the accounts are then merged using their merger numbers (rather than their accounting statement numbers), according to exemplary embodiments of the present invention. Thus, the merge number provides a separate mechanism by which to automatically merge the accounts, whether the accounting entry number changes or new accounts are added or deleted.

For example, a merge taxonomy may be used to assign a merge. For example, the accounts may be automatically consolidated by installing a generic translator equipped with a consolidation taxonomy at the remote business unit. The consolidated taxonomy is organized by the account properties and account types, where each account property and account type is assigned a consolidation number. Each account to be consolidated is evaluated to discern the nature and type of the account. The identified nature and type are then used (via the taxonomy) as keys to find the appropriate merge number for the account, thereby mapping the account to an appropriate merge number. Once completed, the generic converter remembers the mapping for subsequent reporting. The changes for each account with a merge number may be mapped manually, and the data from the account and the merge number for the account are output together in a consolidated report (which may be provided or generated in an XBRL-compatible format), which is automatically transferred to the parent company, e.g., via FTP (file transfer protocol) or via a private network. At the parent company site, data from the received consolidated statement is entered into the system and automatically consolidated by means of the consolidation number.

For example, one such business unit accounting system may have a control account called "accounts receivable" and another business unit may have a control account called "A/R sales" and "A/R other revenue" and another business unit may have a control account at the customer level. To correctly map accounts of different names into the merged GL, they need to be mapped into the correct GL account. For example, if the merger number for A/R (accounts receivable) is "1" and it is desired to add all of the "A/R sales" (or A/R for all A/R customers) along with all other "A/R other returns" in the merger, they are all given the same merger number "1". The accounts will both map to the A/R in the merged GL.

Return to theAccounting title table concept, accounting title tables may be set in different ways. For example, an accounting title table may be set in the following format:

controlling accounts	Sorting account	Properties of	Type (B)
				Sales of A/R		Assets	Sales of A/R
	A/R customer 1	Assets	Sales of A/R
					A/R customer-n	Assets	Sales of A/R
A/R other benefits		Assets	Other benefits
					Bank 1. a/R interest inc	Assets	A/R other Inc.
	A/R LiInfor. -bank 2	Assets	A/R other Inc.
					Rent of A/R equipment 1	Assets	A/R other Inc.

In the above table, there are two control accounts, 1) A/R sales and 2) A/R other revenue. There are two ledgers (SL) that point to the A/R sales and are associated with the A/R sales control account. There are three SLs associated with the a/R other revenue control accounts, two of which point to a/R interest revenue and one of which points to a/R device rental revenue. All of the accounts display their account nature and account number type. Since we have a control account that aggregates all customer ledgers, we can view the total A/R from sales from the A/R sales control account. The same is true for the other gains for A/R. If customer 1 has two warehouses to which to ship, we can separate them by using attributes (e.g., a first attribute of warehouse 1 and a second attribute of warehouse 2).

Another method of setting the accounting title table is not to use the a/R sales control account and to make the customer level the control account level. The total A/R from all customers can thus be accumulated by creating and using an attribute center (e.g., an attribute center named "asset-A/R sales") to collect the A/Rs from all customers. This example case is shown in the table below. The table below shows the control accounts "A/R customer 1" and "A/R customer 2" for two particular customers, with ledgers named for the customer's warehouse location. Of course, the control account for each customer with the appropriate ledger would be included as well, but is not shown in the table below for simplicity. In the following table, the A/R other revenue control AccountThe user is present and unchanged to show that different methods can be mixed in the GL. If the user so desires, he or she may, for example, set a control account at the A/R interest profit level.

Controlling accounts	Sorting account	Properties of	Type (B)
				A/R customer 1		Assets	Sales of A/R
	Large warehouse of atlanta	Assets	Sales of A/R
					Reno warehouse	Assets	Sales of A/R
A/R customer 2		Assets	Sales of A/R
					Danfo warehouse	Assets	Sales of A/R
	Orlando warehouse	Assets	Sales of A/R
				A/R other benefits		Assets	A/R other Inc.
	Bank 1. a/R interest inc	Assets	A/R other Inc.
					A/R interest Inc. -Bank 2	Assets	A/R other Inc.
	Rent of A/R equipment 1	Assets	A/R other Inc.

According to an exemplary embodiment of the present invention, the general ledger transfer & adjustment statement is used in connection with the alternative control account. This statement provides a mechanism to record numerical changes between the default accounting criteria and the alternate control accounts, and to provide an audit trail for transfers and adjustments. The report may also be used to further clarify the numerical variations between general ledger accounts within the criteria.

Module

According to an exemplary embodiment of the present invention, the system includes a Planning Module (Planning Module) that can use the occurrence date or posting date when accessing historical data. The system may provide a schedule table including questions to be answered for a scheduled time period and answers to the questions at a previous time period and any reference time periods. The question includes the target outcome and the policy or policies that produced the outcome. For example, the user may provide a dollar amount or amount for end-of-term inventory or an inventory increase indicating the inventory turnover or as a percentage of sales. Either or both of these strategies will yield an end of term inventory value. The planned, previous and reference time period data may be graphically displayed, for example, using a button map (the graphic being generated by the system in response to user selection of a single button or icon). On the planning module, the user can also see a graphical representation of trends for any project. The user may also view a number of non-financial factors when planning. The proportional sales/(square root of retail space area) may be displayed, for example, for a planning period, a previous period, and a reference period. Likewise, the percentage of the manufacturing capacity or the corresponding market share can be displayed. The planning module may, for example, implement the goal and rule based functionality described further above, may be part of the module implementing the goal and rule based functionality described further above, or may be separate.

According to an exemplary embodiment of the present invention, the system includes a manufacturing capability module that allows a user to create and evaluate manufacturing capability metrics. For example, the system allows the user to compare sales to maximum plant throughput. This is possible because in one exemplary embodiment of the invention, the system tracks and compares financial and non-financial information. When planning sales, it is important to know whether the current capacity is sufficient to produce enough product to support the planned sales. If capacity is not sufficient, either additional manufacturing resources must be allocated or sales planning must be reduced.

The manufacturing capabilities of the company may be determined based on a number of factors. The assets, plant equipment, labor, utilization of raw materials, and utilization of financial resources used to fund the manufacturing process are all factors monitored by the system. In a static data module, the manufacturing capabilities of each machine or pipeline is a non-financial standard that is maintained, tracked, and/or monitored by the system. The size, skill and productivity of the staff is maintained, tracked and/or monitored in the human resources module of the system. In the inventory module of the system, purchase orders, including costs, quantities, and delivery dates of raw materials, are maintained, tracked, and/or monitored. The system also maintains, tracks, and/or monitors the company's financial resources, cash available for action, and credit. The system thus has information that supports the calculation of the capabilities. Of course, the system also has historical and projected sales data so sales can be compared to manufacturing capacity.

Finding and analyzing

The system database contains a number of information about the company, including financial information and non-financial information. For example, the non-financial information may include the number of employees, the square footage of the production equipment, the order date, and the shipping/receiving date, among others. To maximize the likelihood of collecting all important information from the database, including relevance, efficiency, etc., a search and analysis engine is provided. In an exemplary embodiment of the invention, the search and analysis engine is specifically designed to mine the database and submit reports based on specific requests or scheduled times. The lookup and analysis engine allows users to obtain reports simply and easily. One function of the lookup and analysis engine is to discover relationships in the data that may not be intuitive or obvious to the user. Another function would be to provide information for the target management system as described previously. In an exemplary embodiment of the invention, the lookup and analysis engine is specifically adapted to work with encryption or data security mechanisms incorporated into the system, such that the protection of data in the system database is transparent to the user.

The present invention may be embodied in other specific forms by those of ordinary skill in the art without departing from the spirit or essential characteristics thereof, and the invention is not limited to the specific embodiments described herein. For example, the concepts and mechanisms described herein may be particularly and generally applied to different database systems. The presently disclosed embodiments are therefore considered in all respects to be illustrative and not restrictive. The scope of the invention is indicated by the appended claims (rather than the foregoing description), and all changes that come within the meaning and range and equivalence of the claims are intended to be embraced therein.

Claims (11)

1. A method for organizing a plurality of accounts, comprising:

each account is assigned a label that includes a name label, an account property label, and an account type label.

2. The method of claim 1, comprising selecting the account property label from an account property label set, wherein the account property label set comprises assets, liabilities, revenues, expenses, owner equity, and sales costs.

3. The method of claim 1, comprising selecting the account type tag from an account type tag set, wherein the account type tag set comprises a liquidity asset, an accounts receivable, an accounts payable, a transaction income, a transaction expenditure, a working cash flow, a financing cash flow, and an investment cash flow.

4. The method of claim 1, comprising assigning an account classification label to an account.

5. The method of claim 4, comprising selecting the account category label from an account category label set, wherein the account category label set comprises a customer, a supplier, a rent, a utility, and a commission.

6. The method of claim 4, comprising assigning a sub-category label to an account.

7. The method of claim 6, including selecting the sub-category label from a set that includes details about elements in the account category label set.

8. A method for displaying financial data, comprising:

arranging the initial balance sheet sequence, balance sheet transfer and adjustment sequence, income sheet sequence, cash statement sequence and end balance sheet in a row side by side; and

all elements in each sequence are organized such that all corresponding elements in each sequence are arranged in the same row.

9. The method of claim 8, comprising organizing all elements in each sequence according to a standard ordering of one of the sequences.

10. The method of claim 9, wherein the standard ordering is a standard ordering of a sequence of end-of-term balance sheets.

11. The method of claim 9, comprising organizing all elements in each sequence according to a ranking selected by a user.