Skip to main content
A few concepts run through the whole platform. Learn these once and every screen reads clearly.

Budget versions

A budget version is a named container for a plan: its forecast window, assumptions, headcount, revenue, and derived GL all live inside one version. You always work in the context of exactly one version, and a selector at the top of the app tells you which one.
  • The live version (unlocked) is where active planning happens. Edits land immediately and the engine recomputes downstream.
  • A locked version is a frozen snapshot. You compare against it but cannot edit it.
A typical workspace carries several versions side by side: a “2026 Plan” you locked at the start of the year, a “Rolling Forecast” you update every month, and maybe an “Aggressive Hiring” scenario you are stress-testing.
A version’s label year is just a label. Plans are driven by the forecast window (the start and end month you set), not by the version’s name. A live Rolling Forecast can carry a label of 2025 while it covers 2026, so always reason from the window, not the title.

Actuals vs forecast

Novaplan keeps actuals (what actually happened, immutable, append-mostly) strictly separate from forecast (what the engine projects, regenerated on every run). They live in different tables with different identifiers and different audit rules. Reports stitch them together at the boundary month, so you see one continuous line from history into projection without the two universes ever mixing. Why the separation matters: an actual posted in March never changes when you re-run the forecast, and a forecast for next March is free to update on every run without disturbing anything you have already closed.

The two universes: GL and domain

Every number you see lives in one of two universes, joined by a bridge. The domain universes are where you plan with real-world objects (a person, an open req, a subscription). The GL universe is the common ledger that all reporting reads. Headcount and revenue each derive into the GL through a bridge, so a dashboard built on the GL always reflects your latest people and revenue plans without anyone re-keying numbers. This is also why a domain figure and a GL figure for “the same thing” can differ slightly: GL P&L can include accruals, contractor spend, and recruiting fees that the per-employee cost model does not. That gap is the universe difference, not an error.

Dimensions

Departments, entities, GL accounts, products, channels, and regions are dimensions. They are the axes that power every filter, group-by, and pivot across the app. Admins manage how raw data from your source systems maps onto canonical dimensions in Admin, then Dimensions. Identity is resolved by ID, not by name, so an upstream rename (a department relabeled in your HRIS) never scrambles your hierarchy.

Scenarios

A scenario is a what-if layered on a version. Change a few assumptions (hiring pace, growth rate, attrition) and compare the result against the base without ever disturbing the base. Scenarios let you ask “what if we hold hiring flat?” and see the cost impact side by side before you commit. See Scenarios.

Lock levels

Locking freezes a version so its numbers cannot drift after a cycle closes. When a version is locked, its data is served from a snapshot taken at lock time, so historical comparisons stay stable forever. Lock levels let you freeze progressively, from external-facing data only up to everything: A concrete example: you present the 2026 Plan to the board in January and lock it at the external level. From then on, every “plan vs actual” report reads the board figures from the snapshot, so the variance story stays honest even as your live Rolling Forecast keeps moving. When the year fully closes, you raise the same version to all and it becomes a permanent baseline.
Lock-awareness is automatic. Planning surfaces route reads to the snapshot when a version is locked and to live data when it is not, so you never have to check a lock flag yourself.