Skip to content

Planning & dimensions

Two different jobs that both sit on the same analytical axes as your actuals: budgets that control spending, plans that inform expectations, and the dimensions that make both comparable to the ledger without reconciliation.

Budgets & commitment control (/budgets)

Load a budget version and its lines (an account, a dimension tuple, a period, an amount) and adopt it, which freezes the targets. See available budget (budget − actual − open commitment), budget-versus-actual, and open commitments.

The control that makes a budget real is commitment (encumbrance) accounting:

  • Approving a purchase order consumes budget: it raises an encumbrance.
  • The invoice liquidates that encumbrance.
  • Closing or cancelling the PO releases the residual.
  • A PO that would exceed the available budget is refused before it is placed.

Each budget coordinate has a control mode: block (refuse), warn, or track (the default).

Commitments post to a separate budgetary ledger (a budgetary account type, excluded from the financial statements), so encumbrances never distort your real P&L or balance sheet:

Event Debit Credit
Commitment raised Encumbrances Reserve for encumbrances
Liquidated / released (the reversal)

The financial actual is just payables' ordinary invoice posting. Budget adoption itself is stored, not posted. Commitments are driven only by procurement and payables events: there are no manual commitment endpoints.

Permissions: budget:manage, budget:adopt, budget:read.

Planning & forecast (/planning)

Create a scenario, load plan lines on the same coordinates as actuals (entity, cost centre, project, account, period), baseline it (which seals it), branch what-ifs from a baseline, and read variance (actual − plan) and a rolling forecast (actuals to date, plan beyond).

  • Lifecycle: DRAFT → BASELINED → ARCHIVED.
  • A plan sits on the same axes as actuals, so variance is a subtraction, not a reconciliation.
  • A budget refuses; a plan informs. They are different tools: one is a control, one is an expectation. Baselining seals a plan; what-ifs branch, they never overwrite.

Planning never posts: it is expectation, not fact, so the trial balance is unaffected.

Not yet built

The forecast roll-forward endpoint is not yet built (the variance query is). Driver-based and ML forecasts, group-plan elimination, multi-currency plan translation and spreadsheet import/export are deferred.

Permissions: planning:manage, planning:baseline, planning:read.

Dimensions (/dimensions)

The analytical axes every ERP posting can carry: cost centres, projects, funding sources, departments and more. Maintain the members as an effective-dated hierarchy (code, name, parent, validity window), and view a trial balance rolled up an analytical axis with drill-down to the leaves (/dimensions/balances).

  • ERP postings can carry up to eight dimensions; banking carries two (branch, counterparty branch).
  • Dimensions are validated per posting: against the tenant's dimension profile, member validity, which axes an account requires or forbids, and which combinations are allowed.
  • They are preserved as-at-posting: if the org structure changes later, historic postings keep the dimensions they had.
  • Dimensional balances are an additive projection: they do not touch the banking hot path, which simply writes no dimension.

The dimension strip you see on posting screens is rendered from the tenant's profile: two axes for a bank, up to eight for the ERP.

Permission: dimension:read. The dimension screens post nothing; dimensions ride on other modules' postings.