Skip to main content
Use a Functional P&L when the chart of accounts alone does not match how management reviews the business. It lets you organize operating performance around functions, cost centers, or other mapped dimensions while retaining a path to actuals and transactions.

Functional P&L and standard P&L

A standard P&L primarily organizes activity by group account. A Functional P&L can add dimension criteria to individual nodes in the layout. For example, one salary account can contribute to separate Sales, Product, and Administration sections when the underlying transactions carry a mapped department dimension.
The account is not duplicated in the source data. Each placement defines which part of the activity belongs in that management view. Functional P&L actuals with Operating Expenses split into Research & Development, Sales, Marketing, Customer Support, and Administration, and Administration further split into Headcount and Other OPEX

Before you begin

  • Confirm that the relevant local accounts map to group accounts.
  • Map the dimensions and values used to define each business function.
  • Review dimension coverage for the reporting period.
  • Decide how activity without the required dimension should appear.
Incomplete dimension mapping can leave valid transactions outside the intended functional row. Resolve material unmapped values before relying on the result.

Design the operating view

Build the high-level functions that match the management review, then add the accounts and dimension filters that define each function. Use node-level dimension filtering when:
  • the same account contains activity for several business functions;
  • management ownership follows a department, project, region, or cost center;
  • a broad account needs to be split into more decision-useful views;
  • the same account needs to appear in more than one explicitly filtered placement.
Avoid overlapping criteria unless duplicated activity is intentional. If two nodes match the same transaction, confirm how that duplication should be interpreted in the report. Checkpoint: Each functional row has a clear account and dimension scope, including an intentional treatment for unclassified activity.

Write dimension rules with Simple or Advanced mode

Each node’s dimension filter has two editing modes. Switch between them from the Simple and Advanced tabs at the top of the dimension picker. Use Simple mode when the rule is a flat list of dimension values. Values you select within one dimension are combined with OR, and dimensions are combined with each other in the way the picker already shows. This is the mode most existing layouts use, and it stays the default for new nodes. Use Advanced mode when the rule needs mixed AND / OR logic that a flat list cannot express. Advanced mode builds one or more condition groups. Within a group:
  • Values inside one dimension are combined with OR.
  • Different dimensions inside the same group are combined with AND.
Condition groups are then combined with each other using OR. This lets you write expressions like:
In this example the row includes Marketing activity in Finland and Sales activity in Sweden, but excludes Marketing activity in Sweden and Sales activity in Finland — a scope a single flat list cannot describe.

Build an Advanced rule

Open the dimension picker on a node and switch to Advanced. Any values already selected in Simple mode are converted into equivalent condition groups so the existing scope is preserved.
  1. In the first condition group, select Add dimension and choose a dimension.
  2. Select Add value to pick one or more items in that dimension. Values within one dimension are ORed together.
  3. Add more dimensions to the same group to require all of them at once (AND).
  4. Select Add condition group to describe an alternative combination. Groups are ORed together.
  5. The Resulting filter preview at the bottom of the picker shows the expression that will be saved.
Switching back to Simple discards the group structure. Only do it when the current expression can be represented as a flat list.

Allocate shared values with allocation keys

Use an allocation key when a shared cost or revenue is booked to one place but management wants to attribute it across entities or dimension items. An allocation key produces monthly weights on either the entity axis or one mapped dimension axis, and Control applies those weights to any account row that references the key. For example, you can allocate €100,000 of warehouse rent by each entity’s share of revenue:
The allocation changes the management-reporting attribution. It does not create journals, change source transactions, or change the consolidated total.

Live driver and manual keys

Every allocation key has a key type that determines how the weights are produced:
  • Live driver keys derive the weights from actuals. Each period, Control sums the selected grounding rows and turns each target’s share of that sum into its weight. Weights recalculate automatically as source data changes.
  • Manual keys use fixed monthly percentages that you enter yourself. Every month must total exactly 100%. Blank months fill forward from the last month you entered, so you only enter a new column when the split changes.
Use a Live driver key when the split should track another metric (revenue, headcount, floor area). Use a Manual key when the split is set by policy, contract, or budget and does not follow actuals.

Build the grounding for a Live driver key

The grounding defines the driver basis that adds up to 100%. It combines three optional filters:
  • One or more accounts, groups, or formula rows.
  • A restriction to specific dimension items (for example, only the Sales department).
  • A restriction to specific entities.
Adding filters narrows the driver population. For example, grounding on the Revenue group and the Product-line dimension items Hardware and Services splits by each target’s share of hardware and services revenue only. Leaving the dimension-item and entity filters empty uses every eligible row.

Create an allocation key

Open the .
  1. Select Allocation Keys, then select New key.
  2. Enter a descriptive Name and choose a Key type of Live driver or Manual.
  3. For a Live driver key, build the Grounding: pick one or more driver accounts, groups, or formula rows, and optionally restrict the grounding to specific dimension items or entities.
  4. Under Split by, select Entity or Dimension. For a dimension allocation, also select the mapped dimension.
  5. Select the Target items that can receive the allocation.
    • For a Live driver key, leave every item unchecked to include all eligible targets.
    • For a Manual key, you must pick each target explicitly.
  6. For a Manual key, enter the monthly percentages in the Weights grid. Every month must total exactly 100%; blank cells fill forward from the latest entered value.
  7. For a Live driver key, select Preview to review the driver values and proposed weights for the latest complete month.
  8. Select Save key.

Assign a key to receiving items

Assigning a key is a two-step choice: first the key, then the items on that key that should receive a share.
  1. In the Allocation Key column, open the picker on an account or group row.
  2. In 1 · Allocation key, choose the key (or No allocation to clear an assignment).
  3. In 2 · Receiving items, tick the items that should receive a share of that row. Use Select all and Clear all for bulk changes.
  4. Select Apply to row.
The editor cell shows the key name and a comma-separated summary of the receiving items on one line. Hover the cell to see the full list. Unchecked receivers stay on the source row as an Unallocated remainder for that assignment. Control never renormalizes the checked receivers to cover the omitted share, so a partial receiver selection is a deliberate way to allocate only part of an amount.

Assign a key to a whole group

Assign a key on a group row to allocate every account underneath it in the same way. Each child account inherits the group’s key and receiver selection until you assign a different key on the child, which overrides the inheritance for that row only. Inherited assignments are labelled (inherited) in the picker so you can tell them apart from assignments made directly on the row. One allocation key can be reused by many rows, but each row uses only one key at a time. Editing a reused key updates every row that references it. Clear all assignments before deleting a key.

Verify allocated actuals

Open the . Expand an assigned account row to see one child row per selected receiver, plus an Unallocated row when the receiver selection did not cover the full amount. The Allocation Key column on each receiver row shows the weight applied for the visible periods, matching the active comparison mode. When the weight is the same in every visible period, Control shows the single percentage; otherwise it shows a range. Hover the cell to see each period’s weight. Check that:
  • the receiver rows plus any Unallocated row add up to the source account row;
  • each period uses that period’s driver values (for Live driver keys) or the manually entered weight;
  • entity or dimension filters show the target’s allocated share without recalculating the weights from only the visible targets;
  • affected subtotals and formulas use the allocated attribution; and
  • the consolidated source total remains unchanged.
If a Live driver key’s eligible driver values total zero or contain both positive and negative values in the same period, Control keeps the full source amount in Unallocated for that period instead of applying an unreliable split. Review the grounding, reporting period, and target restrictions before relying on the result.
Receivers you did not select are treated as an intentional partial allocation. The selected receivers keep the weights the key produced; the remainder stays on the source row as Unallocated.

Validate the result in actuals

Move from the layout into actuals and keep the period and entity selections aligned with the mapping coverage you reviewed.
  1. Review each material function separately.
  2. Drill into a row and confirm that its transactions carry the expected account and dimension values.
  3. Compare the combined functional view with the standard P&L where the structures are intended to reconcile.
  4. Investigate unexplained differences as missing mappings, overlapping filters, excluded values, or deliberate management adjustments.
You can compare Functional P&L results across periods without rebuilding the layout filters. This makes the view suitable for recurring operating reviews after the initial structure has been validated.

Narrow the actuals view with a rule

The actuals toolbar has the same Simple / Advanced dimension rule builder as the layout editor. Use it to filter the current view without editing the layout — for example, to look at one country during a review while keeping the underlying layout unchanged. Actuals rules and layout rules combine with AND. The row still has to match its layout scope; the actuals rule then narrows what appears inside it. If a node’s layout rule is (Cost Center: Marketing AND Country: Finland) OR (Cost Center: Sales AND Country: Sweden) and you add an actuals rule for Product line: Hardware, the view keeps the two layout branches and requires Hardware inside each one. Advanced actuals rules are available on Functional P&L only. They travel with the URL and any saved view, so reopening the same view restores the same expression.

Pivot dimension items into columns

Turn on Pivot selected items into columns in the actuals toolbar’s dimension picker to show one column per selected item from a single dimension. Use it to compare the same row across a small set of dimension items, such as several product lines or cost centers, side by side. Requirements and limits:
  • Available on Functional P&L only.
  • Every selected item must belong to the same dimension.
  • Up to 10 items can be pivoted at once.
  • Dimension-item pivot cannot be combined with entity pivot; enabling one turns off the other.
Each pivot column adds its dimension item to every condition group in the active rule. Row scope, other dimension filters, and every OR branch of an Advanced rule are preserved, so the pivot narrows the view consistently across all branches instead of collapsing them. Condition groups and pivot selections persist through pivot toggles, saved views, URL state, layout copying, and AI-assisted layout revisions. If a dimension item referenced by a rule is later deleted, Control removes it from the affected groups without disturbing the rest of the expression.

Important considerations

  • A Functional P&L is a management view; it does not rewrite source accounting classifications.
  • Dimension quality determines the reliability of the functional split.
  • Duplicate account placements require deliberate, non-overlapping filters unless duplication is the intended result.
  • Advanced dimension rules combine values within a dimension with OR, dimensions inside a condition group with AND, and condition groups with OR. Layout rules and actuals-view rules are combined with AND.
  • Dimension-item pivot columns keep every OR branch of the active rule and narrow all of them with the pivoted item.
  • Allocation keys restate attribution on either the entity axis or one mapped dimension axis. They do not change source transactions or consolidated totals.
  • Live driver weights are period-specific. A zero or mixed-sign driver leaves the source value explicitly unallocated for that period.
  • Manual keys require every month to total 100%. Unentered months fill forward from the last entered month.
  • Selecting only some receivers on a row is an intentional partial allocation; the remainder stays on the source row as Unallocated and is never renormalized.
  • Changes to source dimensions or mappings can change historical views when the data is reprocessed.