Cost allocation rules

Some cost centres only serve others: IT, HR, the head office. Cost allocation moves their costs onto the cost centres that use them, so every operating unit carries its fair share. A rule says where the costs come from, where they go and in what proportion; a run writes the result into the cube, and a revert takes it back out.

Allocation rules are not mapping tables. A mapping table translates codes on the way into a cube. A rule moves values that are already in it.

What a rule says

Part	Example
Costs move across a dimension	Cost centre
From one item of it, the source	IT
To other items of it, the targets	HR, HQ, OpsA, OpsB
Accounts allocated, a list or a code pattern	Costs, or `6*`
Allocated out, an input item that books the credit on the source	AllocOut
Allocated in, an input item that books the debit on the targets	AllocIn
Driver, the proportion	fixed weights, or a line of the cube

Running the rule books minus the amount on Allocated out of the source and the shares on Allocated in of the targets. The original costs are never changed. A Total costs formula that adds Costs, AllocOut and AllocIn shows each centre after allocation, and the same total over all cost centres stays exactly what it was before the run.

Drivers

Fixed weights are numbers per target: 2 : 1, or 20 / 30 / 50. They are proportions, so they need not add up to 100.
A line of this cube reads each target's own value on another item, such as Headcount or Square metres, in the same period and on every other dimension. A target with nothing there gets no share.
A line of another cube does the same from a driver cube. Set this up through the assistant or the API; the editor shows it and leaves it as it is.

Every coordinate is allocated on its own. The period, version and entity of a cell select the driver values of that same period, version and entity.

Steps and the order they run in

Rules run in their order, lowest first, and each rule can pass on what its source received from earlier rules. That is a step-down: IT is spread to HR, HQ and the operating units, then HR passes on its own costs plus the share of IT it received, then HQ does the same.

A rule may not send costs back to a cost centre an earlier step already allocated from, so a chain such as IT → HR → IT is refused when you save it. Reciprocal allocation, where centres serve each other at the same time, is out of scope.

Preview, run, revert

Preview runs the whole cascade without writing anything and shows what each rule would move, the landing cells with their value now and after, and whether the result nets to zero everywhere.
Run removes the previous run's output first and then runs every enabled rule again. Running twice gives the same result as running once, and changing a driver and re-running leaves nothing behind.
Revert last run puts back the values the latest run replaced. Reverting again walks further back. The History lists every run and revert, newest first.

A rule whose output is still in the cube can be edited, but its dimensions and landing items cannot change, and it cannot be deleted. Revert first.

Where a rule stops

A rule skips a coordinate, and says so in the result, when:

the drivers there add up to zero, so there is nothing to divide by;
a driver is negative;
a landing cell is locked, by a cell lock, a workflow state or your access rule. Nothing at that coordinate is written, so it is never half-allocated.

Every other coordinate still runs. The result counts the stops of each rule and names the first.

Who can do what

Editors can create, run and revert rules; the entry sits under Data in the sidebar and is not shown to viewers. A user with an access rule on the cube can only run allocations that land in cells they may write.

With the assistant

The assistant has the same rules as tools that use dimension names and item codes: list_allocation_rules, create_allocation_rule, update_allocation_rule, delete_allocation_rule, run_allocation (with dryRun for a preview), revert_allocation and get_allocation_runs.