## _tnm1103 - Introduction ## Source details **Canonical URL:** [_tnm1103 - Introduction](https://www.imf.org/-/media/websites/imf/imported-full-text-pdf/external/pubs/ft/tnm/2011/_tnm1103.pdf) ## Other formats - [Markdown version](/-/media/websites/imf/imported-full-text-pdf/external/pubs/ft/tnm/2011/_tnm1103.pdf.md) - [Structured JSON version](/-/media/websites/imf/imported-full-text-pdf/external/pubs/ft/tnm/2011/_tnm1103.pdf.json) --- ### Purpose and scope of the TNM - Explains the purpose of a chart of accounts (COA) and its importance in public financial management (PFM). - Discusses stakeholder needs in a typical PFM framework that need to be reflected in a COA. - Discusses the role of COA in budgetary and financial accounting. - Discusses the relation between the COA and IFMIS. - Explains key steps for identifying data requirements and structures for developing a COA. - Objective: demystify the COA, describe its role across budget preparation, execution and reporting, present key design principles and factors, discuss budgetary and financial accounting issues affecting COA, and consider COA development and implementation and its relationship with an IFMIS. ### Importance of the COA in PFM systems - The COA is the lynchpin of a government’s accounting and reporting system and a critical element of a well-functioning PFM system. - An effective accounting and financial reporting system should capture, classify, record, and communicate relevant, reliable, and comparable financial information for at least: - budgetary accounting and reporting, including reporting of actual against approved budget estimates; - general purpose financial reporting; - management information; and - statistical reporting. - Risks of a poorly designed COA: - onerous standard reports, increased reliance on human and spreadsheet intervention, hampered data retrieval and reconciliation, and unreliable financial reports. - The COA must be planned to meet current management needs and potential future requirements and be changeable (particularly with an IFMIS) to respond to organizational reorganization and changing needs. ### What is a COA? - The COA is an organized and coded listing of all individual accounts used to record transactions and make up the ledger system. - It specifies how financial transactions are recorded in accounts that form the General Ledger (GL) and subsidiary ledgers. - Provides a coding structure for classification and recording of financial information (flows and stocks). - Classification structure should meet legal and administrative requirements and conform to international standards on financial and statistical reporting. - For budget management, the COA should support planning, controlling and reporting of budgetary allocations/appropriations and internal management needs of budget units and/or cost centers. - COA configuration represents hierarchical structures of groups of classifications (segments) that can be combined to create reports and enforce controls. - With an IFMIS, stakeholders’ needs can be met with one unified COA configured with hierarchical linked codes (parent-child relationships). ### Common classifications used in COA (Box 1) - Administrative or organizational classification - Fund classification (which may include donor classifications) - Program classification - Classification of Functions of Government (COFOG) - Economic (or Natural account) classification* - Government Financial Statistics (GFS) classification (usually based on the IMF GFSM 2001)* - Location or geographic classification - Note: Both the economic and the GFS classifications should either be the same or the latter should be derived from the former. ### Role of the COA in government systems — seven major objectives - Control: - budget appropriation control, in-year allotment/warrant control, fund control (e.g., the general revenue fund such as Consolidated Fund), management control and other fiduciary controls. - Accountability: - tracking transactions specific to each administrative entity to enforce accountability and audit trails; configuration should respond to accountability and audit requirements (e.g., tracking stages of transaction authorization). - Budget management: - supports budget formulation, execution and reporting and day-to-day monitoring; should cover authorized appropriations, in-year allotments/apportionments, virements or supplementary budget authorizations, expenditure commitments, obligations/liabilities at verification/delivery stage, and payments. - Financial planning and management: - supports financial planning, cash management, and asset and liability management; COA design must specify categorization and aggregation levels for assets, liabilities, and cash/liquid assets. - Management information: - enables line agencies to obtain detailed and frequent information for cost monitoring, internal control and decision making; agency-level detailed account codes may link to higher level codes for consolidation. - General purpose financial reporting: - supports preparation of financial statements and reports in accordance with national and/or international accounting standards (such as IPSAS) and enables users to evaluate resource allocation and hold managers accountable. - Statistical reporting: - produces statistical reports (e.g., GFS reports) for macroeconomic analysis, surveillance, international comparisons, and reporting to international organizations such as the IMF; data should be generated from the accounting system via a well-designed mapping. ### Reporting entity and budgetary sector (summary of Box 2) - “Reporting entity” includes resources deployable by the entity regardless of legal or administrative structure; used in preparing general purpose financial reports. - A government as a whole (federal, state, territorial or local) is a reporting entity for assessing resource allocations and accountability. - Individual statutory authorities and departments (and entities they control) may also be reporting entities because of economic/political significance or financial characteristics. - Identifying a reporting entity requires considering the boundary of economic activities; legal entity existence alone is neither necessary nor sufficient. - Consolidation: - A reporting entity can include multiple entities where one controls others and consolidated financial statements should be presented where appropriate. - To fully comply with standards (such as IPSAS) coverage may need to extend beyond the budgetary sector. - The definition of the budget sector varies by country and depends on entities accountable to parliament/legislature. ### Budgetary Accounting vs. General Financial Accounting – Case of France (Box 3) - Legal framework: - Article 27 of the French Organic Budget Law (LOLF) of 2001: central government shall keep accounts of budgetary receipts and expenditures (comptabilité budgétaire) and general purpose accounts (comptabilité générale). - Article 28 (LOLF 2001): budgetary receipts and expenditure payments recognized on a cash basis. - Article 8 (LOLF): appropriations comprise commitment appropriations and cash appropriations. - Article 30 (LOLF 2001): general purpose financial statements based on accrual accounting. - Budgetary accounting (comptabilité budgétaire): - Purpose: verify compliance with parliamentary authorizations and enforce accountability for execution of the Budget Law. - Recognizes receipts and payments on a cash basis; records appropriations at two stages: autorisation d’engagement (authorization for commitments) and crédit de paiement (authorization for payments during the budget year). - Flow-based, single-entry system producing a budget execution report; coverage limited to transactions formally authorized in the Budget Law; does not produce a balance sheet. - General purpose accounts (comptabilité générale): - Purpose: provide financial statements reflecting assets and financial position; align with French plan comptable where appropriate. - Accrual accounting: transactions entered for the financial year to which they relate, independent of payment/receipt dates. - The General Account (Compte Général de l’Etat, CGE) is issued annually alongside the Budget Review Act (Loi de Règlement); CGE presents balance sheet and statement of revenue and expenditure. - Linkage between the two systems: - A common and integrated account coding structure is desirable to link budgetary and general accounts. - France developed a common budget and accounting code—nomenclature budgétaro-comptable—used for both systems. - Historical updates: 1988 chart of accounts review to align with the 1982 plan comptable; 2004 modernization to reflect move to accrual accounting. - Implications for COA design and IFMIS: - Budget and accounting classifications should be integrated conceptually and architecturally to enable monitoring. - Risks of non-integration: loss of important information, difficulty identifying accounting implications of budgetary operations. - Alternative: bridge tables can link accounting data with budgetary operations when classifications are not integrated. - Implementation guidance: improve budget classification only when corresponding COA/IFMIS changes are in place; e.g., introducing a program segment without COA/IFMIS changes may prevent program-level budget outturns. ### Key principles for COA design (core principles) - Comprehensiveness: capture all required/relevant information; reflect both budget and accounting frameworks; embed or harmonize budget classifications in accounting classifications. - Adequate granularity: provide sufficient detail in segments and sub-segments to meet control, accountability, management, and reporting needs. - Mutual exclusiveness: define segments and attributes to be mutually exclusive. - Avoiding redundancy: do not create independent segments if information can be derived from another segment. - Internal consistency: use a consistent hierarchical structure and numbering system. - Unified framework: allow limited local flexibility for subsidiary ledgers but ensure aggregated information uses the same accounting classification. - Scalability: allow room for future additions and changes. ### Additional factors affecting COA configuration - Institutional framework: centralization vs decentralization of transaction processing affects COA design; recording at commitment and payment order stages must integrate with financial accounting at the payment stage. - Transaction processing platform: implementing the COA in the GL module of an IFMIS raises specific configuration issues. - Accounting basis: cash or accrual basis for budget execution and reporting influences COA design; governments transitioning from cash to accrual should enable progressive capture of accrual information. - Need to define accounting policies simultaneously with the COA to avoid ambiguity when bases differ. ### Business needs analysis — key issues (Box 4) - Users: policy makers, government managers, parliament/legislature, the broader public, supreme audit institution, credit rating agencies and international organizations. - Control framework: COA must reflect who is accountable, why, and for which funds. - Data structure: allow data from different dimensions and levels to be collected, reconciled and consolidated for alternative views. - Reporting requirements include entity reporting, financial reporting, internal management reporting, consolidation reporting (including in-year aggregate), accountability reporting, GAAP/IPSAS reporting, segment-level reporting, program/project reporting, interdepartmental/intercompany reporting, and other country-specific needs. - Deriving the balancing segment: commonly set as the organization segment; conclude where balancing occurs for IFMIS configuration. - Anticipating future needs: keep one or two reserve segments. - Hierarchy versus segment: consider parent-child relationships versus segments for administrative classification, functions/programs, natural account, projects/activities/geographic classifications. - Classification needs and exclusions: economic classification underpins GFS; vendor/customer details should be held in subsidiary ledgers, not the GL COA. - Transaction level and coding: distinguish COA (hierarchical segments) from transaction code (Coding Block); use mapping tables where segments can be derived. - COA usability: avoid overcomplicating numbering; use simplified but structured numbering. ### Structuring accounts, ledgers and IFMIS configuration (Box 5) - COA structure: - Reflects budget classification plus asset, liability and equity accounts and internal management classifications. - Each classification has a name, description and code; organized around segments with parent-child hierarchies. - GL and subsidiary ledgers: - COA is the basis of the GL; subsidiary ledgers (e.g., Accounts Payable) must map to GL control accounts. - Fragmentation risk if transactions recorded in disparate systems that do not roll up to GL control accounts. - Account types and economic classification: - Revenue and expense accounts are netted at year-end with surplus/deficit transferred to networth; asset and liability balances carried forward. - Configuring COA in an IFMIS: - IFMIS can provide real-time financial information and support financial reporting; GL module is the backbone. - Design considerations: establish one global/unified COA, use simple logic and limit number of accounts, decide accounting basis (cash, accrual, or in transition), leverage IFMIS functionality, and ensure scalability. - Balance level of detail between GL COA and subsidiary ledgers; use subsidiary ledgers for supplier and asset detail. - Data normalization and reporting: - Organize data to minimize redundancy in an RDBMS IFMIS; prefer standard reports run directly from IFMIS using coding structures. - Amending legal/regulatory framework and change control: - Assign institutional authority to approve COA changes (e.g., Minister of Finance/Accountant General). - Define roles, procedures, and a cyclical update process no more frequent than quarterly. - Assess impact of proposed changes and ensure consistency with segment definitions and parent-child relationships. - Data migration: - Develop a data migration plan; involve functional users (map old to new codes) and technical support; reconfigure historical reports to align with new COA. - Capacity building and change management: - Secure support from highest levels of government early. - Identify organizational and documentation changes, human capacity development needs, key change agents, and a sensitization plan. - Develop and implement a training program. ### Conclusion and key implementation steps - The COA is the lynchpin of a government accounting and reporting framework and the hub of any computerized accounting and reporting system (IFMIS). - COA design should address specificities and stakeholder needs in the PFM framework and provide structure for organizing, recording and reporting financial information (flows and stocks). - Even when budgeting and financial reporting use different accounting bases, a common and integrated account coding structure should be possible. - Key implementation steps: - (i) carrying out a comprehensive business needs assessment; - (ii) harmonizing the budget classification and the COA; - (iii) structuring the data attributes and developing various segments of the COA; - (iv) following basic guidelines for configuring the COA if implemented as part of an IFMIS; - (v) amending, as necessary, the underlying legal and regulatory frameworks; - (vi) addressing data migration issues; and - (vii) developing and implementing a plan for capacity building of COA users as well as a change in management strategy. - Phased implementation may be necessary to reflect sequencing of other PFM reforms, examples include: - updating the economic classification to implement GFSM 2001; - transition to accrual accounting; - adding a source-of-fund segment to integrate donor financing; and - implementing a program structure for results-based budgeting. *Source: _tnm1103 - Introduction_* ### Introduction ### _tnm1103 - Introduction ### Purpose and scope of the TNM - Explains the purpose of a chart of accounts (COA) and its importance in public financial management (PFM). - Discusses stakeholder needs in a typical PFM framework that need to be reflected in a COA. - Discusses the role of COA in budgetary and financial accounting. - Discusses the relation between the COA and IFMIS. - Explains key steps for identifying data requirements and structures for developing a COA. - The note aims to demystify the COA, describe its role across budget preparation, execution and reporting, present key design principles and factors, discuss budgetary and financial accounting issues affecting COA, and consider COA development and implementation and its relationship with an IFMIS. ### Importance of the COA in PFM systems - The COA is presented as the lynchpin of a government’s accounting and reporting system and a critical element of a well-functioning PFM system. - A well-functioning PFM framework includes an effective accounting and financial reporting system to support fiscal policy analysis and budget management. - The accounting and reporting system should capture, classify, record, and communicate relevant, reliable, and comparable financial information for at least: - budgetary accounting and reporting, including reporting of actual against approved budget estimates; - general purpose financial reporting; - management information; and - statistical reporting. - A poorly designed COA makes standard reports onerous, increases reliance on human and spreadsheet intervention, hampers data retrieval and reconciliation, and yields unreliable financial reports. - The COA must be planned to meet current management needs and potential future requirements; it should also be able to be changed—particularly in the context of an Integrated Financial Management Information System (IFMIS)—to respond to organizational reorganization and changing needs. ### What is a COA? - The COA is an organized and coded listing of all individual accounts used to record transactions and make up the ledger system. - The COA specifies how financial transactions are recorded in a series of accounts required to support the needs of various users/stakeholders; this series of accounts is called the General Ledger (GL) and subsidiary ledgers. - The COA provides a coding structure for the classification and recording of relevant financial information (both flows and stocks) within the financial management and reporting system. - The classification structure should meet legal and administrative requirements for budget management and financial reporting and conform to certain international standards on financial and statistical reporting. - For budget management purposes, the COA should meet requirements of planning, controlling and reporting of budgetary allocations/appropriations as well as internal management needs of budget units and/or cost centers. - The COA configuration represents hierarchical structures of groups of classifications (segments). Each segment identifies a discrete information requirement; segments can be combined to create reports and enforce controls. - For effective management, the COA should cover all transactions (flows) and balances (stocks) of the reporting entity for budget management and general purpose financial reporting. - With an IFMIS, the needs of all stakeholders can be met with one unified or common COA configured with a hierarchical set of linked codes based on parent-child relationships, with lower level codes used by individual accounting units and higher level codes used for consolidation. ### Common classifications used in COA (as listed in Box 1) - Administrative or organizational classification - Fund classification (which may include donor classifications) - Program classification - Classification of Functions of Government (COFOG) - Economic (or Natural account) classification* - Government Financial Statistics (GFS) classification (usually based on the IMF GFSM 2001)* - Location or geographic classification - Note: Both the economic and the GFS classifications should either be the same or the latter should be derived from the former. ### Role of the COA in government systems - COA definition and use are influenced by different PFM traditions; practices differ across countries, but sufficient commonality exists to set underlying principles for an effective COA. - The COA should meet seven major objectives: - Control: budget appropriation control, in-year allotment/warrant control, fund control (e.g., the general revenue fund of the government [e.g., Consolidated Fund] and other special funds), management control and other fiduciary controls. - Accountability: tracking transactions specific to each administrative entity to enforce accountability and audit trails; COA configuration should respond to these accountability requirements and specific audit requirements (e.g., tracking stages of transaction authorization). - Budget management: supports budget formulation, execution and reporting (in-year and end-year) and day-to-day monitoring; budgetary accounting should cover authorized appropriations, in-year allotments/apportionments, virements or supplementary budget authorizations, expenditure commitments, obligations/liabilities at verification/delivery stage, and payments. Budget classifications define the structure of COA codes/sub-codes related to government budgetary revenue and expenditure operations. - Financial planning and management: supports financial planning, cash management, and asset and liability management; COA design must specify how assets and liabilities are categorized and at what aggregated level cash and liquid assets are monitored. - Management information: enables line agencies to obtain detailed and frequent information for cost monitoring, internal control and day-to-day decision making; agency-level detailed account codes may be used if linked to higher level codes for consolidation. - General purpose financial reporting: supports preparation of financial statements and reports in accordance with national and/or international accounting standards (such as IPSAS); enables users (e.g., parliament, public, creditors/donors) to make and evaluate resource allocation decisions and holds managers accountable. - Statistical reporting: produces statistical reports (e.g., GFS reports) for macroeconomic analysis, surveillance, international comparisons, and reporting to international organizations such as the IMF; data for statistical reporting should be generated from the accounting system via a well-designed mapping. ### Reporting entity and budgetary sector (summary of Box 2) - The “reporting entity” concept is used in preparing general purpose financial reports and includes information on resources deployable by the entity, regardless of legal or administrative structure. - A government as a whole (federal, state, territorial or local) would be identified as a reporting entity because users require general purpose financial reports to assess resource allocations and accountability. - Individual statutory authorities and departments (and entities they control) may also be reporting entities because of economic/political significance or financial characteristics. - Identifying a reporting entity requires considering the boundary of economic activities; legal entity existence alone is neither necessary nor sufficient. - A reporting entity can include more than one entity where one controls the others and consolidated financial statements should be presented where appropriate. - Reporting entity vs. budgetary sector: - Entities making up the budget sector (resources allocated through the budget) may individually be reporting entities. - Because budget sector entities are controlled by a government, the government and its controlled entities together would meet the definition of a reporting entity for consolidated reporting. - To fully comply with financial reporting standards (such as IPSAS) or to include all financial transactions controlled by government, coverage of the reporting entity may need to extend beyond the budgetary sector. - The definition of the budget sector varies by country and depends on entities accountable to parliament/legislature; the nature of resources is one factor but not the only one. *Technical Notes and Manuals 11/03 | 2011* *Source: _tnm1103 - Introduction_* ### Box 3. Budgetary Accounting vs. General Financial Accounting – Case of France ### Box 3. Budgetary Accounting vs. General Financial Accounting – Case of France ### Legal framework - Article 27 of the French Organic Budget Law (loi organique relative aux lois de finances, LOLF) of 2001: “the central government shall keep accounts of budgetary receipts and expenditures (comptabilité budgétaire) and general purpose accounts (comptabilité generale) for all of its transactions.” - Article 28 of the LOLF of 2001: budgetary receipts and expenditure payments shall be recognized on a cash basis. - Article 8 of the LOLF: appropriations comprise commitment appropriations and cash appropriations. - Article 30 of the LOLF of 2001: the general purpose financial statements (based on comptabilité générale) are to be based on the accrual accounting principle. ### Budgetary accounting (comptabilité budgétaire) - Purpose: - Track government expenditure and revenue operations to verify compliance with parliamentary authorizations and enforce accountability for proper execution of the Budget Law. - Accounting basis and features: - Recognizes receipts and expenditure payments on a cash basis (Article 28). - Records appropriations at two authorization stages (Article 8): - autorisation d’engagement (authorization for commitments), which could be multiyear; - crédit de paiement (authorization for payments during the budget year). - Records both commitments and payments during the budget execution cycle. - Flow-based, single-entry system that produces a budget execution report but does not produce a balance sheet. - Coverage limited to transactions formally authorized in the Budget Law. - Uses an accounting classification reflecting the nomenclature used in the budget. ### General purpose accounts (comptabilité générale) - Purpose: - Provide general-purpose financial statements to reflect the government’s assets and financial position; enable a more reliable assessment of fixed assets, receivables, and payables. - Accounting basis and features: - Accrual accounting: transactions are entered for the financial year to which they relate, independently of the date of payment or receipt (Article 30). - Objective to align central government general accounts with the French plan comptable (private sector chart of accounts), except where government-specific differences are warranted. - The General Account (Compte Général de l’Etat, CGE) is issued annually alongside the Budget Review Act (Loi de Règlement): - The Budget Review Act records execution of the preceding year’s budget prepared from budgetary accounts. - The CGE describes budget transactions for the year, cash transactions, and results of accounting entries, presented as a balance sheet and a statement of revenue and expenditure. ### Linkage between budgetary accounting and general purpose accounting - Importance: - The linkage between the two systems is an important objective to ensure consistency and enable monitoring of budget execution. - Principle adopted: - Although objectives differ, a common and integrated account coding structure is desirable so that budgetary accounts and accounting records can be linked. - French approach: - France developed a common budget and accounting code—nomenclature budgétaro-comptable—used for both budgetary accounting (commitment and cash basis) and financial accounting/reporting (accrual basis). - Historical changes: - 1988: central government chart of accounts underwent an in-depth review to align with the 1982 plan comptable for the private sector. - 2004: central government chart of accounts modernized again to take into account the move to accrual accounting. ### Implications for COA design and IFMIS - Need for integration: - Budget classifications and accounting classifications should be integrated in conceptual terms and architecturally consistent so linkage is possible for monitoring budget execution. - Risks when not integrated: - Loss of important information undermining budget control and reporting. - Difficulty identifying accounting implications of budgetary operations; identical accounting transactions may not systematically reflect equivalent budgetary operations. - Alternative mechanisms: - Bridge tables (e.g., used under the old French system) can link accounting data with budgetary operations when classifications are not integrated. - Implementation guidance: - Improvements to budget classification should be implemented only when corresponding changes have been made to the COA structure and fully adopted by the IFMIS. - Example risk: introduction of a program segment in the budget classification without corresponding COA/IFMIS changes can result in budget outturn data not being available by programs. ### Key principles for COA design (core principles) - Comprehensiveness: - Capture all required/relevant information; reflect both the budget framework and the accounting framework; embed or harmonize budget classifications in the government’s accounting classifications. - Adequate granularity: - Provide sufficient detail in segments and sub-segments to meet control, accountability, management, and reporting needs. - Mutual exclusiveness: - Define COA segments and attributes to be mutually exclusive to avoid confusion in transaction recording and reporting. - Avoiding redundancy: - Do not create independent segments if information can be derived from another segment; explore relationships between classifications to minimize data capture volume. - Internal consistency: - Use a consistent hierarchical structure and numbering system to make the chart user friendly and reduce coding errors. - Unified framework: - Allow limited local flexibility for subsidiary ledgers but ensure the COA framework is unified so aggregated information uses the same accounting classification. - Scalability: - Allow flexibility for future additions and changes; provide room for growth to accommodate future legal and business requirements. ### Additional factors affecting COA configuration - Institutional framework: - Whether transaction processing is centralized or decentralized affects COA design; recording at commitment and payment order stages must integrate with financial accounting at the payment stage. - Transaction processing platform: - Implementing the COA within the GL module of an IFMIS raises specific configuration issues (see Section IV in source). - Accounting basis: - The choice of cash or accrual basis for budget execution and financial reporting influences COA design. - Governments transitioning from cash to accrual should set up a COA to enable progressive capture of accrual information in line with the transition strategy. - Need for simultaneous definition of accounting policies with the COA to avoid ambiguity when bases differ. ### Key steps in developing a COA (overview) - Carry out a comprehensive business needs assessment: - Define stakeholders/users, their tasks, goals, and information needs drawing from the country’s PFM framework. - Identify stakeholder information requirements to design a COA that supports recording, control, and reporting of government activities. - Identify and design primary classifications essential for budget control, management, and reporting: - Administrative classification: identifies organizations/entities responsible for managing allocated resources (ministries, departments, agencies, budget-funded entities). - Functional/programmatic classification: identifies functions of government or programs to deliver policy objectives; supports COFOG derivation where programs do not straddle functions/sub-functions. *Source: Box 3. Budgetary Accounting vs. General Financial Accounting – Case of France (Technical Notes and Manuals 11/03 | 2011)* ### Box 4. Business Needs Analysis – Key Issues ### Box 4. Business Needs Analysis – Key Issues ### Users of government financial information - Users include policy makers, government managers, parliament/legislature, the broader public, supreme audit institution, credit rating agencies and international organizations. Each of these stakeholders may require data for different purposes. ### Control framework - All governments need to control the use of funds, hold entities accountable and be able to determine if they are delivering on their policy objectives. - Control requirements apply whether the government uses a performance-based or a line-item-based management control of the budget. - The chart of accounts (COA) should take account of: - who are to be held accountable, - why are they held accountable, and - for what types of funds are they held accountable (both for collecting and spending). ### Data structure - Establish data structures to ensure that the data meets users' financial information needs fully and efficiently. - The process must allow data from different dimensions and levels within the organization to be collected, reconciled and consolidated, to enable alternative views. ### Reporting requirements - The COA structure determines what information is captured and made available to meet reporting needs, including: - (i) entity reporting;1 - (ii) financial reporting; - (iii) internal management reporting; - (iv) consolidation reporting, including in-year reporting at the aggregate level; - (v) accountability reporting requirements; - (vi) GAAP/IPSAS reporting requirements; - (vii) segment level reporting; - (viii) program and project reporting/monitoring needs; - (ix) interdepartmental and intercompany reporting (in the case of State-Owned Enterprises); and - (x) other country-specific reporting needs. ### Deriving the balancing segment - In any double entry accounting system, accounts must be balanced (debits equal credits). - Balancing is also required at the segment level for which the trial balance is prepared. - It is common to set the organization segment as the balancing segment, as it is usually the basis for reports generated for accountability purposes. - It is important to conclude where balancing is to happen for appropriate configuration in a computerized system/IFMIS. ### Anticipating future needs - The most tricky part is to identify future needs and design a flexible COA structure that caters not only to current business processes but also can accommodate anticipated future requirements. - Keeping one or two reserve segments is recommended. ### Hierarchy versus segment - The same objective can sometimes be achieved either by defining a segment or by creating parent-child relationships between segment values. - Consider the impacts and pros/cons of each approach for segments such as: - Administrative Classification and Cost Centers; - Functions and Programs; - Natural Account and Economic Classification; and - Projects, Activities and Geographic Classification (regions, cities and municipalities). ### Classification needs and exclusions - Economic: classification includes classification of revenue, expenditure, assets and liabilities and retained earnings. This classification is the basis for preparing government finance statistics (GFS). - Other classifications may be needed to meet budget managers’ and stakeholders’ requirements, e.g., location, project type, entity type, outcome, output, and source of funds (see the Diagram in Annex, which includes Fund and location segments). - Details of vendor or customer type should not be in the GL COA; include these in subsidiary ledgers (accounts payable and accounts receivable) or in profiles stored in other IFMIS modules (e.g., procurement module). - Where multiple classifications exist, explore relationships to see whether some classifications can be derived from others to avoid redundancy between COA segments. ### Structuring data attributes and developing COA segments - Define COA segments and hierarchical levels within each segment. - Use segment relationship diagrams to establish relationships between segments (e.g., mapping to function and mapping to GFS structures) and hierarchy within segments. - Reserved segments to meet future requirements should be invisible to users for now. - The purpose and structure of each COA segment should be clearly defined; classifications and sub-classifications must strictly adhere to their definitions. - Box 5 discusses (i) how to incorporate budget classification and other classifications in the COA; (ii) how to structure each segment into levels based on hierarchical relationships; and (iii) how to organize the general ledger and subsidiary ledgers and link them to the COA. ### Mapping requirements - Identify mapping requirements, e.g., to derive GFS and COFOG classification from other classifications. - Mapping may be one-to-many or many-to-one; the mapping process should be well documented and tested. ### Interdepartmental account/segment - Complex interdepartmental transactions need periodic settlement and reconciliation. - Achieve this either by having an interdepartmental segment reflecting both transacting entities, or by defining interdepartmental accounts. Choice depends on organizational requirements. ### The transaction level and coding - The transaction level19 (also sometimes referred to as “leaf level”) is the lowest level at which actual data is recorded in the IFMIS database. - Distinguish between the COA and the transaction code (Coding Block). The COA is a set of hierarchically structured segments; the transaction code is a combination of segments describing attributes of a specific financial transaction or balance. - If one segment can be mapped from another via a clear relationship, the transaction code should include the lowest level of only the primary segment, with secondary segment(s) derived through a mapping table. - Such a mapping table remains hidden and is automatically applied in a computerized financial management information system/IFMIS to retrieve data classified according to the derived COA segment. ### COA design principles and usability - The COA and its segments should use basic logic and account definition to provide clarity on recording transactions and balances. - Avoid overcomplicating numbering sequences and structure: - If too complex, users will take more time to identify proper accounts. - Creating too many specific account ranges can quickly limit open ranges and force abandonment of the structure. - A simplified but structured numbering system facilitates ease of use and maintenance. - Eliminating redundant and... (discussion continues on practical numbering examples).21 *Box 4. Business Needs Analysis – Key Issues, Technical Notes and Manuals 11/03 | 2011* ### Box 5. Developing a COA - Accounts Classification, Type and Ledger System ### Box 5. Developing a COA - Accounts Classification, Type and Ledger System ### COA purpose and structure - The COA should reflect the budget classification and other classifications. - A well-designed COA includes budget classification (revenue, expenditure and borrowings) plus asset, liability and equity accounts. - The COA also includes any internal management classification such as departments, cost centers, and regions. - Each classification should have its name, a brief description and a code or number assigned to aid in recording, classifying, summarizing, and reporting transactions. - Each classification is organized around a segment. - Each hierarchical segment of the COA can be further analyzed and sub-divided in the form of a parent-child relationship (summary and detail data requirements). - Sub-divisions of a segment are given a numbering sequence to create sub categories (examples: program → sub-programs → projects/activities; administrative segment: ministry → budget and treasury departments → etc.). ### General ledger (GL) and subsidiary ledgers - COA is the basis of the general ledger (GL); COA represents the structure of the GL. - The GL is an accounting book which uses the COA structure to record, report, and reconcile financial data. - Coding structure of subsidiary ledgers (e.g., Accounts Payable module of an IFMIS) must be mapped to respective control accounts in the GL. - Example: GL has a control account for Accounts Payable while the Accounts Payable system has accounts of individual suppliers. - Each purchase is recorded in the Accounts Payable subsidiary ledger and the total recorded in the GL. - At any time, the GL balance can be proven against details in the Accounts Payable subsidiary ledger. - Fragmentation risk: apparent comprehensive GL/COA may be partial if transactions are recorded in varied systems that do not roll up to GL control accounts, impairing report usefulness and data accuracy. ### Account types and economic classification - Account types (also called natural accounts). - Revenue and expense accounts are netted off at year-end and the surplus/deficit is transferred to networth account. - Asset and liability accounts balances are carried forward to next year. - Revenue, expense, asset and liability accounts are further classified using the economic classification. ### Configuring the COA in an IFMIS - Governments increasingly use IFMIS to modernize accounting and reporting systems. - An IFMIS can improve the PFM framework by: - (i) providing real-time financial information that managers can use to formulate budgets, manage resources, and administer programs; and - (ii) supporting the preparation of financial reports and statements. - A well implemented IFMIS can help governments achieve effective control over public finances and enhance transparency and accountability. - COA design should consider impact of other IFMIS modules and subsidiary ledgers; GL module is the backbone of an IFMIS and COA provides the GL structure. - IFMIS usually includes the GL module and at least the accounts payable module; other common modules include accounts receivable, cash management, procurement and payroll. - Linkage between GL and subsidiary ledgers should be clearly established. - Subsidiary ledger configuration combines with the COA in the GL to record, control and report government activities. ### Basic guidelines for a computerized COA - Key issues to consider when developing/redesigning COA for an IFMIS: - (i) establishing one global/unified chart of accounts; - (ii) using simple and basic logic and limiting the number of accounts; - (iii) deciding the accounting basis – cash, accrual or in transition (from cash to accrual); - (iv) understanding and using the vast functionality of modern computer systems; and - (v) scalability to provide room for future growth. - Creating a global/unified COA: - Establishes consistency in terminology and eliminates redundant accounts. - Provides basis for consistency in budget and accounting policies and procedures across government. - Enables coordinated IFMIS functionalities and reduces duplicate data entry and errors. - Simplifies consolidation of individual budget entities into whole-of-government reporting. - Where individual organizations use separate systems, there should still be a unified COA framework; different COAs may be used but must integrate into a unified framework for government-wide consolidation. - Leverage IFMIS functionality to simplify the COA: - Decide which IFMIS subsidiary modules are essential. - Properly designed segments and logical coding structures can produce standard reports without extensive customization. - Balance detail in GL COA vs. detail in subsidiary ledgers: as much detail as possible should be held in subsidiary ledgers (e.g., supplier names in Accounts Payable, asset details in an asset register). - Overly complicated COA may cause significant problems generating reports. - Data normalization is essential in an RDBMS IFMIS: - Organizing data to minimize redundancy is called “normalization”. - Without normalization, reporting functionality may become complicated and data redundancy may impact data reliability. - Standard reports run directly from the IFMIS using coding structures should be the first option. - Reporting functionality should provide access to separate sets of data (in related tables) for comparison of budgeted and actual amounts. ### Amending legal and regulatory framework; change control - New COA often prepared to unify disparate accounting and reporting structures. - Even well-structured COA will require changes over time to meet new business requirements. - Clear institutional, legal and procedural frameworks are essential to prevent COA fragmentation. - Assign clear institutional authority to approve COA changes (e.g., a single point of authority such as the Minister of Finance/Accountant General). - Define roles and responsibilities and procedures for adopting COA changes to preserve integrity. - Principles to ensure COA remains unified and agreed: - Designated process and timeframes to (i) propose changes; (ii) have them reviewed by key stakeholders; and (iii) signoff and publish changes so that all users are advised. Any cyclical process for updates should be no more frequent than quarterly. - Identify the impact of proposed changes to the COA, including whether they fit with core principles and agreed structure. - Clear institutional allocation of authority for authorizing changes to the COA. - All changes to the COA must be consistent with the configuration, i.e., there will be no departure from how the segments are defined or the parent-child relationship. ### Data migration - Develop a data migration plan to ensure historical data is not lost or corrupted when implementing a new or updated COA. - Effective and efficient migration of existing data from old to new COA is a cornerstone for success and improved reporting capability. - Data migration requires considerable planning and is often under-resourced; poor quality data can undermine the usefulness of the new COA. - Both technical and functional IFMIS users must be involved: - Functional users identify which new codes old ones should map to. - Technical support providers supply the technical solution. - Reconfigure historical financial reports to align with the new structure to provide useful historical data for comparison. ### Capacity building and change management - Adequate training of all users across government is fundamental when introducing COA modifications. - Effective change management strategy required to implement new COA and associated reforms; changes bring uncertainty and potential resistance. - Key steps in change management strategy: - securing explicit support from the highest levels of government at an early stage of reform; - identifying organizational changes necessary to implement new processes and changed rules and procedures, clearly articulating the benefits of the changes; - identifying documentation changes, including input (e.g., payment vouchers) and output documents (e.g., management reports, budget monitoring reports, etc.); - identifying human capacity development needs and developing a plan, including a training program, to address existing capacity constraints; - identifying key change agents in the ministry of finance and line agencies; and - developing a plan for sensitizing various users to the new systems and procedures. ### Conclusion and key implementation steps - The COA is the lynchpin of a government accounting and reporting framework and the hub of any computerized accounting and reporting system (IFMIS). - COA design for government should address specificities and stakeholder needs in a given PFM framework. - A COA provides structure and classification systems for organizing, recording and reporting financial information (flows and stocks) and a coding structure for classification and recording. - Where budgeting and financial reporting use different accounting bases, financial reporting may require additional information to comply with relevant standards; nonetheless, a common and integrated account coding structure for both should be possible. - Definition, use and maintenance of COA segments are critical for data integrity and report usefulness. - A well sequenced plan to develop and implement a COA should involve the following key steps: - (i) carrying out a comprehensive business needs assessment; - (ii) harmonizing the budget classification and the COA; - (iii) structuring the data attributes and developing various segments of the COA; - (iv) following basic guidelines for configuring the COA if it is to be implemented as part of an IFMIS; - (v) amending, as necessary, the underlying legal and regulatory frameworks; - (vi) addressing data migration issues; and - (vii) developing and implementing a plan for capacity building of COA users as well as a change in management strategy to effectively implement the COA and associated reforms. - Phased implementation may be necessary to reflect sequencing of other PFM reforms, examples include: - updating the economic classification to implement GFSM 2001; - transition to accrual accounting; - adding a source-of-fund segment to integrate donor financing; and - implementing a program structure for results-based budgeting. *International Monetary Fund — Technical Notes and Manuals 11/03, 2011* --- _Source: https://www.imf.org/-/media/websites/imf/imported-full-text-pdf/external/pubs/ft/tnm/2011/_tnm1103.pdf_