Dimensional posting: the decision you cannot retrofit

The request always arrives phrased the same way, and always at the wrong time: "We need project profitability for the last three years." The books are clean, the trial balance reconciles to the last dinar. And the report cannot be produced — not because nobody knows how to build it, but because the journal line never had a field a project could go into. The data is not hidden. It does not exist.

What a ledger line actually remembers

In modelling terms the general ledger is small. Everything downstream — trial balance, account cards, the income statement, dimensional analysis — derives from one narrow structure: the journal line. It carries exactly what the model gave it and nothing more.

• Date and period — where the value lives, and whether the line may be touched.
• Account — the kind of value, inside a chart prescribed by regulation.
• Amount and side — the entry balances to zero or it does not exist.
• Link to the source document — invoice, goods receipt, statement, payroll run.
• Dimensions — if the model has them: cost centre, project, channel, organisational unit.

The last item is the only optional one, and that is the point. The account answers what kind of value arose: material cost, revenue from goods, a payable to a supplier. The dimension answers whose it is — which project, which cost centre, which channel. The two are orthogonal, and no number of digits appended to an account code changes that.

The first reflex: analytical accounts

The first proposal is nearly always the same, and it comes from experience rather than ignorance: extend the account. The regulated frame stops at the third digit; the fourth and fifth are ours. Account 5130 becomes 5130-01, 5130-02, 5130-03, one per project. For one angle with few, slow-moving values, this works for years.

The trouble starts with the second angle: you also need cost centre, because the project is run by three people from two departments. The account can no longer be a list; it has to be a product. With 42 expense accounts, 14 cost centres and 30 active projects that is 17,640 analytical accounts; add a channel with four values and it is 70,560. This is multiplication, not rhetoric: analysis inside the account code grows as the product of angles, dimensions grow as their sum. Each code is an account somebody opens, maps to a statutory line, and closes at year end.

Why this is a non-retrofittable decision

History has nothing to be filled from

Adding a column is trivial. Adding the data is not. For an entry posted in May 2023 the project information exists nowhere: at best it is free text in the description, or a spreadsheet kept by someone who has since left. What gets proposed — "we will derive it by rule: every invoice to customer X between March and September belongs to project Z" — is an assumption wearing a migration's clothes. Books that were exact now hold estimated numbers, and six months later nobody can tell which are which.

"Unassigned" becomes your largest category

Suppose you drop the reconstruction, which is more honest. The column fills from the cut-over date, history is empty. Every dimensional report now picks: skip the history, or show it as an "Unassigned" bucket holding everything before the cut. But comparison was the reason you wanted the dimension. The first one that means anything arrives two full years after switch-on: a decision taken in year three yields insight in year five.

Control exists only at the moment of posting

A dimension without rules is a field that sometimes gets filled in. To be data it needs a matrix: which account requires which dimension, which forbids it, which leaves it optional. An expense account must not post without a cost centre; a supplier payable does not need one. Switch it on in year three and the whole history violates it, leaving two exits: exempt the history permanently — a footnote on every report from then on — or make the rule soft, at which point it is not a control. Reposting closed periods is not a third exit: VAT has been filed against them, the statements filed and, for audited entities, reviewed. Rewriting three years of ledger is an act with legal consequences, not a data edit.

Dimensions live in the document chain, not in the ledger

The journal column is the last five percent of the work. The value must be derived where it arises — on documents: the purchase order carries the project, the goods receipt inherits it, the supplier invoice confirms it through three-way matching, landed costs from the customs declaration allocate onto the same lines, the work order carries the cost centre, a LOT-controlled issue under FEFO carries its purpose, payroll spreads gross and contributions across organisational units — a split the statutory PPP-PD filing ignores and your project report needs. If the chain does not carry the dimension, the ledger column is empty exactly as before, only with a better name.

Anatomy of a retrofit

1. 1

   Inventory of angles

   Which dimensions exist, what values, what hierarchy. It sounds like one workshop; in practice it is weeks of argument about what a "project" is — a contract, a site, a customer, a budget line — because three departments have three answers, all correct until they met in one column.

2. 2

   Model and rules

   The account × dimension matrix: mandatory, optional, forbidden. For a dimensional balance sheet, not just a P&L, entries must balance to zero per dimension value — a materially different demand on the posting engine.

3. 3

   Derivation on documents

   Every document type that produces a posting needs the field, a default, a derivation rule and validation: procurement, sales, warehouse, production, payroll, fixed assets. The largest part of the work, and the part no script shortens.

4. 4

   The decision about history

   From which date. Make the call in the open and write it down; it will be asked for years. Every "we will reconstruct it backwards" clears one bar: may the result sit beside an audited statement without a caveat. Usually not.

5. 5

   Opening balances per dimension

   For balance sheet accounts you want dimensioned, the opening position must be allocated across dimension values. Otherwise the first dimensional balance carries an unallocated remainder that rolls forward every year.

What a model that survives this looks like

• Dimensions are their own registers, not digits in an account code. A value has a validity period — a project opens, closes and stays in history instead of hanging in the chart forever.
• The matrix is versioned by period. A rule from 2026 must stay visible after it changes in 2027, or history appears to violate rules that did not exist.
• The value is derived from the source document, not chosen in the journal. The accountant does not know which cost centre a consumption belongs to — the work order does.
• Balancing per dimension is an option, not a global switch. Overkill for a cost centre; a precondition for a project with its own balance sheet.
• The dimension on the document and in the ledger are the same datum, not a copy. Copies diverge, and then two disagreeing reports are both "from the system".

How NG One frames the decision

NG One posts dimensionally from the first line. Dimensions are part of the ledger's basic shape rather than an extension of it: cost centre, project, channel and organisational unit are registers of their own, and a value in a register has a validity period — a project opens, closes and stays in history without a single new account. The account × dimension matrix sits in the same layer as time-valid statutory parameters: data with a validity period, not a constant in code, so a rule from 2026 stays visible after it changes in 2027. The document chain works the same way — the field sits on the purchase order, the goods receipt, the work order and the payroll run, not only on the journal, so the value is derived where it arises instead of being guessed at the end of the chain.

If your system already runs without dimensions

1. Cut over at a financial year boundary — the only date everyone understands without explanation.
2. Turn dimensions on at the documents first, the ledger second. In reverse you get a hand-filled field, and a hand-filled field is filled in for about three months.
3. Start with one dimension and few values. A cost centre with fourteen values populated consistently beats five populated when somebody gets around to it.
4. Leave history as "Unassigned" and say so on every report. An honest gap is usable; an estimate that looks like data is not.
5. Record the decision and the cut-over date where an auditor reads it. The question returns every year, with new people.