Abstract:
A system and method for calculating variable consideration for performance obligations. The method can involve, checking a database for historical transaction data, accessing the historical transaction data, and applying one or more predetermined variable consideration rules to the historical transaction data. The method can include automatically analyzing the historical transaction data generating an analysis report based on the data. The method can include uploading predetermined corrections to variable consideration transactions to a database or other storage medium and applying the corrections to historical performance obligation transaction data. The method can include determining whether variable consideration changes should be applied to individual transaction lines within the variable consideration transactions.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims priority to U.S. Provisional Application No. 62/106,095, filed on Jan. 21, 2015, and entitled “A Novel Approach To Meeting Global Financial Standards,” the contents of which are entirely incorporated by reference herein. 
     
    
     FIELD 
       [0002]    This disclosure, in a broad sense, is directed toward a system, method and apparatus for accurately determining an entity&#39;s financial position. More specifically, this disclosure relates to accurately identifying revenues for recognition. 
       BACKGROUND 
       [0003]    Entities and organizations must understand their financial positions, as well as be able to accurately report such information to appropriate parties, shareholders, owners, etc. However, as the number and complexity of transactions and agreements for a company grows, it can become increasingly difficult to do this accurately. 
         [0004]    A report can consist of, for example, a financial statement. The general purpose of financial statements is to provide information about the financial position, performance and changes in financial position of an enterprise that are useful to a wide range of users in making economic decisions. According to the Financial Accounting Standards Board (FASB), “a statement of financial position provides information about an entity&#39;s assets, liabilities, and equity and their relationships to each other at a moment in time.” 
         [0005]    One aspect of financial reporting is detailing when an organization may recognize the revenue it has acquired. Generally, revenues are not recognized until they are earned or in other words, “realized.” According to FASB guidelines, “revenues are considered to have been earned when the entity has substantially accomplished what it must do to be entitled to the benefits represented by the revenues.” The general concept behind these guidelines is to “recognize revenue to depict the transfer of promised goods or services to customers in an amount that reflects the consideration to which the entity expects to be entitled in exchange for those goods or services.” 
         [0006]    The FASB identifies five steps that an entity must follow to recognize revenue: (1) identify the contract with a customer; (2) identify the performance obligations (promises) in the contract; (3) determine the transaction cost or “fair value; (4) allocate the transaction price to the performance obligations in the contract; and (5) recognize revenue when (or as) the entity satisfies a performance obligation. For an entity having large numbers of transactions and agreements of differing types and complexity, accurately and quickly recognizing revenue can be extremely challenging. Currently, there are no systems or methods available which can adequately meet these challenges. Thus, there is room for improvement in the art. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]    Implementations of the present application will now be described, by way of example only, with reference to the attached Figures, wherein: 
           [0008]      FIG. 1  illustrates a method  100  of recognizing revenue in accordance with an embodiment of this disclosure; 
           [0009]      FIG. 2  illustrates an example user interface for customizing aspects of a performance obligation; 
           [0010]      FIG. 3  illustrates an example user interface for accounting for and reporting costs; 
           [0011]      FIG. 4  illustrates an example user interface for assigning variable consideration; 
           [0012]      FIG. 5  illustrates an example user interface for configuring various forecasting options within a performance obligation template of this disclosure; 
           [0013]      FIG. 6  illustrates a user interface displaying a hierarchy of rules and conditions according to an embodiment of this disclosure; 
           [0014]      FIG. 7  illustrates a user interface providing functionality for customizing variable consideration parameters; 
           [0015]      FIG. 8  illustrates a user interface for applying multiple variable consideration parameters; 
           [0016]      FIG. 9  illustrates a user interface displaying a variable consideration template; 
           [0017]      FIG. 10  illustrates an example user interface in accordance with an embodiment of this disclosure; 
           [0018]      FIGS. 11-12  illustrate cost template windows within example user interfaces in accordance with one or more embodiments of this disclosure; 
           [0019]      FIG. 13  illustrates another user interface within this disclosure; 
           [0020]      FIG. 14  illustrates a method of calculating variable consideration in accordance with an embodiment of this disclosure; 
           [0021]      FIG. 15  illustrates a method of analyzing variable consideration in accordance with an embodiment of this disclosure; 
           [0022]      FIG. 16  illustrates an example workbench user interface in accordance with an embodiment of this disclosure; 
           [0023]      FIG. 17  illustrates information displayed under an overview tab of the workbench user interface; 
           [0024]      FIGS. 18A-J  illustrate additional user interfaces of the workbench module; 
           [0025]      FIG. 19  illustrates a system configured to perform one or methods of this disclosure, and to provide one or more functionalities set forth in this disclosure. 
       
    
    
     DETAILED DESCRIPTION 
       [0026]    It will be appreciated that for simplicity and clarity of illustration, where appropriate, reference numerals have been repeated among the different figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the implementations described herein. However, it will be understood by those of ordinary skill in the art that the implementations described herein can be practiced without these specific details. In other instances, methods, procedures and components have not been described in detail so as not to obscure the related relevant feature being described. Also, the description is not to be considered as limiting the scope of the implementations described herein. 
         [0027]    Aspects of this disclosure can take the form of hardware elements, software elements or elements containing both hardware and software. In one implementation, the software portions can include, but are not limited to, firmware, resident software, microcode, etc. Furthermore, these software portions can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium (though propagation mediums in and of themselves as signal carriers are not included in the definition of physical computer-readable medium). Examples of a physical computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD. Both processors and program code for implementing each as aspect of the system can be centralized or distributed (or a combination thereof) as known to those skilled in the art. 
         [0028]    Aspects of this disclosure can include a data processing system suitable for storing program code and for executing program code, which can be implemented in any of the above-referenced devices described herein, can include at least one processor communicatively coupled directly or indirectly to a memory through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories that provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution. I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be communicatively coupled to the system either directly or through intervening I/O controllers. 
         [0029]    Aspects of this disclosure are directed to complying with accounting standards, such as those set forth in ‘FASB Accounting Standards Update, No. 2014-09, May 2014,’ the contents of which are entirely incorporated by reference herein. 
         [0030]    Several definitions that apply throughout this document will now be presented. The word “module” can include software or firmware having a particular purpose, and/or the system(s) running the module. The terms “processor” and “processing unit” are defined as a component or a group of components that are capable of receiving input signals, or other data, processing those signals and selectively signaling other components to respond to such input or data. The term “electronic device” includes, but is not limited to, devices such as computers, personal computers, laptop computers, smart phones and PDAs. The term “revenue contract” includes “a grouping of one or more transactions for revenue accounting purpose as per applicable accounting guidelines or user policy.” The term “user” includes, but is not limited to, client devices used to implement aspects of this disclosure, and persons using such devices. The term “performance obligation” includes a promise in a contract to transfer a good or service (to a customer, for example). The term “client device” includes one or more electronic devices which can communicate with systems of this disclosure, receive information from one or more systems of this disclosure, or transmit information to such systems. 
         [0031]    An embodiment within this disclosure can include a revenue management module for managing the timing, amount and amortization method of revenue recognition. The embodiment can also enable users to manage cost of goods sold, commissions, rebates, accruals and royalties, and the like. A revenue management model can be adaptable and customizable for the needs and circumstances of a particular entity. A revenue management model can be configured in accordance with an entity&#39;s revenue policies and business rules in order to track revenue and facilitate automated revenue recognition. 
         [0032]    An embodiment can include a revenue allocation module which can automate calculations, such as the ‘Fair Value’ calculation (VSOE, TPOE, BESP) as set forth in relevant accounting guidelines. A revenue allocation module can perform revenue allocations required under appropriate accounting standards, rules, and regulations. A revenue allocation module can automatically allocate and track all calculations at a transaction level, thereby giving transparency and traceability to the expected adjustments. Automated allocation and tracking of calculations at a transactional level can facilitate the presentation and analysis of useful revenue data than allowed using traditional methods, such as complex spreadsheets, for example. 
         [0033]    An embodiment of this disclosure can include a revenue forecasting module which can deliver a large compliment of operational reports, such as those which are required at the ends of financial periods. A financial period can be a month, a quarter or a year, or a combination of these three, for example. A revenue forecasting module can be used to generate reconciliation reports and revenue waterfalls, for example. Such reports can be beneficial during financial analysis of an organization, such as during an audit, for example. 
         [0034]    An embodiment can further include a revenue intelligence module. A revenue intelligence module can enhance the operational reporting capabilities of institutions. A revenue intelligence module can provide performance analytics dashboards on the display of an electronic device. Such a module can thus provide key decision makers with timely and accurate revenue visibility and metrics. The revenue intelligence module can render useable information on pre-formatted, user-customizable, reports and/or dashboards. 
         [0035]    From the time an agreement for services or products is reached, until the time performance by all parties is completed, revenue accounting is affected at each stage. Companies need accurate revenue information throughout the revenue accounting life cycle. At least one embodiment of this disclosure is a system and method to identify and extract all required information from source systems, such as external data sources and externally executed programs, to accurately track and report revenue throughout revenue accounting life cycles. 
         [0036]      FIG. 1  illustrates a method  100  of recognizing revenue. Method  100  can begin by identifying  102  one or more contracts for analysis. Identifying contracts  102  can include grouping  104  of transactions. Once contracts are properly identified  102  and/or transactions appropriately grouped  104 , the method  100  can proceed to block  106 , at which performance obligations (POBs) are identified. Identification of performance obligations can entail creating or modifying/deleting  108  POBs, applying variable consideration  110 , calculation of other costs  112  associated with the POB, and applying forecast rules  114 . The method  100  can then proceed to block  118 . At block  118  transactions costs (associated with a POB) are determined  116  and a fair value of the transaction or a fair value of aspects of the transaction(s) is assigned  118 . Method  100  then moves to block  122 . At block  122  transactions costs are allocated  120  according to a fair market value. Once fair market values have been allocate  122 , the method proceed to block  124 , in which revenue is recognized. Recognizing revenue  124  can involve releasing  126  revenue and accounting  128  for revenue. Thereafter, the method  100  proceeds to block  130 , in which recognized revenue is posted. Once recognized revenue is posted  130 , the method  100  proceeds to block  132 , in which recognized revenue is reported. Although steps of the method  100  are provided in a certain order, it will be understood that a different order, involving the same, additional or fewer steps, can be implemented in one or more embodiments within this disclosure. 
         [0037]    Also illustrated in  FIG. 1  are various functionalities  134  which can be provided by one or more systems of this disclosure, and aspects of which can be applied and/or utilized as part of method  100 . The functionalities, which are described in greater detail below, include, but are not limited to, a variable consideration analyzer  136 , contract modification  138 , and a revenue workbench  140 , SSP Analyzer, Mass Actions, Netting Process, each of which can be comprised within one or more modules. An SSP Analyzer can incorporate a unique calculation which identifies appropriate SSP when provided a set of transactions. Mass actions is a method used to perform various actions on one or more transactions/data within the software. Netting Process is a method to perform accounting adjustments as per revenue accounting guidelines (ASC  606 /IFRS  15 ). As noted above, in at least one embodiment of this disclosure, a performance obligation can be a promise in a contract with a customer to transfer a good or service to the customer. Appropriate accounting guidelines require that if an entity promises to transfer more than one good or service, the entity should account for each promised good or service as a separate POB only if it is distinct. An embodiment of this disclosure can include a POB configurator, which consists of preconfigured setups related to how a POB can be defined by providing details such as how revenue can be released; how revenue can be recognized based on the various ratable methods; how to override the release events; whether a POB can be released/applied manually (as opposed to automatically); how cost can be treated for a POB in a manner similar to revenue; defining forecasting at a POB level; and assigning Variable Consideration (VC) at another level of computation apart from transaction line level, such as a POB level. Such preconfigured setups can be included in one or more templates. 
         [0038]      FIG. 2  illustrates an example user interface (UI)  200  for customizing aspects of a POB. As shown, a user can specify a particular release event  202 , a particular ratable method  204 , and a particular accounting method  206 . In order to enable accounting for each promised good or service as a separate POB (as when they are distinct), a user can indicate that the relevant quantities are distinct  208  and/or that the term of the POB has a distinct term  210 . 
         [0039]      FIG. 3  illustrates an example UI  300  which enables a cost to be accounted for and reported at a POB level. In at least one embodiment, an application can also account for details related to a cost at a POB level. Thus, under the cost treatment tab  302 , information such as cost type  304 , release event  306 , accounting method  308 , ratable method  310 , accounting duration  312 , company  314 , department  316 , cost center  318 , account (identifier)  320 , and expiry base  322  can be displayed. 
         [0040]      FIG. 4  illustrates an example UI  400  for assigning variable consideration (VC) at a POB level. As shown, the VC type  402 , application type  404 , the amount to apply  406 , and the triggering event  408  for applying the VC assignment can be specified. 
         [0041]      FIG. 5  illustrates an example UI  500  for configuring various forecasting options within a POB template. Under revenue forecast tab  502  there can be seen a date hierarchy window  504  and a schedules window  506 . As illustrated, the date hierarchy window  504  enables selection of an appropriate adjustment period  508 . The schedules window  506  enables the anticipated revenue recognition schedule to be customized. 
         [0042]    In an embodiment of this disclosure, POB rules are defined to associate transaction lines in a revenue contract to a POB template (see  FIGS. 2-5 ). A user can be provided the ability to configure POB rule conditions. Users can also be provided with criteria filters, which enable users to define their own criteria in order to meet the needs of their particular business or situation. A POB rule can have multiple conditions for associating transaction lines to a POB template. A condition, in turn, can have primary and secondary criteria filters, thereby making the condition more robust. Rules and conditions are applied on the transactions lines based on the sequence associated with the transactions lines. In one embodiment, once a transaction line has met a certain rule-defined criteria, no additional rules are applied to the transaction line.  FIG. 6  illustrates a UI  600  displaying a hierarchy  602  of rules and conditions. As shown, a POB criteria window  604  of the UI  600  can enable user-selection of a leading indicator. 
         [0043]    As intimated above, aspects of this disclosure pertain to determination of variable consideration (VC). According to relevant accounting rules, if the promised amount of consideration in a contract is variable, an entity should estimate the transaction price by using either the expected value (that is, probability-weighted amount) or the most likely amount, depending on which method is a better indicator. Within this disclosure, VCs can be defined and assigned at a POB level or at a transaction level (depending on the needs of the situation). A VC configurator module can consist of a VC type module, a VC stratification(s) module, and a VC upload module. With regard to the VC type module, an organization can setup various VC types based on their business model. An embodiment can include a user interface to help business users in configuring multiple VCs types. An embodiment can provide the ability to define the computation method of a VC, and define how to account for the VC amounts as and when they are applied.  FIG. 7  illustrates how a user can be given multiple options of how a VC can be configured to impact specific amounts such as revenue  702  or allocated amounts  704 , and impact how to compute  706  the VC (based on a Gross or Net basis).  FIG. 8  shows how a transaction line can have multiple VCs  800  applied. As illustrated, if multiple VCs  800  exist, they are applied in a hierarchical matter  802 . A VC stratification configures how a VC type is applied on transaction lines. A VC stratification specifies an apply type (which includes option to apply a given VC by percent or by amount). 
         [0044]      FIG. 9  illustrates a UI  900  having an example VC stratification window  902 . The window  902  allows a user to specify an “apply type”  904  (in this case “percent”) and to specify a “calculation level” (gross amount). UI  900  also includes a criteria window  906 . The criteria window  906  is used to identify which transaction lines are eligible for VC assignment based on the criteria defined and mapped to a given POB. Uploading of VC information can be achieved either manually or automatically. 
         [0045]    As noted above with regard to  FIG. 1 , POB identification can involve calculation of other costs. According to applicable accounting guidelines, incremental costs of obtaining and fulfilling a contract with a customer are to be capitalized and amortized on a systematic basis consistent with the pattern of the transfer of the goods or services to which the asset relates. In addition to being able to account for standard costs like product cost, embodiments of this disclosure enable accounting for other costs (such as commissions, royalties, etc.) This additional capability can enable users to track different types of costs associated with a transaction and determine how those costs. At least one embodiment addresses the issue of changing costs, as in for example, estimated cost versus actual cost realized, as well as offline cost calculations. 
         [0046]      FIG. 10  illustrates a UI  1000  having a cost type window  1002 . The cost type window  1002  provides a method to define multiple costs that an organization needs to account for as part of their revenue contracts with customers. As part of the cost type configuration, users can define the GL accounts for the cost entry as well as designate which costs should be included as part of standard margin  1004 . 
         [0047]      FIG. 11  illustrates a cost template window  1100 . The cost template window  1100  can be used to define how a cost (other costs) is be calculated based on a transaction/product characteristics The window  1100  includes options for electing to apply cost type by percent or by amount (“apply type”  1102 ), dynamically deriving the value and computing other cost types (“apply on”  1104 ). The “apply on” menu is useful because a transaction line can have multiple fields storing amounts. A “calculation level”  1106  enables a user to elect either gross or net level. A criteria window  1108  is used in identifying which lines are eligible for a cost calculation based on criteria defined and mapped. 
         [0048]      FIG. 12  illustrates a second cost template window  1200 . Actual percentages or amounts, as defined by the cost template, can be uploaded into the system based on which other costs are being computed. To support an upload, the system provides the flexibility to create a batch  1202  and upload the file for calculation, thereby providing the status  1204  of an upload and any further processing as needed. 
         [0049]    At least one embodiment of this disclosure enables robust and configurable forecasting. Forecasting helps in estimating future revenue outcomes of a transaction or a POB.  FIG. 13  illustrates a UI  1300  for this purpose. As shown in  FIG. 13 , a forecast hierarchy  1302  and a forecast schedule  1304  can be configured at a POB level and then further applied to all lines associated with the relevant POB. Waterfall reports can also be provided to show revenue projections. Multiple date hierarchies  1302  can be configured and a schedule  1302  can be associated therewith, as shown. 
         [0050]    As noted above, at least one aspect of this disclosure pertains to a variable consideration (VC) manager module. A VC manager module can include comprise a VC calculator module and a VC analyzer module. 
         [0051]      FIG. 14  illustrates a method  1400  carried out by a VC calculator module. A VC calculator can enable users to: derive VC estimates based on historical data; define stratification parameters to analyze historical data; define date range to analyze historical data; decide whether to include or exclude “one off” transactions; run different tiers of stratifications to compare; and approve stratifications to be used in transaction price adjustments. At block  1402  the system checks for the existence of historical data. If no such data exists, the historical transactions are loaded  1404 . The system then applies variable consideration rules  1406  to the historical data. The method  1400  then proceeds to block  1408  in which analysis of historical data is performed. An analysis report can then be generated  1410 . The method proceeds thereafter to block  1412 , in which such report is rendered or displayed for user viewing. Based on the results of the report, a determination  1414  can be made as to whether to apply the variable consideration rules to new transactions. If the answer is ‘yes,’ variable consideration (VC) estimates and variable consideration ‘actuals’ can be loaded  1416  into a VC group for subsequent use. If the answer is ‘no,’ such information can be loaded  1418  by other means, such as one or more spreadsheets. The method  1400  can then end. 
         [0052]    A VC analyzer resolves the issues that arise when estimates of VC were provided during the prior periods and were applied to the transactions, however, after a certain period, actual costs are provided or estimates contained incorrect values. A VC analyzer can help identify all impacted transactions (BULK/Transaction Level Processing) due to the change and apply the correct values across all the transactions or a specific transaction. The system will automatically, reallocate all the transaction lines by reallocating the transaction price in the revenue contract and perform retrospective/prospective accounting. A VC analyzer can allow users to analyze, manage and adjust existing VC&#39;s on transactions. A VC analyzer can provide users with the ability to analyze VCs applied on transactions. A VC analyzer can also: provide mass updates to adjust them based on actuals or new estimates; provide upload option to load actual costs; and generate reports used to analyze VC amounts. 
         [0053]      FIG. 15  illustrates a method  1500  carried out by a VC analyzer module. The method  1500  begins at block  1502  in which corrections to VC transactions are uploaded and applied. Corrections can be automatically applied by the system or manually by a user via UI. The system then checks to see if transactions are available for corrections. If not, the method  1500  returns to block  1502 . If transactions are available for corrections, the method proceeds to block  1506  in which identified transactions are reviewed. The determination is then made as to whether VC changes should be applied to transactions lines. If VC changes are not to be applied, the method  1500  can end. Otherwise, the method proceeds to block  1510  in which VC changes are applied to transactions lines as appropriate. The method  1500  then proceeds to block  1520  in which reallocation of TP on impacted retrospective considerations (RCs) is performed. The method  1500  then proceeds to block  1530  in which retrospective accounting or prospective accounting, or both, are performed. Accounting entries can then be posted  1540  and thereafter changes made earlier during the method are reported  1550 . The method  1500  can then end. 
         [0054]    In an embodiment within this disclosure, the system can he configured to receive transactions from a source system in a transaction currency and calculate transactional amounts in a base currency (or operating currency) and reporting currency. When the amount of revenue recognized for a revenue contract is greater than the billed or invoiced amount, the exchange rate for that day or for that period will be used to convert from transactional currency to the reporting currency. When a contract liability is created for a revenue contract, a netting process can be executed to offset a contract asset. In this process, the contract asset will be reversed using the exchange rate used to book the contract asset originally and the offset account (contract liability) will be booked using the exchange rate it was created as part of billing/invoicing. Since both side entries may use different exchange rate, the difference in conversion will be booked to a financial exchange (FX) Gain/Loss account. Alternately, when a transaction consumes the contract liability of another transaction, the exchange rate for the day of the transaction or for that period can be used to convert the revenue on the target transaction. The contract liability on the source transaction can thereafter be released using its historical exchange rate. In at least one embodiment, a target line will consume its self-referencing liability, before the target line will consume liability from other lines. 
         [0055]    A system of this disclosure can provide a ‘workbench’ UI  1600 . A purpose of the workbench UI  1600  is to provide a complete and detailed view of a revenue contract.  FIG. 16  illustrates an example of a workbench UI  1600 . As can be seen in  FIG. 16 , revenue contracts and revenue progress for such contracts can be sorted and searched by customer  1602 . The progress column  1604  shows the revenue released as of current date.  FIG. 17  illustrates information displayed under an overview tab  1700  of the workbench UI  1600 . As shown, overview tab  1700  provides a holistic view of various data elements pertaining to a specific revenue contract in a single screen. For example, the total amount of revenue accrued to certain date can be displayed in a revenue gauge  1702 . Revenue corresponding to specified periods can be provided in a waterfall format  1704 . 
         [0056]      FIGS. 18A-J  illustrate various UIs available through a workbench module/UI  1600 . 
         [0057]      FIG. 18A  and  FIG. 18B  illustrate information and functionality provided under a transactions tab  1800  of the workbench UT  1600 . The transactions tab  1800 , for example, displays information about a given revenue contract. Information or data displayed under the transaction tab  1800  can include, but is not limited to: a rollup of all transaction lines mapped to POBs; a rollup of all sales order transaction lines which linked to a particular contract line; delivery of goods and services; and association information of SO/Contract Lines with POB. The transactions tab  1800  can include various subtabs. Every line in the transactions tab  1800  can identified by an indicator, such as an icon. For example, under the POB name subtab  1802  an ‘A’ icon  1804  can indicate an item was generated by the system (automatically). An ‘M’ icon (not shown) can indicate an item was created manually (by a system user; for example). An ‘S’ icon  1808  denotes a sales order line, a ‘C’ icon  1810  denotes a contract line, and an ‘L’ icon  1811  denotes a leading indicator line. As intimated above, the leading indicator line is the line which drives revenue recognition.  FIG. 18C  displays variable consideration (VC) data which has been processing based on a particular VC configuration. As illustrated, VC data can include percentages  1810  of revenue realized for a given line. 
         [0058]      FIG. 18D  illustrates waterfall information  1812  being displayed at line level. A waterfall can be generated to correspond to various cost types and revenue types, for example.  FIG. 18E  illustrates an example of accounting information  1814  generated based on revenue released  1815 . In the example of  FIG. 18E , accounting information  1814  is displayed below at line level. Such accounting information  1814  can also be displayed at a POB level. As illustrated in  FIGS. 18E-G , the workbench UI  1600  can also enable display of various waterfall types  1816  (commission, revenue, standard cost, for example) at a revenue contract  1820  level, under the waterfall tab  1822 .  FIG. 18H  shows accounting information  1824  for a revenue contract  1826  displayed by the workbench UI  1600  in a summarized format. As shown in  FIG. 18H , the workbench UI  1600  can display a user-selectable icon  1828 , which upon selection, can cause the accounting information  1824  to be displayed in a detailed format.  FIG. 18I  illustrates the accounting information  1824  displayed in a detailed format  1826 .  FIG. 18J  illustrates information displayed under a revenue summary tab  1826  by the workbench UI  1600 . 
         [0059]      FIG. 19  illustrates a system  1900  that may correspond to or may be part of a network component, such as a server, a switch, a router, or any other network nodes, and which can be used to execute one or more methods or run one or more modules set forth in this disclosure. The system  1900  includes a processor  1902  (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage  1904 , read only memory (ROM)  1906 , random access memory (RAM)  1908 , input/output (I/O) devices  1910 , and network connectivity devices  1912 . The general-purpose network component  1900  may also comprise, at the processor  1902  and or any of the other components of the general-purpose network component  1900 . 
         [0060]    The processor  1902  may be implemented as one or more CPU chips, or may be part of one or more application specific integrated circuits (ASICs) and/or digital signal processors (DSPs). The processor  1902  may comprise a central processor unit or CPU. The processor may be implemented as one or more CPU chips. The secondary storage  1904  is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM  1908  is not large enough to hold all working data. Secondary storage  1904  may be used to store programs that are loaded into RAM  1908  when such programs are selected for execution. The ROM  1906  is used to store instructions and perhaps data that are read during program execution. ROM  1906  is a non-volatile memory device that typically has a small memory capacity relative to the larger memory capacity of secondary storage  1904 . The RAM  1908  is used to store volatile data and perhaps to store instructions. Access to both ROM  1906  and RAM  1908  is typically faster than to secondary storage  1904 . 
         [0061]    In the preceding specification, various preferred implementations have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes can be made thereto, and additional implementations can be implemented, without departing from the broader scope of the disclosure as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.