Account Codes: How to Map to FP&A

Key Takeaways

• G/L or account codes can affect budgeting, forecasting, variance analysis, and management reporting.
• Review the existing account structure, define the reporting hierarchy, identify accounts that need restructuring, and create the account mapping before building the model.
• Reconcile mapped accounts to the general ledger and resolve unmapped accounts, classification changes, and other issues that could affect historical comparisons.
• If the G/L or account codes are likely to change, agree on the target structure before building the FP&A model to avoid reworking mappings, reporting hierarchies, and forecasts.
• Define ownership for G/L or account codes and mapping changes and maintain version control so the FP&A model stays aligned with the ERP over time.

FP&A teams can spend weeks building account mappings, reporting hierarchies, and forecast models, only to redo the work when the account codes change. A new account structure can break historical comparisons, change reporting rollups, and leave existing budgets and forecasts tied to categories the business no longer uses.

The codes and hierarchy need to provide enough detail for planning while giving finance a stable structure for reporting and forecasting.

This guide explains how account codes work, how the account codes structure affects FP&A, and how to map ERP accounts into an FP&A model. It also covers when to restructure the account codes that can make it easier to maintain.

What Is G/L or Account Codes?

G/L or account codes is the system of assigning unique codes to financial accounts so they can be identified, grouped, and organized within an accounting or Enterprise Resource Planning (ERP) system.

A code structure typically organizes accounts by category and hierarchy, such as assets, liabilities, revenue, and expenses. The structure should also support financial reporting and make it easier to map ERP accounts into budgeting, forecasting, and FP&A models.

There isn't one universal account coding standard. Number ranges vary by company, industry, ERP, and accounting framework, but a common five-category structure looks like this:

[ Table Caption: Standard account code ranges and categories ]

For example, a company might use account numbers such as:

[ Table Caption: Example chart of accounts numbering structure ]

The exact code convention varies by ERP and company. Some organizations use simple sequential account codes, while others use segments to represent entities, departments, locations, or other dimensions.

How Account Code Structure Affects FP&A

For FP&A teams, G/L or account code structure directly affects budgeting, forecasting, variance analysis, and management reporting. A well-designed account code structure makes it easier to compare actuals against plans and identify the drivers behind financial performance. A poorly structured account code structure can create inconsistent reporting, manual reclassification, and limited visibility into business-unit performance.

The account code structure affects FP&A in several key areas:

• Budgeting and forecasting: Account-level detail determines how precisely teams can build budgets and forecasts. If expenses are grouped too broadly, FP&A may not have enough detail to forecast individual cost drivers.
• Variance analysis: Consistent account structures make it easier to compare actual results with budget and prior periods. Changes in account definitions can make variances difficult to interpret.
• Management reporting: A standardized account code structure allows FP&A teams to roll accounts into reporting categories such as revenue, payroll, occupancy, technology, and other operating expenses.
• Business-unit analysis: Using consistent account and department structures helps FP&A compare performance across entities, departments, locations, or cost centers.
• Data integration: A consistent account code structure makes it easier to map data from the ERP, planning system, and other financial tools without repeated manual adjustments.
• Scenario planning: When accounts are structured around meaningful cost and revenue drivers, FP&A can model how changes in headcount, pricing, volume, or operating costs affect the forecast.

How to Map Account Codes to an FP&A Model

Before mapping account codes to an FP&A model, finance needs to understand how the existing accounting structure supports planning, determine where it creates gaps, and establish a consistent mapping between ERP accounts and the dimensions used for budgeting, forecasting, and analysis.

Here’s a practical seven-step process:

Step 1: Review the Existing Account Codes

Start by documenting how the current account codes are structured and how accounts are used in the ERP. Review the following:

• Account hierarchy
• Account descriptions
• Account types
• Reporting groups
• Additional dimensions attached to accounts

Look for structural issues that could affect planning or reporting. Key areas to review include

• Active, inactive, and duplicate accounts
• Revenue, expense, asset, liability, and equity classifications
• Account hierarchies and existing rollups
• Department, entity, location, project, or cost-center dimensions
• Accounts that combine multiple types of costs
• Accounts with inconsistent naming or classification
• Historical accounts that are no longer used but still contain data

Step 2: Define the FP&A Reporting Hierarchy

Determine how accounting data needs to be organized for planning and management reporting. The FP&A model may not need the same level of account-level detail as the ERP.

Define the hierarchy based on how finance and business leaders need to analyze performance.

Consider

• Budget and forecast categories
• Management reporting requirements
• Materiality of individual accounts
• Department and cost-center reporting
• Entity and location reporting
• Revenue and expense drivers
• Required variance analysis

Step 3: Identify Accounts that Need Restructuring

Once the reporting hierarchy is defined, compare it with the existing account codes. This highlights accounts that do not provide the level of detail or consistency required for planning.

Some accounts may be too broad to support meaningful forecasting, while others may be unnecessarily fragmented and create additional maintenance without improving analysis. For example, if several departments use different accounts for the same type of expense, FP&A may need to standardize the reporting treatment.

Flag accounts that should be

• Consolidated because multiple accounts represent the same reporting category
• Split because one account combines materially different costs
• Renamed because account descriptions are unclear or inconsistent
• Reclassified because an account sits in the wrong reporting category
• Retired or replaced because it is no longer appropriate for current reporting

Step 4: Create the Account Mapping

With the reporting hierarchy established, create the actual mapping between the ERP's accounts and the FP&A model. Each source account should have a defined destination in the planning and reporting structure.

The mapping should be specific enough to understand why an account belongs in a particular category and apply the same logic to future data.

A mapping table might include:

Table caption: Example of mapping ERP accounts to FP&A categories and reporting dimensions

Document exceptions separately. For example, an account may need to be split between two FP&A categories if historical transactions contain multiple types of expenses.

Step 5: Validate Historical Data

Before using the mapping for forecasting, apply it to historical actuals. This step tests whether the new structure produces consistent results and whether historical periods remain comparable.

Start with a representative historical period and reconcile the mapped data back to the general ledger, then review changes in account classifications, newly created accounts, discontinued accounts, and periods where the business used different accounting practices.

Check for

• Unmapped accounts
• Accounts mapped to multiple categories
• Historical accounts with changed definitions
• Large changes in reporting-line balances
• Differences between mapped totals and the general ledger
• Historical periods that require manual reclassification

If the FP&A model uses historical trends to establish forecast assumptions, inconsistent historical mapping can distort those assumptions.

Step 6: Build the Planning Model

Once the mapping has been validated, incorporate the structure into the FP&A model. The model should use the agreed reporting hierarchy as the foundation for budgets, forecasts, scenarios, and variance analysis.

At this stage, connect the mapped accounts to the planning dimensions and assumptions that FP&A uses to forecast financial performance. For example, payroll may be forecast based on headcount and compensation assumptions, while software expenses may be forecast based on contracts, users, or historical spending.

The model should support

• Budget creation
• Rolling forecasts
• Actual-versus-budget analysis
• Actual-versus-forecast analysis
• Scenario modeling
• Department and entity reporting
• Drill-down from reporting categories to source accounts where needed

Build reconciliation checks into the model so finance can identify when mapped data does not tie back to the ERP.

Step 7: Establish Change Governance

G/L or account code mapping is not a one-time exercise because:

• New accounts can be added
• Existing accounts can be changed
• Business structures can evolve

Without a defined governance process, the FP&A model can gradually become inconsistent with the ERP.

Establish clear ownership for approving account code changes and updating the mapping. Ideally, accounting and FP&A should review changes together when they could affect reporting or forecasting.

Define

• Who can create or modify account codes
• Who approves changes to the FP&A mapping
• When new accounts need to be added to the planning model
• How historical data should be treated after a restructuring
• How mapping changes are documented
• How often the mapping is reviewed
• How changes are tested before they reach production reports

Maintain version control for the mapping so finance can trace when a reporting category changed and understand its effect on historical and forecast data.

Should You Restructure Account Codes Before FP&A Modeling?

If account code restructure is already planned, completing it before building the FP&A model can reduce rework later.

Consider a finance team that builds its forecast model around an existing 500-account account codes. Three months later, the company consolidates accounts and introduces a new hierarchy. The FP&A team may now need to remap the accounts, update reporting structures, validate historical data, and revise forecast outputs against the new structure.

Before starting the FP&A build, finance should therefore confirm:

• Whether the current account codes are expected to change
• Which accounts will be added, removed, or consolidated
• Whether the reporting hierarchy will change
• How historical accounts will map to the new structure
• Whether existing budget and forecast templates depend on the current account codes
• Which reports and planning models will need to be updated

Once the target account codes ar agreed, the FP&A model can be designed around the structure finance expects to use going forward.

Account Codes Best Practices

A well-designed account codes numbering system makes accounts easier to identify, group, and map into FP&A reporting structures. Use a consistent numbering logic that reflects the account hierarchy, leaves room for future accounts, and supports efficient reporting as the business grows.

1. Leave room for future accounts: Avoid using a numbering structure that leaves no space between related accounts. Gaps can make it easier to add new accounts without redesigning the numbering system later.
2. Use a consistent numbering convention: Account numbers should follow a predictable structure. Finance teams should be able to understand where an account belongs without relying on individual knowledge of the ERP setup.
3. Keep the account hierarchy logical: Related accounts should be organized in a way that supports financial reporting and management analysis. The hierarchy should make it straightforward to roll detailed accounts into broader reporting categories.
4. Avoid putting too much information into account numbers: Account numbers do not need to encode every reporting dimension. Departments, entities, locations, products, or other attributes may be better handled through separate ERP dimensions or segments, depending on the system.
5. Align the COA with reporting requirements: The structure should support the reports finance actually needs to produce. If management reporting requires a different hierarchy from statutory reporting, the FP&A model may need a separate reporting structure rather than forcing every requirement into the account number itself.
6. Consider FP&A mapping before finalizing the structure: The account codes should be reviewed alongside the planning model. Finance should understand how ERP accounts will map into budgets, forecasts, management reports, and other planning structures before the model is built.

Keep the Account Codes and FP&A Model Aligned

Chart of accounts design is part of the data foundation for FP&A. Account numbering determines how financial data is organized at the ERP level, while the FP&A model determines how that data is used for planning, forecasting, reporting, and analysis.

If the account codes are about to change, finance should understand the impact before locking the planning model to the current structure. Otherwise, account mappings, reporting hierarchies, historical data, and forecast models may all need to be revisited.

Once the account codes and planning structure are aligned, finance can spend less time maintaining mappings and more time using the model to analyze changes in the business.

Limelight can connect budgets, forecasts, actuals, and business drivers in one financial model, giving finance teams a connected structure for planning and analysis. For teams implementing an FP&A model alongside changes to their financial data structure, this can help keep planning inputs and financial data connected as the model evolves.

See how Limelight can help connect your financial data and planning process.

FAQs

What happens if the COA changes after an FP&A model is built?

A COA change can require finance to update account mappings, reporting hierarchies, historical data, and model formulas that depend on the previous structure. The impact depends on which accounts and reporting categories changed and how closely the FP&A model is tied to the ERP structure.

Can FP&A use a different account hierarchy from the ERP?

Yes. The FP&A reporting hierarchy does not necessarily need to mirror the ERP's account structure. Finance can map detailed ERP accounts into broader planning and reporting categories when management reporting requires a different level of aggregation.

Should account numbers encode departments and cost centers?

Not necessarily. Putting every reporting dimension into the account number can make the COA harder to maintain. Depending on the ERP, departments, entities, locations, products, and other attributes can be managed through separate dimensions or segments.

How does COA mapping affect historical financial comparisons?

Changes to account definitions or reporting categories can make periods difficult to compare on a like-for-like basis. Finance may need to remap or reclassify historical actuals so that prior periods use a consistent reporting structure.

Can one GL account map to multiple FP&A categories?

It can, but this requires a defined mapping rule and enough underlying transaction detail to determine how the account should be allocated. If an account combines materially different costs that cannot be separated reliably, restructuring the underlying account may be necessary.