Responsibility units as governed master data: cost centres, profit centres, their managers, their hierarchies and their validity, consistent across finance, HR and planning.
Today a reorganisation is typed into the ERP, then HR, then the planning tool and the BI model, over six weeks, while reports show three versions of the org.
With Lima the cost and profit centres are read where they live, matched on code within a controlling area and name and manager (fuzzy), assembled field by field and published as one golden record per real cost centre, with every source key underneath. Postings, budget lines and positions of a unit, and the hierarchy versions it appeared in are one click away, because the transactions sit in the same bed.
Survivorship is per field; the winning source below is the usual one, and a steward's verified edit outranks it.
A reorganisation is a new hierarchy version with a validity date; the units keep their ids and their history.
Pairs above the merge line merge; pairs between the lines go to the steward with the two records side by side and the transactions of each; the rest stay apart. Every merge can be undone. The golden records page explains the steps.
Several structures for the same record, each kept as versions with dates.
| Hierarchy | Levels and use |
|---|---|
| Standard | controlling area → area → department → cost centre |
| Alternative | any grouping for reporting, versioned |
| Profit | segment → profit centre |
A pivot can roll the record's measures up any of them; a draft version is validated against the facts before it goes live. See hierarchies.
Written in one language, tested on live rows before they are saved.
| Level | Rules |
|---|---|
| Column | valid-to is after valid-from currency is in the code list |
| Row | an active cost centre has an active manager a cost centre with postings this year is in the active standard hierarchy |
| Business | each cost centre sits in exactly one place in the standard hierarchy per version budget by department equals the sum of its cost centres no cost centre closes with an open balance |
| Transactions in the bed | Read from |
|---|---|
| Cost postings | SAP ACDOCA; Oracle GL |
| Budget and plan | planning tool |
| Headcount | HR positions |
Measures above are available in the pivot on any hierarchy level, by month or week, with calculated measures beside them. Drill-down opens postings, budget lines and positions of a unit, and the hierarchy versions it appeared in.
Edits through a finance-approved request; managers read their own subtree; HR reads all. The twelve layers apply on every door; see security.
POST /api/v1/golden/cost-centre/lookup
{
"code": "CC-4410",
"as_of": "2026-04-01"
}200 OK
{
"golden_id": "CC-4410",
"name": "Item data · EMEA",
"manager": "E-19822",
"parent": "DEP-441",
"version": "v13",
"budget_ytd": 1240000
}The same call creates the record when nothing matches; related facts are expanded through the cross-reference; page sizes and limits are published per endpoint. See the headless API.
The objects with their real names, the keys in that system's fields, the write interface and what to set up first.
Cost centre read from CSKS · CSKT.
Open the SAP S/4HANA page →Cost centre segment values read from FND_FLEX_VALUES (cost centre segment) · GL_CODE_COMBINATIONS.
Open the Oracle Fusion Cloud page →Cost centres read from Get_Cost_Centers. 2 objects, the keys in Workday fields, the write path and the prerequisites.
Open the Workday page →Cost centre read from cmn_cost_center. 2 objects, the keys in ServiceNow fields, the write path and the prerequisites.
Open the ServiceNow page →Cost centre read from CONFORMED.COST_CENTRE.
Open the Snowflake page →Names, places and figures are illustrative or anonymised; the pattern is the catalogue's.
A telecom operator ran a reorganisation of 1,900 cost centres as one hierarchy version. HR, the ERP and the planning tool read it on the same day; the finance team's manual re-keying dropped from six weeks to zero.
The golden record is a governed view over rows read in place; a governed replica in your lake is used only where a source is too slow or too limited to query live, and the column says so.
One working day for the first two sources; 2 working days to a production-grade version with rules, hierarchies, security and write-back tested.
Industrial manufacturing, High-tech and semiconductor, Telecom, Financial services. The industry pages show the domains each starts with.
Bring two systems that hold the same customers, suppliers or materials. In one working day we connect them, run the match on live rows, review the queue with your steward and publish the first golden view with its API.