Accounting first
We start from the policy and the group structure, not from a configuration guide. If the accounting treatment is not agreed, no amount of configuration will settle it later.
Financial consolidation
Design the Consolidation Model Before You Configure the System.
Radixa helps organisations translate accounting policy, group structures, ownership, intercompany requirements, reporting and data into a coherent consolidation design that can be implemented — and then operated.
When this matters
Most consolidation problems are design problems wearing a configuration costume.
When a consolidation solution is difficult to operate, the instinct is to look at the build. Occasionally that is where the fault is. Far more often the build faithfully implements a design decision that was never made deliberately — a method that was assumed, a structure that was inherited, a reporting requirement that arrived after the data model was fixed.
Those decisions are cheap to take at the start and expensive to revisit once there is a closed period sitting on top of them. This engagement exists to take them properly, in the right order, with the right people in the room.
What we see
Six things that put a consolidation design at risk.
Consolidation methods and ownership were never agreed in accounting terms
The build starts, and three months later somebody asks how a joint venture acquired mid-year should be treated. By then the data model has already assumed an answer.
FS item and subitem structures cannot support the reporting that was promised
Movement detail, cash flow and segment analysis all depend on decisions taken at the very start. Retrofitting them after the first close is expensive and rarely clean.
Intercompany and partner design creates reconciliation work rather than removing it
Partner assignment, matching tolerance, currency treatment and the point at which differences are cleared are design decisions, not configuration details.
Segment or management reporting arrives late
A second reporting view introduced after the legal consolidation is designed usually means either a parallel structure or a rebuild. Both are avoidable if it is known up front.
Legacy BPC logic is being copied forward without challenge
A decade of script logic contains genuine requirements and a great deal of work around limitations that no longer exist. The two have to be separated deliberately.
Nobody owns the whole picture
Accounting policy sits with Group, the data model with IT, reporting with FP&A and the configuration with an integrator. Each is reasonable on its own and the design falls between them.
How we work
Four principles that shape the design.
Design the edge cases explicitly
Step acquisitions, disposals part-way through a period, indirect and multi-level NCI, method changes, restatements. These decide whether a design survives its second year.
Write the decisions down
A design decision that lives only in somebody’s memory is a design decision you will have to make again. The decision log is a deliverable, not a by-product.
Constrain the cleverness
Your team has to operate this after we leave, and explain it to an auditor. That is a real constraint on how elaborate the design is allowed to be.
What you get
A design somebody can build from, and an auditor can follow.
- Consolidation design principles and a decision log that records what was chosen and why
- Target consolidation model and master-data architecture
- FS item, subitem and dimensional design recommendations
- Ownership, consolidation methods and investment-consolidation design
- Currency translation design, including CTA treatment and rate governance
- Intercompany scope, matching and elimination design
- Data flow and ACDOCU design view
- Reporting and reconciliation architecture
- Risks, open decisions and implementation guidance for the build team
- Typical duration
- 2–6 weeks
- Depending on whether the engagement is a focused design review or a full blueprint, and on the number of entities, ownership levels and reporting views in scope.
Who it is for
Brought in before the build — or when the build is being questioned.
- Finance transformation leads scoping a consolidation programme
- Group Accounting and Group Reporting teams who will own the result
- Solution owners inheriting a design somebody else specified
- System integrators who need design depth rather than extra configuration capacity
- Organisations part-way through a build where the design is being questioned
Related
Where this sits.
- SAP S/4HANA Group Reporting — the platform this design is most often implemented on
- Group Reporting Health Check — if the solution is already live and you want it reviewed rather than designed
- BPC Modernisation & Platform Assessment — if the platform decision itself is still open
- Finance Data & Reporting Architecture — where consolidation sits in the wider landscape
Next step
Tell us what the design has to cope with.
Group structure, ownership complexity, reporting views, the platform if it is decided, and what has already been built. That is enough for us to say whether this is a two-week review or a full blueprint.