08.04 Choosing Your Level of Granularity

08.04 Choosing Your Level of Granularity

The most important decision before you build anything

Before you configure a single input template, you need to decide at what level planners will enter numbers. This decision determines the structure of your input templates, the way submissions are stored, and what is possible in reporting. It also triggers the dimension-locking behaviour described in 08.03 — so getting it right before any live submissions begin matters considerably.

FastClose supports three main approaches:

Approach

Planners enter numbers against…

Best suited to

Account Nominal level

Individual account nominal codes — no cost centre or division breakdown

Consolidated, whole-business planning with no organisational split

P&L / hierarchy level

Named P&L lines (e.g. Salaries, Travel, Revenue) that map to account groups

P&L owners thinking in management report terms

Full GL Account level

The composite GL account — account nominal + division + department combined

Detailed bottom-up planning at the most granular level available

Account Nominal level

This approach collects planning data at the chart-of-accounts level across the business as a whole. There is no split by cost centre, division, or department — you are planning the consolidated account balance for each nominal.

In Epicor terms, this means the down axis of your input template includes Segment1 (the account nominal) only. Segment2 and Segment3 are not included.

image

Use this when your planning process doesn't require an organisational breakdown — for example, a high-level finance-led budget where a single figure per account is sufficient.

P&L / hierarchy level

This is the most common approach for management reporting teams. Planners see a P&L laid out the way it appears in board reporting — Revenue, Cost of Goods Sold, Gross Profit, Salaries, Overheads — and may enter numbers against each named line rather than against individual account codes.

image

FastClose uses its hierarchy engine to map those named lines to underlying account ranges. Individual account codes do not appear on screen — planners work entirely in business language.

Whether the P&L is split by organisational unit is a separate decision: you can collect a single consolidated P&L for the whole business, or have each division or department submit their own P&L, with the organisational segment included in the template's down axis.

This approach is covered in full in Module 08.07.

Full GL Account level

This is the most granular approach. In Epicor, the full GL account is a composite code combining:

Planning at full GL Account level means every submitted figure is stored against a specific nominal within a specific division within a specific department. This gives maximum reporting flexibility and the ability to drill to any level of detail, but requires the most effort from contributors and the most careful template design.

image

Use this when your organisation genuinely needs bottom-up budgeting at departmental and divisional level, and when the planning process has the resource to support that level of detail.

The dimension constraint within a scenario

Within a single scenario, the dimension combination used for submissions must be consistent. When the first figure is submitted to a scenario, FastClose records the dimensions in use. Every subsequent submission to that scenario — regardless of which template it comes from — must use the same dimension combination.

This means you cannot, for example, have one template submitting at Account Nominal level and another submitting at Full GL Account level into the same scenario. If you need to support genuinely different levels of granularity simultaneously, use separate scenarios.

Different templates can feed the same scenario, provided they all use the same underlying dimension combination — for instance, two Full GL Account templates filtered to different departments are both submitting at Segment1 + Segment2 + Segment3, which is consistent.

See Module 08.03 for more on how to view and manage the locked dimensions on a scenario, and how to disable the lock if you need to change approach.

Choosing the level within the account hierarchy

Separately from which dimensions you include, you also choose at what level within the account hierarchy submissions are made.

Individual account codes (leaf nodes)
Planners enter a number against each raw account nominal. Maximum granularity within the hierarchy; the default for Account Nominal and Full GL Account approaches.

Aggregated hierarchy nodes
Planners enter a single number against a named group — for example, a Travel node that encompasses car fuel, train tickets, and accommodation nominals. The breakdown between those nominals isn't planned; only the total is collected.

To enable submission at an aggregated node level, open the hierarchy in Designer, select the node, and tick the Submit checkbox. A node with Submit ticked will appear as an editable cell in the planning report; its children will not appear at all. If Submit is not ticked, the node rolls up from whatever is submitted beneath it.

Design this deliberately. A manager who submits a total against a Travel node cannot later break that total out by individual nominal without clearing and re-submitting at a lower level. Decide upfront which nodes need Submit enabled, and configure the hierarchy accordingly before any live submissions are made.

How to decide

Work through these questions:

  1. Who is entering the numbers? A finance director entering an annual cost envelope thinks very differently from a department manager building up estimates account by account. Match the template to the planner.

  2. How will you report? If your board pack has 15 named P&L lines, planning at nominal level gives you detail but requires extra work to map back to those lines. Planning at the named-line level maps directly. Plan at at least the level you want to report at.

  3. Do you have actuals at the level you want to plan? FastClose shows actuals and plan side by side. If a nominal has no actual transactions, no row appears for it automatically — you'd need to add it manually (Module 08.11). Planning at an aggregated hierarchy level sidesteps this for the initial setup.

  4. What granularity do you genuinely need? Full GL Account planning captures everything, but the data-entry burden is significant. Figures entered at that level of detail are not necessarily more accurate than a well-considered P&L-line total.

Recommendation for most first implementations: Start with P&L hierarchy-level planning (Module 08.07). It gives contributors a familiar view, maps directly to how you report, and avoids the complexity of account-code and segment management. Move to Full GL Account level only where the process genuinely requires it.

What you've learned

You have a clear framework for choosing between Account Nominal, P&L hierarchy, and Full GL Account planning, understand the dimension consistency constraint within a scenario, and know how hierarchy node Submit settings shape what contributors can and cannot enter. Go to Module 08.05 to test that your setup works, then to whichever of 08.06, 08.07, or 08.08 matches your chosen approach.

Powered By