Core Functional Requirements for Fiscal Management Systems
Author: Ali Hashim1 and Bill Allan2
  • 1 0000000404811396 Monetary Fund
  • | 2 0000000404811396 Monetary Fund

This paper presents a framework for planning the development of computerized government budgeting and accounting systems in economies in transition and developing economies. It argues that a comprehensive framework is needed to enable fiscal management issues to be addressed effectively, then outlines a methodology for planning systems development and proposes strategies for implementing the methodology in transitional and developing economies.


This paper presents a framework for planning the development of computerized government budgeting and accounting systems in economies in transition and developing economies. It argues that a comprehensive framework is needed to enable fiscal management issues to be addressed effectively, then outlines a methodology for planning systems development and proposes strategies for implementing the methodology in transitional and developing economies.

I. Introduction

Computerization presents new opportunities for public sector financial management, but it also brings new challenges. Computer-based information systems offer the possibility of rapid compilation of data on transactions from widespread locations and generation of many different report formats to suit the needs of policymakers and line managers at different levels. Implementation of computer-based information systems and the rapid rate of change in the associated technology, however, pose many difficult choices in design and implementation of systems and require acquisition of new skills. The broad technical requirements of such systems are essentially the same for all countries. Countries differ markedly, however, in their capacity to implement systems that meet all technical requirements; and the strategy for implementation must accordingly be adjusted in line with these capacities.

At the broadest level, distinctions may be drawn between the industrialized economies of the OECD, the DCs, and EITs. In the first group, there are adequate resources and considerable experience in developing such systems over the past several decades. Numerous problems have been experienced in developing integrated government budgeting and accounting systems in OECD countries. These have included technical questions of compatability between different components of management systems and issues of overall management of complex system development projects. Many of these issues are now being addressed more effectively, and part of the content of this paper is derived from the accumulated experience of developing systems in OECD countries. 1/

DCs, as might be expected, face much tighter constraints than do the OECD economies in applying EDP technology to their budgeting and accounting systems, and, apart from some oil-exporting DCs, few have been able to develop integrated computerized systems. Among the major constraints that most DCs face are a lack of administrative and technical skills, uncompetitive wage levels for skilled staff in government service, and uncoordinated decision-making processes. Very often, the fiscal reports drawn from the accounting system in DCs produce budget reports that are unreliable and too late for decision making. A common response in such circumstances is to circumvent the central accounting system and either use ad hoc data or set up special systems to meet specific problems—for instance, relying on banking data for timely assessment of the budget deficit, setting up stand-alone debt management systems, or establishing special arrangements for accounting for development projects. These approaches may meet the particular needs for which they are designed, but frequently they rely heavily on external technical assistance and are not maintained after the assistance is terminated. More importantly, such forms of assistance tend to weaken the development of the basic budgeting and accounting systems.

The EITs face yet a different set of problems. In general, the public sector in these economies has a supply of trained staff, many of whom have some experience with computers. The administrative and financial management systems, however, are designed for implementing a central plan—not for managing a budget in a market-oriented economy. The key requirement in these countries is to redesign basic control requirements, define processes, and develop systems that are appropriate to the new environment. Since one of the key management problems facing these economies is to exercise strict control over the size of the budget deficit, developing such systems has a special urgency.

For each of the above groups, there is a need to define clearly the scope of the CGBAS to ensure technical consistency and efficiency in the processes and flows of data, and to set priorities over which aspects should be given priority in systems development. They differ in their starting points for systems design and in the resources available. A basic premise of this paper is that the underlying business processes are sufficiently similar that a common methodology—a generic budgeting and accounting systems approach—can be applied. The second section of this paper describes this methodology. In the third section, strategies for applying the methodology to EITs and DCs are discussed.

II. Methodology

The approach taken in this paper is, first, to carry out a functional analysis of the business processes involved in government fiscal management. Second, this functional analysis is used as the basis for defining the information architecture, which is derived by analyzing the strength of information linkages among the functional processes and describes the information requirements for these processes. All data generated are, as a result, grouped into distinct information areas. The information architecture is the base upon which the systems architecture can then be defined. The type of data in each information area, together with the nature of the functional processes and the information flows between information areas, determine the nature of the applications software and selection of hardware required to support government fiscal management. 2/

1. Functional analysis

The functional requirements of information systems for government budgeting and accounting will depend upon:

  • The overall regulatory framework for fiscal management;

  • The functional processes associated with fiscal management; the information requirements for these processes; the information flows between functional processes; the nature, volumes, and frequency of these flows; and the geographical distribution of information sources.

a. Overall regulatory framework

The overall regulatory framework for operation of the various component modules of a CGBAS consists of the following elements: (1) the control structure; (2) the accounts classification; and (3) the reporting requirements. The information systems will need to incorporate features to ensure that they abide by the requirements of this framework. Therefore, the regulatory framework needs to be in place—possibly, reviewed and modified—before productive work can commence on the design of computer systems to support fiscal management. A full discussion of the overall regulatory framework is outside the scope of this paper. However, this paper does describe the basic elements of this framework to highlight control factors that should be incorporated in the design of component system modules.

(1) Control structure

Many of the basic controls that are to be applied to the use of government funds are derived from a legislative framework, very often with basic principles laid down in financial provisions in the constitution. Controls are defined at several levels: formal legislation and regulation, the structure of funds and appropriations, and administrative practices. Financial legislation and administrative regulations specify the detailed requirements for control to ensure that transactions are properly authorized and documented and that appropriation authority is not exceeded. Within most legislative frameworks, receipts of governments are paid into a fund (which will herein be referred to as the consolidated fund (CF) 3/ and any expenditure from the fund must be formally appropriated by the legislature. Regulations, administrative instructions, and administrative practices specify the standards and procedures to be followed for transaction processing. These include (1) document and transaction level controls to ensure correct processing, full and correct recording, and audit trails; (2) access controls to ensure that only authorized personnel can record, change, or report information; and (3) overall system controls to ensure that the system embodies the established processing standards.

Formal regulatory frameworks in the Western industrialized economies have generally evolved at a time when the predominant interest was to ensure that the executive arm of government used public funds properly and within the limits authorized by the legislature. Legislative developments have not always kept pace with the needs of modern economies, where the concerns of fiscal management are much broader. In particular, the roles of the budget in macroeconomic management and the efficient allocation of resources to meet social and economic objectives are as important as the traditional compliance role. Defining such needs and designing control systems to meet them is particularly important for the EUITs.

From a systems design point of view, the macroeconomic management objective has a direct bearing on definition of the control structure. It is necessary to look beyond controls specified at a legislative level and the traditional compliance role of the accounting system. For fiscal management, the overall deficit of the general government and the way in which this deficit is financed are crucial variables. It is vital that all elements of the budget and accounting information system be designed to produce this information in a timely way, to facilitate the formulation and execution of macroeconomic policy.

The resource allocation aspects of fiscal management are reflected in systems design primarily through appropriate budget and accounts classification and reporting specifications, which are discussed in the following sections.

(2) Accounts classification

The accounts classification code structure is a methodology for consistently recording each financial transaction for purposes of expenditure control, costing, and economic and statistical analysis. A standard, government-wide classification code structure needs to be set up to provide a consistent basis for:

  • Consolidating government-wide financial information;

  • Integrating planning, budgeting and accounting;

  • Capturing data at the point of entry throughout the government;

  • Compiling budget allocations and program and project costs within and across various government agencies.

The design of the accounts classification structure should, therefore, be determined by the information requirements for each of the above objectives. In principle, this structure should accommodate the following elements: fund, program, organization unit, project, and object of expenditure classifications. Program codes should identify program elements and supplements down to the basic program decision units. Similarly, organization codes should identify budget and cost centers. Projects can be related either to organizations or programs, but should be further subclassified independently of these structures in terms of subprojects, jobs, and functions. The object classification should serve both administrative and economic classifications and be divided into subcategories for control purposes. The object classification should also be consistent with economic classification codes used for generating national accounts or government finance statistics.

(3) Reporting requirements

Governments must specify reporting requirements and objectives in two areas: (a) external reporting—to provide information to the legislature and the public, as well as other countries, international organizations, overseas investors, and financial markets; and (b) internal management reporting—for government policymakers and managers. In general, the broad requirements for external reporting are specified in the budget legislation and detailed requirements are given in regulations, instructions, and administrative practice (e.g., report formats actually in use).

From the point of view of resource allocation, increasing emphasis has been given in recent years to improving reporting standards by linking financial and performance information and giving a clearer perspective on resource use by using accrual-based reports in addition to the usual cash-based government accounts. Development of such report formats is, in general, occurring mainly in the industrialized market economies. Nonetheless, it is suggested that the design of the CGBAS budgeting and accounting in any country should take into account, to the extent possible, the likely development of such report formats in the future.

b. Functional processes of government budgeting and accounting

The functional processes associated with government fiscal management and the information requirements for these processes have been described in publications of the Bank, the IMF, and other organizations (see references). The functional processes carried out by the central government 4/ in the areas of budgeting and accounting—and linkages to the control framework—are illustrated in Chart 1, and the main elements are briefly described below.

Chart 1:
Chart 1:

Functional Analysis, Control Framework, and Functional Processes

Citation: IMF Working Papers 1994, 027; 10.5089/9781451844450.001.A001

As indicated in Chart 1, the functional processes of budgeting and accounting can be categorized as those carried out by the central agencies and those carried out by the spending ministries and agencies. Those of the former group are most directly linked to the control framework—indeed, one of the main functions of the central agencies (particularly the ministry of finance (MOF) is to ensure that the control framework is properly applied throughout government. The functional processes cover three interrelated areas: (1) budget preparation and approval; (2) budget execution and cash management; and (3) accounting and audit.

(1) Budget preparation and approval

Chart 1 shows the budget preparation processes carried out by the central agencies in the column titled “Budget and Cash Management Processes.” The processes that take place at sector agencies that deal with the preparation of estimates for programs and projects that constitute the sectoral work programs (public sector work program or PSWP) are shown in the column titled “PSWP Management.”

At the start of the budget cycle, the central agencies (generally the Ministry of Finance) send the sector agencies a budget circular indicating economic prospects and broad policy objectives (in some cases, based on a formal macroeconomic framework paper), and giving the parameters within which the budget for each ministry is to be prepared. The circular may give specific ceilings for expenditure by each agency and program. The sector agencies respond with their budget proposals. As indicated in Chart 1, the financial information in these proposals should be categorized (a) by type of expenditure—as per budget classification and, at the broadest level, distinguishing recurrent from capital expenditures; and (b) according to whether they are continuations of programs approved under existing policy or are new project proposals.

Since budget requests generally exceed resources, negotiations between central and sector agency staff at the technical level are required to review costings for existing programs and new project proposals. Cabinet level (or cabinet committee level) discussions are often required to set priorities among the project proposals and select those that can be funded within the macroeconomic framework. The framework should be updated frequently, particularly during budget initiation and finalization, as well as for subsequent reviews during the year.) As a result of these discussions, a draft budget document is prepared.

After preparation by the executive branch, the legislature reviews the estimates and approves the budget. The duration of legislative consideration and degree of change that can be introduced at this stage vary considerably among countries.

This approved budget then becomes the legal basis of the PSWP to be executed by the sectoral ministries. It gives estimates of expected revenue and borrowing and the amount of expenditure—by budget and accounts classification—that is authorized to be spent on approved programs and projects. It usually contains data on past expenditures and may also contain descriptions of programs and projects and data on expected performance during the year. (As discussed below, the approved budget may be modified in the execution phase by supplementary appropriation (requiring legislative approval) or by virement—shifts of resources within the approved total—with the approval of the central agencies).

At the start of the year, sector agencies prepare forecasts of cash requirements for the year, based on known and anticipated commitments for both recurrent and capital expenditures. These forecasts highlight information on firm commitments and the foreign exchange component (if any) of anticipated expenditures. The cash requirements and revenue projections obtained from the agencies responsible for revenue collection are developed into a consolidated cash flow forecast by the Ministry of Finance.

(2) Budget execution and cash management

Once the budget is approved, the MOF has the task of controlling the release of funds, monitoring progress on budget implementation, and managing the cash resources of the government. From the start of the financial year, the MOF releases funds (warrants/cash allocations) periodically to sector agencies, keeping in view the approved budget, the sector agency cash requirements, and the overall resource availability. As the fiscal year progresses, the sector agencies prepare monthly/quarterly requests for funds and submit actual expenditure (and revenue) statements for the previous month/quarter. Capital expenditure warrants are allocated to specific projects.

Warrants authorized by the MOF are sent to the unit (the treasury, the accountant general’s office (AG), or its equivalent) that is the custodian of the CF—hereinafter referred to as the treasury. The warrant either authorizes the treasury to make payments out of the CF or authorizes the treasury to make money available for payment by the responsible accounting officers of the sector agencies. The latter can be achieved either by giving authority to debit the central government account or subaccount) or by crediting separate bank accounts (which are nonetheless under overall treasury control) of the ministries in the central bank (CB) or authorized service banks.

On receipt of the warrant authority from the MOF and access to funds from the treasury, sector agencies begin implementing the approved programs and projects. The line agencies start using the appropriated funds by requisitioning, procuring, and paying for goods and services.

A typical sequence of administrative steps for the acquisition of goods and services is shown in Chart 1. 5/ The first step is the placing of purchase orders for the goods and services—and recording the resulting commitments in the accounting system. The second step is the acquisition of goods and services. After work is completed or services rendered, bills are received; spending agencies then verify the receipt of goods and the accuracy of the bills. The third step is the preparation of payment vouchers, which are then passed to the treasury for review and, upon approval, issue of a check of payment order. 6/ Where payment is decentralized, however, ministries may issue payment orders directly; these may be drawn on a central account or a ministry account—depending on whether control of bank accounts is also decentralized. The payment orders are thereafter paid by the bank.

To ensure proper expenditure control, sector agencies are required to institute a system of commitment planning and control to ensure that (a) expenditure does not exceed the sum approved by parliament for specific purposes; and (b) expenditure is within the warrant amounts. The latter element of expenditure control is often used by the MOF/treasury to ensure that expenditures do not exceed actual resources (which may be less than estimated in the budget). When a receipt shortfall occurs, it is essential that the treasury be aware of the commitments (e.g., statutory payments, such as public debt, staff salaries and allowances, unpaid bills and existing contractual obligations) for which cash is needed during the year.

The spending ministry staff—or treasury staff assigned to this task—are responsible for steps one and two. At step three, the issuing of the payment order, many of the above processes have to be scrutinized again, possibly including the following verifications: the identity of the spending officer, the availability of budget provisions, the exact budgetary imputation, the verification of the receipt of goods and services, and the observation of financial regularity.

Receipt transactions are also shown in Chart 1, in a very simplified form. Again, detailed processes of administration and collection would need to be specified for a full functional process analysis—these, too, would generally be set up as separate subsystems of the CGBAS.

Tax revenue from customs duties, income, excise, and land taxes is managed by the revenue collection agencies; it is deposited in local commercial banks and remitted to the government’s central account in the CB. The CB then sends a daily report to the treasury on inflows to this central account.

Nontax revenue from fees, administrative charges, and product sales (e.g., products made in prison) are also managed by the collection agencies and transferred to the CF.

The basic processes involved in government accounting are (a) maintaining records of spending authorizations at the appropriation and funds - release (warrant levels); (b) processing transactions—recording the transactions as they occur, applying the requisite controls, posting to the appropriate account, and listing transactions and associated data for control and audit; and (c) maintaining ledger accounts to monitor and control actual spending and receipts against budget and warrant controls.

As discussed in Section 2b below, accounting information from these processes is focused on four main systems (1) budget and warrant control; (2) accounts payable; (3) accounts receivable; and (4) the treasury general ledger. The first of these is concerned with maintaining data on spending authority, the second and third with processing transactions as soon as possible after they occur, and the fourth with compilation of summary records for control and analysis.

2. Systems requirements

The regulatory framework and the functional processes associated with government budgeting and accounting require specific characteristics in a computer-based system.

a. Systems requirements of the regulatory framework

The computer system should be able to ensure that procedures for initiating, approving, reviewing, and processing government financial transactions against the specified chart of accounts and maintenance of audit trails are adhered to. In addition, it should be able to fulfill government reporting requirements.

Since the chart of accounts may be structured quite differently across governments, the computer system should be able to accommodate variations in the chart of accounts. The system should be able to accommodate any number of levels in the accounting chart structure, with as many digits as required in the code for a given level. It should also allow flexible field descriptions for each level. It should have provision for defining a calendar and the type and number of accounting periods, (month, week, day, etc.).

Other requirements are that the system be able to maintain multiple accounting periods open concurrently and to keep records of who is allowed to initiate, authorize, and review specific transactions. The system should capture information about the initiator, the sanctioning authority, and the review authority for each transaction, as applicable. This information should be matched with the systems record as the transaction progresses through the approval process, to ensure compliance with government regulations and any specific controls. The system should maintain an audit trail of all transactions.

To satisfy government reporting requirements, the computer system must maintain an up-to-date record of the data generated during budget implementation and this data must be accessible to the central and line agency managers for their reports. Therefore, the system must (1) record and maintain information on the various data entities 7/ created/used during the fiscal management processes: (2) uses the appropriate software for storage and management of data, such as relational database management systems (RDBMS) which enables easy and flexible access; and (3) use a good report writer to facilitate report formatting by endusers. The data and software requirements are discussed in greater detail in the following sections.

b. Systems requirements of the functional processes

To satisfy the information requirements of the CGBAS processes, the computer system must maintain a record of information on the data entities created during the performance of an organization’s functions and support the data flows and information processing associated with these processes.

(1) Data architecture

The main data entities associated with a CGBAS are listed in Table 1. A definition of each data entity is given in Annex I. The computer systems supporting budgeting and accounting should maintain information on each of these entities. These data entities are derived from (a) budgeting and accounting transactions, such as budget transfers, purchase orders, commitments; or (b) associated books of accounts and reports, such as cash flow forecasts, fiscal reports, and general ledgers.

Table 1.

Business Processes, Data Entities and Information Systems Associated with Government Budgeting and Accounting

article image
article image

The computer systems should be able to capture data on the different data entities as they are generated (or altered) during the budgeting and accounting functional processes. Provided that this is achieved, the report writing facilities normally available with most application development packages should satisfy the reporting requirements.

(2) Functional systems architecture

The functional systems architecture of government budgeting and accounting systems is a model of the information systems, the major databases, and information flows required to support the government’s budgeting and accounting processes. It is defined by the information processing requirements of these processes, the data entities which specify the information requirements of these processes, and information flows between groups of processes. Table 1 lists the main modules of the information systems network that will be required to support the budgeting, accounting, and cash management processes. The interrelationships between these modules are shown in the schematic representation in Chart 2. More detailed representations of the systems for each area and their associated data flows are given in Annex III, Charts 2A, 2B, 2C, and 2D. The main elements of this architecture are described below. 8/

Chart 2:
Chart 2:

Systems Architecture For Government Budgeting and Accounting Systems

Citation: IMF Working Papers 1994, 027; 10.5089/9781451844450.001.A001

a. Systems to assist in budget preparation, monitoring, and control

Budget preparation—these systems support the processes of budget estimate preparation. The systems receive from the various line agencies, the details of their programs and projects, consolidate them, and produce from them the documents that form the basis of the negotiations between the line agencies and central agencies. After finalization of the budget, the system produces the approved budget estimates.

In order to satisfy these requirements, the systems should be able to capture and maintain the budgetary proposals and income estimates of all government agencies and to capture any subsequent changes during the budget preparation, approved and amended processes.

The evaluation of the budget proposals should include an examination of the manpower component, the maintenance, and other operating expenses, and of the capital outlays program, using baseline data from previous periods for comparison. The baseline data should include data on authorized and filled positions for each agency, including their emoluments, and maintenance and operating expenses for previous years. Examination of the capital budget requires data on the status (physical and financial) of government-approved projects, (both locally and foreign-funded). The system should be able to access and generate the baseline data from the relevant past-year databases. In addition, it should provide facilities to effect the computation of baseline data.

Budget implementation, monitoring, and control—these systems maintain data on budgeted allocations (both capital and recurrent), sources of financing for programs and projects, budget transfers, and supplementary allocations, fund releases (warrants) against budgetary allocations over the course of the year, and summary data on commitments and actual expenditures against budgeted allocations derived from the accounting databases.

The budget monitoring systems normally operate at at least two levels—the line agency level and the central level at the MOF. The line agencies’ systems (operated by their finance departments) enable managers to track the budget implementation process and implement expenditure controls.

Tracking the implementation of capital projects normally requires separate subsystems at the line agency and central levels. For these, it is very important to maintain data on the physical and financial status and resource requirements of individual projects, including historical data.

At the start of the fiscal year, the legislature - approved budget is entered into the system. Budget transfers, adjustments (such as supplementary authorizations), and warrants are also entered during the year as they are issued. As commitment and expenditure transactions take place at the line agencies, the corresponding line agency systems responsible for generating these transactions access the line agency budget databases to (a) determine budget authorization, and (b) update the total committed and spent. The line agency systems provide agency commitment and expenditure information periodically to the central budget monitoring system, which tracks the budget implementation process for the government as a whole.

In a technologically advanced environment, the line agency systems would obtain information on the initial budget, budget adjustments, and cash allocations by directly tapping into the MOF central systems and in turn input into the MOF system their commitment and expense positions. However, in practice, the central system usually provides the initial data on budgetary allocations, budget adjustments, and cash allocations to the agency systems—off-line—and receives periodic output from the line agency systems on their commitment and expenditures.

b. Accounting systems at the line agencies and the center

Payment systems: accounts payable—the accounts payable system can also be operated at the line agency and the central levels. In cases where the treasury places approved budgeted funds in agency clearing accounts managed by agency finance staff, the system at the agency level records the payments made at that level and works with the agency general ledger, which has to be requested with the TGL. Alternatively, however, treasury payments could be handled by a treasury suboffice that would maintain the accounts payable system and the general ledger on behalf of the agencies it services. The accounts payable system at the center would record payments made at the center by the treasury.

A significant part of the payments emanating from the line agencies are related to the procurement of goods and services. A procurement tracking system would serve as a feeder to the accounts payable processes and enable line agencies to track the procurement of goods and services. The system would enable agencies to register a procurement request and would create a commitment after checking for budget allocations. It would then track the procurement processes until the purchase order is issued. This tracking would include maintaining a list of approved vendors, issuing of the request for proposal (REP), evaluating the responses, and issuing the procurement contract. As mentioned earlier, where the procurement process is handled centrally for all government agencies, the procurement system would be operated by the central agency responsible for procurement. In these cases, the line agencies would record commitments in their own accounting systems to cover the procurement, prior to placing the order on the central procurement agency.

In general, the accounts payable systems should be able to accommodate the following requirements for procurement - related payments:

  • Maintenance of an approved vendor database;

  • Maintenance of a record of procurement requests, commitments, purchase orders, and goods receiving reports;

  • Provision of facilities for matching requests, commitments, purchase orders, goods receiving reports, partial receipts against payment orders, and blanket purchase orders;

  • Provision of facilities to age transactions, make cash requirement projections, and generate reports.

In addition to processing transactions related to the procurement of goods and services, the system should be capable of processing payments related to other transactions, such as advances, grants, and loans.

Subsidiary payment systems would cater to special types of payments relating to, for example, payroll and pension. These systems could be operated at the central level, as is normally the case for pension payments, or at the agency level, as is the case for agency payrolls. These systems would post summaries to and interface with the corresponding general ledgers.

Receipt systems: accounts receivable—the accounts receivable systems can also operate at both agency and central levels and record the receipts/receivables at these levels.

In general, the receivable systems should be able to maintain an accounts file containing detailed information on, for example, individual employees, private sector organization, state or local governments, and federal government agencies, including data such as identification, address, balances, account history data, and billing cycles. They should be able to support the calculation and generation of bills; update each account when billing documents are generated and collections received, and provide reporting facilities.

Special receipt systems are tax, customs and foreign aid receipts. These systems should post summaries to the corresponding general ledgers.

General ledger—the main requirements of the general ledger are that it maintain historical and current records on all government transactions and facilitate timely reconciliation with bank statements. Month-end and year-end financial reports should be generated by the general ledger with a minimum of delay. The system should provide for automatic month- and year-end closing procedures, and permit data entry for two months simultaneously. It should have the facilities to accept transactions directly or from other system modules of the network, for example, the accounts payable, the accounts receivable, and the subsidiary payment and receipt systems mentioned above. Like the other subsidiary systems, the general ledger is also implemented at the line agency and the central (MOF/treasury) levels.

Cash management system—this system maintains an up-to-date picture of the government’s liquidity position and cash requirements. It obtains information on actual agency expenditures and cash balances in government (including agency) accounts from the general ledger, revenue inflows, borrowing, loan disbursements, treasury bills, government bonds, and cash deposit maturities are obtained either from the general ledger or from the specific systems for these areas, for example, the debt management system. Using this information, the government can decide on (a) budget ceilings and fund releases to line agencies; and (b) the timing of the issues and redemptions of government securities, to provide short-term financing for shortfalls.

Systems for fiscal reporting and budget evaluation—these systems use the data from budget implementation, monitoring, and accounting systems to monitor and evaluate the overall budget implementation and cash management can be made.

3. Technological requirements

The technological requirements for a CGBAS comprise hardware, software, and communications technology to be used to implement the systems’ modules identified above. The requirements involve a description of the nature, size, and distribution of computer processing facilities and the associated work stations; the nature of communications between computer processing facilities; the nature of application development and systems software, database management system (DBMS) software, special purpose software to support analytical capabilities, text management, and desktop publishing.

a. Overall technological considerations

The CGBAS network requires modules at the line agency and central levels with facilities for generating, storing, and processing data at each level and for exchanging data between levels. The data volumes encountered can vary widely across the nodes of the network.

To implement a CGBAS, one of the following types of systems is needed -

(1) A computer located at the center with terminals in the line agencies connected by telecommunications. Transactions generated at any node would be processed on a real time basis; or

(2) A multitiered system with stand-alone microcomputers, local area networks (LANs), or minicomputers, located at the nodes (MOF, other core agencies, the line agencies, and subordinate/regional treasury offices, and connected by telecommunications. The transaction processing and database management at each node would be carried out by the local computers. The summary or detailed data required for the applications would be transmitted to the computer in the agency responsible for that system (e.g., to the MOF’s budget division for the budget system, to the treasury for the accounting and cash management systems.)

Under option (1), all computing, including processing, storage facilities, and data compilation, would be centralized. A mainframe computer and telecommunication facilities capable of high speed data transmission would be needed at the center.

Option (2) is frequently preferred because computing power is distributed commensurate with node requirements, making this system less vulnerable to malfunctions at the central site; and (b) endusers at the line agencies have more control of their technological and data resources, which inculcates a sense of ownership in the systems. In the absence of good telecommunication facilities, the data transfer between the nodes and the center could be periodic (say, daily, weekly, or monthly, depending on the application system) in an off-line/batch node. In the absence of any telecommunications facilities at some nodes, the data transfer could, as a minimum, be on computer-compatible media (data transfer via hard copy written reports would imply rekeying data).

The size of each node’s computers would depend on the amount of its data and number of its transactions. They could be stand-alone microcomputers, microcomputers connected by a local area network (LAN), or fairly large capacity minicomputers at the center and larger line agencies.

For application modules that are to be implemented at multiple levels, the software should be similar at each node and scalable—that is, able to be run on small or large computers without major changes. These properties can be achieved by choosing compatible computers that offer multiple size configurations. However, this would restrict further additions to the network to this vendor and line of computers. To avoid these restrictions, the application systems should be developed using tools and DBMs software that can operate on machines of different sizes offered by several vendors. 9/ This feature is called software portability.

To ensure vertical and horizontal portability, and scalability, the hardware should be an open system—assembled from components that conform to generally (though not universally) accepted standards. The hardware and software would therefore be interchangeable, providing greater flexibility.

It will be some time before there is a full set of products on the market that truly conforms to open system standards; at present, the UNIX environment comes the closest. Most vendors now offer a version of UNIX. Since UNIX versions vary slightly with the vendor, some application changes may be required before it can be used on a different vendor’s machine; however, time and effort involved in making these changes would be small compared to rewriting the applications.

Another consideration in choosing the application development environment is that certain tools, such as fourth-generation languages (4GLs), RDBMs, and graphic user interfaces (GUIs) make it easy to add or change application features, including changes to database structures, associated programs, and report formats. The use of these tools increases application development productivity and, therefore, reduces development time. These tools also enable endusers to access the databases themselves and to program simple reports.

b. Application-specific technological requirements

The specific technology required for the various system modules would depend on the modules’ functional characteristics, including the amount of data handled, the size of the databases, the number and rates of transactions, and the volume of the information flow between modules.

A number of design elements are also important, such as the distribution of the processing—whether the information is processed centrally or among widely separate locations. If the latter, the following factors should be taken into account: how frequently the information needs to be aggregated at the center, and the requirements for output facilities (such as graphics, report writing, and desktop publishing) and for analytical facilities. These technological requirements are illustrated in Annex II.

CGBAS application modules are closely related. To facilitate data transfer and system operation, they should be implemented using the same software environment across the network.

4. Project management issues

System design requires close coordination between top level management, system users, and system designers. Unfortunately, this cooperation is not often achieved and, consequently, the system is either not implemented or is inadequate. To avoid such difficulties, the following should be taken into account:

Overall framework—implementation of a CGBAS government-wide computer system for budgeting and accounting is a substantial undertaking. A framework outlining the scope of the information network modules and the interconnections between them is needed.

Formalization of the project—project planning methodologies should be used to design, implement, and monitor the CGBAS, and project management responsibilities should be clearly identified. Phased implementation would ensure that the system can be absorbed by the organization where it is implemented.

Project sponsorship—sponsorship at the highest levels and participation by the widest range of users is necessary in all phases of the project. Senior management input and a managerial capacity to ensure acceptance by the user community are particularly important during the earlier phases.

Steering Committee—a mechanism widely used to ensure user participation is a steering committee, comprised of a senior manager and representatives of different user groups. This committee should provide input to the technical team responsible for implementation.

Technical skill—to implement and operate the CGBAS, the following are required -

  • High-level project design and planning skills;

  • Project management skills;

  • Technical implementation skills—to operate the use of the hardware and software;

  • User-support skills—to develop user and technical documentation, to train endusers, and to set up a hot line as well as more formal training for endusers.

Technical support for hardware and software—it is imperative that the hardware and software chosen be supported locally. The vendors must have a local presence to be able to provide training and technical support during the life of the system.

Organizational issues—An information systems organization should be set up, or existing organizational units strengthened, to incorporate the skills mentioned above, and to manage the planning, development, and operation of the systems. Information system support should be distributed among several agencies across government. Therefore, coordinating mechanisms should be created to ensure that a common set of policies, procedures, and standards, are put in place for managing data and systems across government. The standards should, inter alia, cover the protocols for communications, data entry, editing, and updating screen input and output formats, back-up and recovery, security, contingency and disaster planning, and technical and user documentation.

III. Strategies for Implementation

The emphasis that countries place on management will differ, as will their capacity to implement system reforms. Implementation of budget and accounting system reforms is a long-term process. Such reform programs have been evolving in the OECD economies for several decades. A similar or longer term timetable will be necessary in those countries with less-developed administrative processes. For effective fiscal management, it is vital that systems be developed around the core functions described in the preceding sections. Moreover, since the underlying requirements are similar, it seems feasible, either to develop or identify from the several software packages available on the market, a (CGBAS) that could (1) provide the basic transaction processing and database management functions needed for fiscal management in any country; and (2) allow the tailoring of controls, data entry, and reporting functions to any country’s needs. Development of such a system and/or identification of off-the-shelf software package(s)—with ancillary documentation of budgeting and accounting procedures and appropriate technical assistance support—could greatly facilitate budget reforms in the DCs and EITs.

The case for developing such a core system or identifying suitable software package(s) is strongest for the EITs. Development of the appropriate institutions to manage a market-oriented economy is of strategic importance to these economies and, since they are all starting from a similar administrational base, a core system should be readily applicable to all. Development of a CGBAS should greatly reduce the implementation time for all such systems.

It should be emphasized that for most EITs the current environment is not favorable to major improvements in the budget preparation process. Major uncertainties on the revenue side (because of falling output) combined with intense political pressure for social spending and resistance to expenditure reductions elsewhere, mean that the approved budget is often an unrealistic guide to a sustainable level of public spending. In the near future, the strategy for building the budget and accounting system in these countries must focus on the careful control of budget execution and the management of cash and public debt. Major emphasis is therefore being given to establishing a control framework and building a treasury system that would control release of funds to ministries, take over full accounting functions from the banking system, and manage cash and public debt. The treasury system, once established, would provide a good basis for developing the budgeting functions.

As indicated in the introduction, the DCs face different problems but, nonetheless, the development of a CGBAS could play a critical role in rebuilding and developing their budgeting systems. In general, the DCs have inherited manual systems from their former colonial powers, and these continue to provide a reasonable basis for control in most cases. The requirements of administration have become much more complex, but this has not been matched by the development of administrative skills or comprehensive modernization of budgeting and accounting systems. Indeed, a common feature of most DCs is that government accounts are not produced on a timely basis, not comprehensive, and not reliable; in other words, they meet none of the classical criteria of a good accounting system. As noted, a common response has been to develop a variety of specialized stand-alone information systems that often result in a further weakening of the central budgeting and accounting system. The most appropriate strategy for these countries would be to provide strong support for the central accounting system and ensure that the design is flexible enough to meet the special needs being addressed by stand-alone systems—or to integrate the central system with these auxiliary systems. A CGBAS would provide a possible option for achieving this end—particularly since many of the computer systems now in operation in the DCs are old, custom-built, COBOL-based systems, which do not give comprehensive coverage to fiscal management processes and cannot be easily developed to do so.

The CGBAS should provide a sharper focus for much of the technical assistance provided by international and bilateral agencies. A wide variety of these organizations, notably the IMF, the World Bank, the regional development banks, and the UNDP, have provided assistance to improve various aspects of budgeting and accounting. The need for continuing efforts in this area is widely recognized. If a CGBAS were available, efforts could be directed to tailoring its features to meet specific needs, and the implementation time would be much reduced from the broader approaches now being used. Of course, some general support would continue to be needed; in each country, there would need to be a comprehensive review of systems requirements, administrative constraints, and an appropriate phasing of implementation, in the light of these factors. Centering the efforts on a CGBAS, however, should avoid the difficulties that arise from piecemeal development of systems. Clearly defined requirements would enable the systems to be designed to accommodate all budgeting and accounting objectives, whereas computerization of existing accounting systems would only meet the more limited objectives of ensuring financial compliance. Information systems development could then play a pivotal role in improving budgeting and accounting, providing that the policy and administrative environment is supportive.

ANNEX I: Data Architecture for Government Budgeting and Accounting System

article image
article image
article image
article image
article image

ANNEX II: Technological Requirements for Budgeting and Accounting Systems

article image
article image
article image

ANNEX III: Systems to Assist in Budget Preparation, Monitoring, and Control

Chart 2A
Chart 2A

Systems to Assist in Budget Preparation, Monitoring, and Control

Citation: IMF Working Papers 1994, 027; 10.5089/9781451844450.001.A001

Chart 2B
Chart 2B

Accounting Systems at the Line Agencies and the Center

Citation: IMF Working Papers 1994, 027; 10.5089/9781451844450.001.A001

Chart 2C
Chart 2C

Systems for Cash Management

Citation: IMF Working Papers 1994, 027; 10.5089/9781451844450.001.A001

Chart 2D
Chart 2D

Systems for Budget Evaluation and Fiscal Reporting

Citation: IMF Working Papers 1994, 027; 10.5089/9781451844450.001.A001

ANNEX IV: Summary of Functional Requirements for the Budgeting and Accounting Modules of a Government Fiscal Management System 10/

Budget and Funds Control

The budget and funds control subsystems must include -

  • expenditure control equivalent to funds allocation;

  • financial and other data for budget and program estimates, and periodic budget reports;

  • budget control at any nominated segment of the account code;

  • budget control on a monthly or biweekly basis (or as required);

  • control available either as a warning or to prevent a transaction taking place, as required;

  • on-line checking of commitments and expenditure against availability of funds;

  • adjustment to commitment at time of posting expenditure;

  • on-line checking of forward commitment against limits; and

  • formula - driven allocation function to enable a high-level allocation function to be split, in accordance with a user specified formula, to lower level allocations.


The purchasing subsystem must -

  • provide access to a list of potential suppliers and vendor files and a means of maintaining these databases;

  • allow recording of details of supplier performance;

  • allow entry of requisitions (proposals for expenditure);

  • allow entry and printing of purchase orders from any approved location by approved user;

  • allow credit card transactions to be recorded, and provide facilities to reconcile transactions with monthly credit card statement;

  • allow splitting of orders to multiple accounts;

  • provide recording of receipt of goods/services, including partial delivery;

  • accommodate variations to, and cancellation of, purchase orders; and

  • accommodate multiple vendor addresses (e.g., different addresses for placement of order and payment).

Accounts Payable

The accounts payable subsystem must -

  • provide facilities for registration and monitoring of claims;

  • match purchase order, invoice, and delivery details;

  • process credit notes from suppliers;

  • generate recurring payments;

  • provide a due date facility;

  • allow payment of claims by credit card;

  • allow recording of details of cash payments;

  • accommodate many-to-many relationships between invoices and purchase orders;

  • notify creditors on remittance advice if discount taken;

  • provide facilities to enter check-butt/remittance advice details;

  • allow splitting of payments to multiple accounts;

  • record commitment if invoice does not relate to an existing purchase order;

  • allow purchase order to be reopened by authorized staff after final payment has been made;

  • verify transaction to avoid payment of duplicate invoices; and

  • provide techniques to handle voided checks.

Accounts Receivable

The accounts receivable subsystem must provide facilities for -

  • processing sales orders, invoices, and debit advice notes; and following up debt, including calculation of interest;

  • producing age and trend analyses of debts;

  • recording bad debts, write-offs and recoveries;

  • recording details of agreements with debtors;

  • registering credit notes from suppliers and issuing credit notes to clients;

  • producing bank deposit slips;

  • acquitting receipts against invoices; and

  • maintaining debtor details.

General Ledger and Chart of Accounts

The general ledger and chart of accounts subsystem must provide -

  • flexible coding system;

  • automatic posting to subsidiary ledgers;

  • transaction details for previous years;

  • totals for previous years;

  • cash commitment and accrual accounting;

  • user-defined accounting periods;

  • journal entry facilities;

  • entry and reporting of nonfinancial information;

  • account maintenance facilities;

  • procedures associated with end of accounting periods;

  • facilities for recurring accrual entries;

  • facilities for a single transaction to have effect in two accounting periods;

  • mechanism for cost allocation; and

  • separate recording of expenditure and revenue (not just cash balance).

Internal Controls and Audit

The internal controls and audit system must allow the user/auditor to -

  • ensure that all processing complies with statutory requirements;

  • produce exception reports;

  • reconcile subsystems with general ledger;

  • obtain audit trails for all transactions associated with supplier and other master files;

  • obtain transaction details to support account balances; and

  • obtain audit trails to enable source documents to be traced to financial statements and vice versa.


The security system must

  • provide facilities for electronic signatures, for internal user identification and authorization, and for external authorization and check production;

  • log all transactions by user and terminal;

  • record user’s identification as part of the transaction record;

  • limit access to data files and programs both through the system and through access methods external to the system;

  • prevent alteration of financial data except through the posting of transactions that are entered through the normal edit and update process;

  • provide a system-wide security facility covering all core modules;

  • allow detection, reporting, and investigation of unauthorized access to data;

  • prevent malicious or accidental destruction/misuse of data;

  • provide a security management system that allows individual and generic user security profiles to be created, and that maintains and controls access to data and functions on the basis of these profiles;

  • require a single user identification password to access all core modules to which access is allowed;

  • allow a limit to be placed on the number of unsuccessful/unauthorized attempts at a particular operation; and

  • provide an audit trail of unsuccessful/unauthorized attempts to access the system.

Backup and Recovery

The backup and recovery system must work in conjunction with the operating system, the transaction processing system, and the database management system to assist in-

  • identifying data files that have been changed and those that will be saved for recovery purposes; and

  • backing up all incomplete transactions, restoring the system to its last consistent state, and reapplying the transactions that have not been successfully posted since the last backup.

This system should provide options for selective or full restores, incremental or complete backups, and on-line backups by excluding user access.


  • Allan, W., and M. Woolley, Public Expenditure Management Systems for Developing Countries: Core Requirements and Practical Strategies,” unpublished, (Fiscal Affairs Department, International Monetary Fund, Washington, 1991).

    • Search Google Scholar
    • Export Citation
  • Australia, Department of Finance, “Review of Financial Management Information Systems—Report to the Information Exchange Steering Committee” (Canberra, 1990).

    • Search Google Scholar
    • Export Citation
  • Davies, H. M., A. Hashim, and E. Talero, Information Systems Strategies for Public Financial Management,” World Bank Discussion Paper No. 193 (Washington, 1993).

    • Search Google Scholar
    • Export Citation
  • Joint Financial Management Improvement Program, “United States, Federal Financial Management Systems: Core Financial System Requirements” (Washington, 1988).

    • Search Google Scholar
    • Export Citation
  • Lacey, M. Robert, Managing Public Expenditure,” World Bank Discussion Paper No. 56 (Washington, 1989).

  • Organization for Economic Cooperation and (1990), “Public Management Developments: Survey” (Paris: OECD, 1990).

  • Premchand, A ., Government Budgeting and Expenditure Controls: Theory and Practice” (International Monetary Fund, Washington, 1983).


IBRD staff member.


The authors are grateful to a number of colleagues from the World Bank and the IMF for helpful comments on earlier drafts of this paper. In particular, we would like to thank Michael Stevens, Anthony Graeme Lee, Eduardo Talero, Alan Pearson, and Ross Paul.


See, for instance, JFMIP (1988), and OECD (1990).


The analysis presented in this paper is an extension of that described by Davies, Hashim, and Talero (1993), which derives a strategic framework for computer-based fiscal management systems for government from a systematic analysis of functional processes, information requirements, and information flows associated with government fiscal management. This paper carries the analysis to the next level of detail and derives functional specifications for the core government budgeting and accounting systems identified by Davies et al., by analyzing the functional processes and information requirements for the budgeting and accounting areas in greater detail. The results of such an analysis can be used for designing and developing these application systems.


The fund becomes the basis for accounting and reporting in government. It is common to divide the overall CF into several funds—for example, a fund for current receipts and expenditures, a fund for loan and capital receipts and expenditures, and a fund for receipts and expenditures on behalf of other parties (trust funds). Any fund may have a number of subfunds, and subfunds may have several bank accounts.


As noted, from a macroeconomic point of view, the concern is with the general government rather than simply with the central government budget. Aggregate reports from all elements of general government should be compiled in a timely and reliable way—and essentially the same processes described for central government should also apply to local levels of government and extrabudgetary components of general government.


It should be noted, however, that the processes are simplified substantially for expositional purposes. One complexity is that many important payment categories do not follow the precise order-bill payment pattern shown in the diagram. Payment of payroll, salaries, and debt service are examples. Each needs a specific functional process description—and should be developed as a linked subsystem of the CGBAS. It should also be noted that, in many governments, some inputs (such as drugs or building materials) are purchased centrally. These purchases follow the routine described (though possible through a revolving fund arrangement within the CF), and ministries wishing to use these items requisition from stores when required and transfer funds to the credit of the purchasing authority.


In some cases, payments may be handled by the regional offices of the treasury.


A data entity is a person, place, thing, or concept involved in an organization’s functional processes (in this case, the processes associated with government budgeting and accounting) and on which data needs to be kept. A data entity has various attributes, which are recorded in system databases.


See also the summary of the functional requirements for government fiscal management systems, extracted from a report prepared by Australia’s Department of Finance, in Annex IV.




Extracted from the Report to the Information Exchange Steering Committee, Department of Finance, Government of Australia, December 1990.

Core Functional Requirements for Fiscal Management Systems
Author: Ali Hashim and Bill Allan