System and method for implementing a revenue recognition model

A system and method for implementing a revenue recognition model in an automated environment includes receiving rules, over a communications network, associated with an entity. Information associated with a transaction is received, and one or more automated processes are implemented to determine whether revenue from the transaction is recognizable.

TECHNICAL FIELD

This invention relates generally to accounting services, and more specifically, to a system and method for implementing a revenue recognition model.

BACKGROUND

The accounting and financial industries are always changing and evolving. New rules, regulations, and procedures to improve reporting have burdened the daily tasks of professionals. Conventionally, professionals expend extensive manual effort to ensure compliance with accounting rules, regulations, and procedures.

SUMMARY OF THE DISCLOSURE

In accordance with the present invention, disadvantages and problems associated with previous techniques for accounting services may be reduced or eliminated.

According to one embodiment of the present invention, a system and method for implementing a revenue recognition model in an automated environment includes receiving rules, over a communications network, associated with an entity. Information associated with a transaction is received, and one or more automated processes are implemented to determine whether revenue from the transaction is recognizable.

Certain embodiments of the invention may provide one or more technical advantages. A technical advantage of one embodiment includes decreasing the manual effort of professionals to comply with accounting rules, regulations, and procedures by providing a revenue recognition model in an automated environment. Another technical advantage of an embodiment includes providing a series of steps that allow for the proper classification and recognition of revenue for companies. Therefore, a user may need to input specific, limited information into the system, and the revenue recognition model determines whether revenue should be recognized without the user having to expend extensive manual effort.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1illustrates a system10for implementing a revenue recognition model (RRM) for an entity. System10includes endpoints12that communicate over a network14with subsystem16. During communication with endpoints12, subsystem16implements the RRM to facilitate accounting services.

System10facilitates implementation of the RRM for an entity, such as a business. The entity participates in transactions with customers. A transaction may include a sale, lease, or license of computer software or any other suitable transaction involving a product and/or service related to computer software. In an embodiment, the transaction includes products and/or services for customers that may be delivered over a period of time. The products and/or services provided to the customer may contain other bundled products and/or services. Bundled products include any suitable types of products that may be combined, such as hardware and software with continued licensing or maintenance. Bundled services include any suitable types of services that may be combined, such as training and installation. Customers include resellers, distributors, value-added resellers (VARs), end users, or any suitable customer. Entities may include companies or organizations in the software, technology, or consulting industries or any other suitable industry or endeavor that may implement the model.

Rules to recognize revenue are determined by the Securities and Exchange Commission (SEC). The SEC provides these rules through various regulations passed, such as Staff Accounting Bulletin Nos. 101 and 104. The American Institute of Certified Public Accountants (AICPA) has determined the Statement of Position (SOP) 97-2, which also includes rules to recognize revenue. SOP 97-2 governs the recognition of revenue for transactions involving computer software. According to Generally Accepted Accounting Principles (GAAP), an entity properly recognizes revenue for a transaction when the transaction meets the following five minimum requirements: (1) an arrangement or contract exists, (2) delivery of the product has occurred or services have been rendered, (3) the price is fixed or determinable, (4) collectibility is reasonably assured, and (5) multiple-element arrangements are defined. The RRM automates several decision points in the above-identified areas and provides a final authorization to improve an entities' ability to recognize revenue and properly record a transaction as current revenue on an income statement or as deferred revenue on a balance sheet. Deferred revenue is a liability account for customer-payment received, but not yet earned by the entity. The entity may earn the deferred revenue over time as it fulfills all of the obligations. Only when the entity actually earns the revenue does the revenue become current revenue.

According to the illustrated embodiment, system10includes endpoints12that communicate with each other and subsystem16through network14. For example, endpoints12communicate with subsystem16to facilitate the implementation of the RRM. Endpoints12may send any suitable signal to verify and approve processes implemented by the RRM. For example, endpoints12may send and receive data signals, audio signals, video signals, or any combination of the preceding to communicate in system10. Endpoints12may support any suitable communication protocol to facilitate communication with network12and subsystem16.

Endpoints12include any suitable hardware and/or software to communicate in system10. Endpoints12may include, for example, a personal computer, a laptop, or any other suitable device. Endpoints12also include any suitable display13that displays information generated by the RRM. For example, display13includes a monitor, a screen, or any other suitable display that displays information to a user. Through display13, the user may interact with the execution of the RRM using any suitable interface, such as a keyboard or a mouse. For example, endpoints12provide verifications21to subsystem16. Verifications21verify information about a transaction. Generally, endpoints12execute financial or accounting software that allows users to input information, perform calculations, run repots, or engage in any other suitable financial or accounting activity. For example, endpoints12may include personal computers in an accounting department, point-of-sale (POS) devices, servers, or other computing and/or communicating device at one or more locations.

Network14allows endpoints12to communicate with other endpoints12, networks14, or subsystem16. Network14may include a local area network (LAN), a wide area network (WAN), or any other public or private data network, a local, regional, or global communication network such as the Internet, an enterprise intranet, other suitable wireline or wireless communication link, or any combination of the preceding. Network14may include any combination of gateways, routers, access points, and any other hardware and/or software that may implement any suitable protocol or communication.

Subsystem16facilitates the provision of accounting services in system10by communicating with endpoints12. Subsystem16includes information about an entity that allows for the RRM to be applied to the information. Subsystem16may include any suitable hardware and/or software to facilitate the provision of accounting services. Subsystem16may refer to any server, hub, switch, router, gateway, or other suitable network component(s) that communicates information with endpoints12. In other embodiments, the functionality of subsystem16may be included in endpoints12, and each endpoint12may implement the RRM.

In the illustrated embodiment, subsystem16implements the RRM using an enterprise resource planning module (ERP module)18and a business process manager module (BPM module)20. The results of the RRM are provided to general ledger22. BPM module20includes revenue recognition model application (RRM application)24that implements the RRM. Subsystem16may include any suitable module or combination of modules that provide for implementation of the RRM.

ERP module18represents any suitable application that facilitates accounting services. ERP module18includes any suitable hardware and/or software having business rules and parameters associated with the entity to use in the RRM. The rules and parameters are entity-defined and may be changed at any suitable time. Exemplary rules and parameters include: the entity's accounting year, a list of personnel authorized to verify certain information, standard shipment terms, standard payment terms, standard customer acceptance terms, or a percentage price discount threshold. In an embodiment, ERP module18facilitates revenue accounting and determines timing of revenue. For example, ERP module18may include commercial software, such as PEOPLESOFT, PEACHTREE, or any other suitable accounting, financial, or business application.

BPM module20represents an application that interacts with ERP module18and general ledger22. BPM module20includes any suitable hardware and/or software to manage business processes. For example, BPM module20allows a user to implement business processes to improve efficiency. As another example, BPM module20allows a user to integrate existing business infrastructure. BPM module20may include any suitable application, such as the Interstage® Business Process Manager™ platform sold by Fujitsu® Limited.

In the illustrated embodiment, BPM module20includes RRM application24that executes processes to implement the RRM. RRM application24includes any suitable hardware and/or software that inputs, analyzes, ascertains, determines, and records the proper amount of current and deferred revenue in an automated environment based on accounting and/or financial data generated or processed in system10. In the illustrated embodiment, RRM application24includes questions26presented to endpoints12that allow RRM application24to receive information about a transaction.

RRM application24also estimates and schedules the exact amounts of deferred revenue by future accounting periods. RRM application24interacts with ERP module18to retrieve information to use in implementing the RRM. For example, financial parameters are identified in ERP module18and RRM application24retrieves the information from ERP module18. RRM application24may include any suitable process or number of processes that provide for the implementation of the RRM. RRM application24may be customized in any suitable manner to meet the specific needs of the entity. For example, RRM application24may include reminders specific to the entity.

As discussed above, endpoints12include a display13to display information. RRM application24may tailor the information to be displayed on display13to correspond to different job functions within the entity. For example, the information displayed on display13may correspond to job functions in the following areas: customer service, account management, sales management, credit management, and/or technical services.

General ledger22interacts with ERP module18and BPM module20. General ledger22is any suitable hardware and/or software that include financial information about the entity. General ledger22may include the revenue account of the entity and the deferred revenue account. For example, if RRM application24determines to recognize revenue for a transaction, general ledger22receives the output of RRM application24and includes the revenue in the appropriate account, either the current revenue account or the deferred revenue account.

In operation, ERP module18receives rules and parameters regarding the entity from a user. When a transaction occurs, RRM application24may be executed to determine whether to recognize revenue for the transaction. Endpoints12may provide verifications21to subsystem16to verify information about the transaction. A series of questions26regarding the transaction are presented to the user. Questions26may be automatically generated when the transaction occurs, at the time of book entry, or at any suitable time. RRM application24uses the responses to determine whether to recognize revenue. In an embodiment, questions26may contain simple true/false questions that pertain to a specific line item within a transaction. For example, questions26may include the following: did the customer accept the product, does the customer have the right to use the product, is the customer the end-user, are there special payment terms, or any suitable question that provides for determining information about the transaction. Certain responses may trigger more detailed questions. System10contemplates any number, type, and level of questions presented to the user regarding a transaction to implement the RRM.

If RRM application24does not receive an answer within a specified period of time, RRM application24may initiate automatic timers to remind the user to provide an answer and to allow the process to proceed. The timer may be programmed to repeat question26on any suitable basis, such as hourly, daily, or weekly until resolved. Because the process does not continue until RRM application24has the necessary information, unauthorized or premature recording of revenue is ensured not to occur and the rules and parameters of the entity are followed while enabling an accurate recording of revenue.

When questions26are answered, RRM application24implements additional processes and provides an output, which is current revenue and/or deferred revenue from the transaction. An authorized user may review and approve the output of RRM application24. General ledger22records the current and/or deferred revenue in the appropriate account when RRM application24receives approval.

Modifications, additions, or omissions may be made to system10inFIG. 1. For example, subsystem16may include any suitable component or module that facilitates the provision of accounting services to the entity. As another example, ERP module18may include general ledger22rather than including general ledger22in a separate module. As yet another example, BPM module20may receive rules, parameters, and financial data from a user, rather than interacting with ERP module18. Moreover, the operations of system10may be performed by more, fewer, or other components. The components of system10may be integrated or separated according to particular needs. Any suitable logic comprising software, hardware, other logic, or any suitable combination of the preceding may perform the functions of system10.

FIG. 2is a block diagram illustrating a configuration of ERP module18. ERP module18includes databases that store information for RRM application24to retrieve and use in determining whether to recognize revenue. In the illustrated embodiment, ERP module18includes an order entry database30and a general ledger22, which further includes accounts receivable (A/R) database36, revenue database38, and other suitable databases that include accounting information of the entity.

Order entry database30stores information for transmission to RRM application24. The information in order entry database30includes transactions of the entity. The transactions are populated manually or automatically as the entity accounts for a transaction for products and/or services. Order entry database30may organize the transactions in any suitable format. Order entry database30includes any suitable database operable to store information.

As mentioned above, general ledger22includes A/R database36and revenue database38. General ledger22represents any suitable accounting database that includes a summary of all transactions that occur in the entity, such as assets, liabilities, expenses, revenue, losses, gains, and owner's equity.

A/R database36stores data regarding the accounts receivables of the entity. Accounts receivables represent transactions regarding the billing of customers that owe money to an entity. A/R database36includes any suitable database that stores accounting information. A/R database36may organize the information in any suitable manner. For example, A/R database36may organize the information according to the customer or according to the age of the transaction.

Revenue database38stores information regarding the revenue of an entity. Revenue database38includes any suitable database that stores revenue information. Revenue database38may organize the revenue information in any suitable manner. For example, revenue database38organizes the revenue based on the revenue type, such as current revenue40and deferred revenue42.

In operation, order entry database30and A/R database36provide information to RRM application24for RRM application24to use in implementing the RRM. RRM application24performs the various processes and determines whether to recognize revenue. RRM application24recognizes the revenue as current or deferred revenue and updates general ledger22. For example, if current revenue is recognized, RRM application24updates current revenue40, and if deferred revenue is recognized, RRM application24updates deferred revenue42.

Modifications, additions, or omissions may be made to ERP module18. For example, ERP module18may include other databases, such as a purchasing database, a sales database, a licensing database, a maintenance database, or a services database that provide inputs to order entry database30. As another example, the databases may be organized in any suitable manner. Moreover, the operations of ERP module18may be performed by more, fewer, or other components. Any suitable logic comprising software, hardware, other logic, or any suitable combination of the preceding may perform the functions of ERP module18.

FIG. 3is a flowchart300illustrating implementation of the RRM by RRM application24. RRM application24receives rules and parameters for the entity at step302. The rules and parameters serve as the general framework within which RRM application24operates. At step304, RRM application24determines whether a new transaction is entered into ERP module18. Transactions may be entered automatically from endpoints12, such as a POS or manually. If ERP module18does not have a new transaction, RRM application24continues to monitor ERP module18for new transactions. If ERP module18does have a new transaction, RRM application24receives information related to the transaction at step306.

RRM application24receives the information from ERP module18. The basic information may include any suitable type of information that properly identifies the transaction. For example, basic information may include customer name, customer identification number, transaction date, amount, products and/or services, current date, a description of the transaction, customer type, agreement type, or other suitable information. Retrieving the basic information from ERP module18saves significant time and effort, rather than manually duplicating the information for RRM application24to use.

RRM application24also receives inputs, also referred to as verifications21, to verify the information received from ERP module18at step307.FIG. 4below illustrates a more detailed flowchart of the verification process. In an embodiment, these verifications21include information from a customer service representative, information from a revenue accountant, and information from an account manager or credit account manager. For example, a revenue accountant may verify a signature is by an authorized person on the transaction. A customer service representative may verify the accuracy, completeness, and validity of the transaction. Also, a credit account manager may verify the payment terms and credit worthiness of the customer associated with the transaction. RRM application24determines the appropriate user(s) in the entity to verify the information and the user(s) can access the information from one or more endpoints12. RRM application24may identify more than one user to verify different types of information and may communicate the different types of information simultaneously to the users. Any one of these identified user(s) can take the desired action based on this information to move the process forward. RRM application24may communicate the information according to pre-set timers and/or actions taken by users as part of the RRM process.

Upon receiving verifications21or while still awaiting verifications21, RRM application24provides questions26to various departments regarding the transaction at step308. For example, the sales department handles questions26regarding data activity of the transaction, such as special terms, estimated start and completion dates, special contingencies, or related transactions. The technical services department may handle consulting data activity, such as providing information regarding training and installation. Also, the customer service department may verify the specific information of the transaction, such as accurate pricing, correct descriptions, correct shipping information and delivery instructions, and the customer's right to use the product or service. If system10does not receive a response for each question26as determined at step310, the method determines at step312whether to terminate RRM application24. If RRM application24does not terminate, the method continues from step310until each response is received. Otherwise, RRM application24terminates and the method ends.

If RRM application24receives a response to each question26, the method continues from step314where RRM application24implements a fee description process, as described inFIG. 6. The fee description process includes any suitable process that determines the fees involved in the transaction. For example, system10determines a fee type, resolves any contingency surrounding the fee, and applies any concessions. The fee description process also considers the type of customer involved in the transaction. For example, if the customer is an end-user, the method continues. If the customer is a reseller or distributor, the method may not continue until the reseller or distributor makes a binding sale to an end-user.

RRM application24also implements a collectibility process at step316. The collectibility process includes determining whether the customer is creditworthy and reliable and whether the nature of the transaction would provide for recognizing revenue.FIG. 7, below, illustrates the collectibility process in further detail.

The multiple-elements process is implemented at step318.FIG. 8illustrates the multiple-elements process in further detail. The multiple-elements process considers any discounts applied to the transaction. The process considers various aspects of the discount, such as the percentage of the discount. A sub-process also considers whether the transaction involves a barter, as described with respect toFIG. 10. A barter is the non-monetary exchange of goods and/or services. If the transaction includes a barter, additional processes are implemented to determine whether to recognize revenue.

At step320, RRM application24determines whether current revenue is recognized according to the above processes, which include receiving verifications21and receiving a response to each question26to confirm the existence of an arrangement or contract and to confirm delivery of the product has occurred or services have been rendered, verifying the fee, implementing the collectibility process, and implementing the multiple-elements process. If current revenue is recognized, RRM application24requests approval to recognize the revenue in general ledger22at step321. System10determines whether approval is received from a user at step322. If the user approves the recognition of revenue, RRM application24updates general ledger22at step324. For example, RRM application24updates current revenue40in revenue database38to include the revenue and removes the transaction from A/R database36. If the user does not approve the recognition of revenue, the application ends.

If RRM application24does not recognize current revenue at step320, RRM application24determines whether deferred revenue is recognized at step326. If no deferred revenue is recognized, the application ends. The process continues from step322when deferred revenue is recognized. At step322, a user determines whether to approve the recognition of the deferred revenue. RRM application24updates general ledger22at step324if an approval is received or ends the application if an approval is not received. Updating general ledger22to include deferred revenue may include updating deferred revenue42in revenue database38to include the deferred revenue and removing the transaction from A/R database36.

Modifications, additions, or omissions may be made to flowchart300. For example, timers may be initiated throughout the process to remind the user to answer questions26or provide information for the RRM to continue. As another example, each process described in the RRM may determine any suitable information to allow for an accurate recognition of revenue. As yet another example, any suitable component may implement RRM application24and perform any or all of the steps of the application. Although described in a particular sequence, flowchart300may perform steps serially or in parallel in any suitable order.

FIGS. 4-12illustrate detailed flowcharts that the RRM may implement. Any suitable component of system10may implement the steps as illustrated inFIGS. 4-12. Although described in a particular sequence, system10may perform the steps of the flowcharts serially or in parallel and in any suitable order.

FIG. 4is a flowchart illustrating verifications21system10receives from users in an entity. RRM application24gets data from ERP module18regarding a transaction, received as a purchase order (PO). Various users in the entity verify information in the PO. A revenue accountant may verify the signature on the PO, a customer service representative may verify the PO data, and a credit manager may enter the credit information associated with the PO. When the information is verified and entered, system10processes the line items in the PO and continues with the implementation of RRM application24. If the information is not verified, such as the signature on the PO, system10terminates RRM application24.

FIG. 5is a flowchart illustrating an evidence of arrangement process of the RRM. The evidence of arrangement process confirms that a transaction exists. Various users in the entity provide information regarding the transaction. For example, a sales manager may provide transaction data, a vice-president of sales may enter the contract data, a technical services representative may enter consulting data, and a customer service representative may verify the transaction data. If the information is properly entered and there is an evidence of acceptance of the transaction, the process continues to a fee description process as described inFIG. 6. However, if there is no evidence of acceptance or there is not a right-to-use, RRM application24may terminate.

FIG. 6is a flowchart illustrating a fee description process of the RRM. During the fee description process, system10determines the fees of the transaction, including determining whether any concessions or contingencies exist. The fee description process is a sub-process of the evidence of acceptance process. A user in the entity may resolve the concessions and contingencies, such as a vice-president of sales. If system10cannot resolve the concessions or contingencies, RRM application24terminates. Otherwise, the fee description process continues by determining the type of customer involved in the transaction, such as a reseller, an end-user, or other suitable customer. If the customer is not a reseller or a reseller agreement exists for a reseller, the process continues to a collectibility process.

FIG. 7is a flowchart illustrating a collectibility process of the RRM, which is a sub-process of the fee description process. During the collectibility process, system10determines whether an entity may reasonably rely on a customer to fulfill the terms of the transaction. If system10determines the fees are not collectible, RRM application24terminates. Otherwise, system10implements the multiple-elements process.

FIG. 8is a flowchart illustrating a multiple-elements process of the RRM. During the multiple-elements process, system10determines whether discounts are applied to the transaction. The process determines the number of products to which a discount applies and gathers discount information. Following this process, system10implements an other arrangements process.

FIG. 9is a flowchart illustrating an other arrangements process. During the other arrangements process, system10determines whether miscellaneous arrangements exist. For example, if a barter arrangement exists, a barter process, as described with respect toFIG. 10, is implemented. As another example, the other arrangements process implements an authority matrix, as described inFIG. 11, to verify the revenue recognized. As yet another example, the other arrangements process implements the final review process, as described inFIG. 12, to finally review the recognizable revenue before entry into general ledger22. As depicted inFIG. 9, system10may terminate RRM application24during the other arrangements process.

FIG. 10is a flowchart illustrating a barter process. The process determines whether the transaction involves a non-monetary exchange. Even if the transaction is a barter, revenue may still be recognizable. System10implements this process to determine whether a non-monetary exchange may involve recognizable revenue.

FIG. 11illustrates an authority matrix system10implements to determine whether to continue with the process of updating general ledger22. System10may implement the authority matrix for any suitable reason and using any suitable technique. If system10does not implement the authority matrix, a revenue accountant may approve or reject whether to recognize the revenue. However, if the system implements the authority matrix, various users within the entity approve or reject the recognition of revenue. Depending on the amount of the transaction, senior personnel within the entity may approve the transaction. For example, if the transaction is less than $1000, only the approval of an accountant may be needed. Alternatively, if the transaction is more than $1000, the approval of a senior accountant in addition to the accountant is needed. This process through the authority matrix may continue for transactions surpassing $1 Million. If the revenue is recognizable, system10determines whether to implement the final review process, as described inFIG. 12. If any user rejects the transaction, a sales manager verifies the rejection. If the sales manager agrees with the rejection, the authority matrix terminates. If the sales manager overrides the rejection and approves the transaction, the transaction returns through the authority matrix.

FIG. 12is a flowchart illustrating final review of recognizable revenue. A revenue accountant reviews the recognizable revenue. The revenue accountant may review immediately when the review is requested, or defer review until a later time. When the revenue accountant reviews the recognizable revenue, the accountant confirms whether to recognize the revenue and update general ledger22or determines that the revenue is not recognizable. If the revenue is not recognizable, RRM application24terminates. If the revenue is recognizable, system10updates general ledger22.