Embodiments of the present invention relate to computerized accounting systems and, more particularly, to such systems that operate pursuant to specialized accounting procedures that might be required, for example, by governmental agencies and the like.
Public sector organizations such as government agencies are required to record their financial transactions with a greater degree of specificity than, for example, private firms. Thus, accounting procedures that govern the records for private firms are not completely satisfactory for these public sector organizations because they record incomplete information regarding the organizations' activity. In a private firm, for example, only the actuals may be recorded on a general ledger. A government agency, however, may be expected to also record budget related activities on the general ledger. In the United States, regulations promulgated pursuant to the Joint Financial Management Improvement Program (JFMIP) define the accounting procedures for such entities.
Many Enterprise Resource Planning (ERP) vendors sell to these government agencies various computerized financial products, which are designed to support their financial management. Often, these financial products create financial documents from original transaction documents for accounting purposes. These financial documents are required to conform to the accounting procedures, such as the JFMIP, imposed on the government agency. Among various financial products provided by ERP vendors, a budgetary ledger is one of the most often tested components in selecting one of these financial products. Often, the budgetary ledger maintains account balances for budget relevant processes or transactions. The budgetary ledger is typically interactive with a general ledger, which maintains account balances for not only the budget relevant transactions, but also the actuals, receivables, and other types of transactions, to ensure that the agency is managing the funds pursuant to defined limitations. Put differently, the budgetary ledger may post budget relevant transactions to the general ledger to maintain account balances for budget related transactions.
SAP AG, the assignee of the present invention, included a budgetary ledger unit in prior versions of its R/3 product that handled the reporting requirements for governmental organizations. The budgetary ledger unit, however, was deemed cumbersome for its users. For each transaction, the budgetary ledger unit required an operator to manually cycle through a master configuration table to selectively indicate which of a universe of possible predecessor conditions apply to a given reporting requirement and to derive applicable accounts. FIG. 1 is an illustration of an exemplary master configuration table used by the budgetary ledger unit in prior versions of its R/3 product. The table has seventeen different data fields for each transaction. The budgetary ledger has to maintain values for all of the seventeen data fields, and compares each transaction against all of the data fields to determine relevant accounts. As a result, only one or two relevant accounts are typically expected. Thus, it is very difficult to set up and maintain the configuration table. It is cumbersome and time consuming to perform the account derivation using the master configuration table. Further, this budgetary ledger unit is suitable for use with only one nation's reporting requirements (currently, the United States). Although other nations are instituting similar recording requirements or are expected to do so, the prior version of the R/3 product is not suited for ready extension to accommodate such reporting requirements.
Accordingly, there is a need in the art for a computerized accounting system that provides for easy configuration of public sector reporting requirements and is readily applicable to multiple different recording policies.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates an exemplary master configuration table used by a known budgetary ledger.
FIG. 2 illustrates a budgetary management system operating in accordance with embodiments of the invention.
FIG. 3 illustrates an exemplary budgetary ledger structure according to an embodiment of the present invention.
FIG. 4 illustrates a method for budgetary transaction management using the budgetary ledger shown in FIG. 3 according to an embodiment of the present invention.
FIG. 5 illustrates an exemplary budgetary ledger area determination according to an embodiment of the present invention.
FIG. 6 illustrates an exemplary line pair generation according to an embodiment of the present invention.
FIG. 7 illustrates a simplified block diagram of a computing platform in an embodiment of the invention.
Embodiments of the present invention provide a computerized accounting system that satisfies the enhanced reporting requirements that are defined for public sector organizations. One embodiment of the present invention comprises dividing the budgetary ledger into two components, a core and an extension set. The core provides services necessary to call a general ledger (or an accounting interface) of the system. The extension performs account derivation. By dividing the services necessary to create budgetary ledger documents, embodiments of the present invention provide a flexible and user convenient way to configure a budgetary ledger. This structure also permits extension to other reporting requirements by changing only the extension set. The two systems cooperatively determine, from transaction data, how many different accounts there are to record the transaction.
FIG. 2 illustrates a typical budget management system 200 according to an embodiment of the present invention. The budget management system 200 may be provided as a component of a larger financial management system. The budget management system 200 may include transaction modules 210, such as a material management module, a financial module, and a budget module. These transaction modules 210 may process data representing various transactions that an organization performs during the usual course of business such as payrolls, budgeting, purchase requisitions, purchase orders, goods receipts, invoices, and the like. Typically, the computer systems record these transactions in “documents.” The original transaction documents generally include data representing one or more transactions being performed by a public sector organization. These original transaction documents are fed into a funds management unit 220, which determines whether the organization possesses sufficient funds for such transactions.
In general, the funds management unit 220 may verify that the funds to be distributed do not exceed the amount of funds available for allotment or sub-allotment at a given distribution level. To do so, the funds management unit 220 may record related budgetary documents and control the use of funds against appropriation and administrative limitations. The funds management unit 220 also may record and control the types of budgetary authority, including appropriations, spending authority, and borrowing authority. Thus, when the original transaction documents from the various transaction modules 210 are received, the funds management unit 220 may check each document and may determine whether the organization possesses sufficient funds for a particular transaction.
The budgetary ledger unit 230 determines whether transactions are to be recorded in the general ledger database 250. The budgetary ledger unit 230 compares transaction data to various transaction conditions to determine if they are to be recorded. If so, the budgetary ledger unit 230 identifies accounts to which the transactions are to be recorded and generates “line pairs” for recording in a budgetary ledger document. The budgetary ledger document may be stored in a financial module 240. The financial module 240 then posts the budgetary ledger document to the general ledger database 250. The general ledger database 250, among others, creates a history of budgetary ledger information.
FIG. 3 is a functional block diagram of a budgetary ledger 300 according to an embodiment of the present invention. The budgetary ledger 300 may include a core 310 and an extension set 320. The core 310 may administer the creation of account “line pairs” for recording and may maintain the consistency of the resulting budgetary ledger document. The extension set 320 may tailor operation of the budgetary ledger 300 for operation in a given accounting scheme. For example, one extension set may define reporting policies and accounts for U.S. governmental agencies. Another extension set may define corresponding policies and accounts for governmental agencies of other nations. By engaging an appropriate extension module, one may tailor the operation of the budgetary ledger system 300 for any number of prescribed reporting policies. Furthermore, the structure of this embodiment may ease the set up and maintenance of the budget related transaction data pursuant to the reporting policies. Thus, embodiments of the present invention may provide a user convenient tool to configure the budgetary ledger area.
In an embodiment, the core 310 may further include a transaction processor 330, an iteration unit 340 and a merger unit 350. The extension set 320 may include a budgetary ledger area determiner 360 and an account derivation unit 370. These units cooperate to develop account line pairs from transaction documents generated by a funds management unit.
The transaction processor 330 defines an interface to the funds management unit and the budgetary ledger area determiner 360. From a document, the transaction processor 330 may identify various transactions represented therein. Once the document is received, the transaction processor 330 may determine which transaction(s) in the document require reporting to the general ledger based on their transaction data. For each transaction to be reported, the transaction processor 330 then may forward appropriate transaction data, such as a transaction type, a value type, and the like, to the budgetary ledger area determiner 360. As previously mentioned, the document may be payment documents, down payment documents, invoices, goods receipts, purchase orders, commitments, travel requests, sales and distribution orders, forecasts of revenue, purchase requisitions, pre-commitments, funds reservations, and the like.
The budgetary ledger area determiner 360 may receive the transaction data from the transaction processor 330. The budgetary ledger area determiner 360 may then determine which budgetary areas the document falls into. A budgetary ledger area is a collection of accounts that are associated with a higher-level business process. The budgetary ledger area may typically be defined with a budgetary ledger area name and a predetermined set of accounts.
The budgetary ledger area determiner 360 may provide a table/list that includes triggering conditions for each budgetary ledger area. The triggering conditions must be satisfied for a particular transaction to be reported in a given budgetary ledger area. For example, such triggering conditions may be defined by the type of fund, the timing of the transaction, and the like. A transaction in the document may hit one or more different budgetary ledger areas so long as the transaction satisfies the triggering conditions defined for these budgetary ledger areas. For example, a transaction involving a computer purchase in a purchase order may fall into both the “Expended Appropriations” budgetary ledger area and the “Miscellaneous Receipt” budgetary ledger area. As a result, the budgetary ledger area determiner 360 may return the number of the budgetary ledger areas that each transaction in the document hits and the names of identified budgetary ledger areas.
The iteration unit 340 may receive the identified number of budgetary ledger areas, their names, and the transaction data associated with each transaction in the document from the budgetary ledger area determiner 360. For each hit in the budgetary ledger area, the iteration unit 340 may call for the account derivation unit 370 using the budgetary ledger area name. For example, if one transaction of the document falls into two budgetary ledger areas, the iteration unit 340 calls the account derivation unit 370 two times, once for each budgetary ledger area. Each time the account derivation unit 370 is called, it may perform account derivation for the given budgetary ledger area.
The account derivation unit 370 may receive the budgetary ledger area name and the transaction data from the iteration unit 340. The account derivation unit 370 may then determine the associated account(s) to which the transaction is to be recorded and generate a line or a line pair for recording in the identified account(s). Each budgetary ledger area may require different logic for the account derivation and usually different account ranges. The logic for determining the budgetary ledger area, to where each transaction of the document has to be posted, may be different from the logic for deriving the associated accounts. As a result of the account derivation, the account derivation unit 370 may retrieve up to two accounts.
In one embodiment, once the line or line pair is generated in the accounts, these accounts may be stored in a budgetary ledger document. The budgetary ledger document is then stored in the financial module, which forwards it to the general ledger database.
In another embodiment, a merger unit 350 may be connected to the account derivation unit 370 and may define an interface to the financial module. The merger unit 350 may receive the accounts that are associated with each budgetary ledger area. Once all the accounts relating to all of the budgetary ledger areas are received, the merger unit 350 may then determine if any accounts may be merged together. The merger unit 350 may also determine if any accounts from different transaction documents could be merged together. Whether two accounts may be merged will be governed by the accounting procedures imposed on a particular agency. If permitted, the merger unit 350 may sum up the values of matching accounts. The merger unit 350 may, in turn, reduce the number of line pairs in the budgetary ledger document, and facilitate easier maintenance of the budgetary information.
FIG. 4 illustrates a method of generating budgetary line pairs according to one embodiment of the present invention. Responsive to the transaction data and the identified transaction type(s), the method may determine if the transaction requires reporting (box 410). If not, the method may perform no further actions (box 420). If so, the method may compare the transaction data to the budgetary ledger area triggering conditions. As previously mentioned, some transactions may require reporting in more than one budgetary ledger areas. Thus, when the transaction requires reporting, the method may determine which budgetary ledger areas the transaction falls into and the names of identified budgetary ledger areas (box 430).
For each hit in the budgetary ledger areas, the method may identify the associated account(s) within the budgetary ledger area (box 440). Different transactions may be related to different number of accounts. Embodiments of the present invention may fall within two general cases:
the transaction may be related to one account, and thus, may create exactly one account document line when the document is self-balanced; and
the transaction may be related to two accounts, and thus, may create a line pair, one line in each of the two accounts, for balancing purposes.
Typically, most transactions require two lines to be generated. Thus, the method may then generate a line in each of the identified account(s) (box 450). The method repeats the process of identifying associated account(s) and generating a line or line pair for each of the identified budgetary ledger area.
Optionally, once the line or line pair is generated in the identified accounts, the method may determine if it may be merged with any other line with the same account (box 460). The agency's reporting will govern whether a given transaction may be posted individually or as a summary. If it is allowed to post some transactions as a summary, the merged line is applied to a specified account and a budgetary ledger document is created therefrom (box 470).
A representative example for generation of a budgetary ledger document according to an embodiment of the present invention is set forth below with reference to FIG. 3. Consider a transaction which creates two original documents with three line items listed as follows:
Cost Center = “X”, Fund = “A”
Cost Center = “Y”, Fund = “B”
Cost Center = “Z”, Fund = “B”