Intercompany
ICMR for intercompany matching and reconciliation, and how it connects to the elimination logic and the close calendar rather than running alongside it.
Flagship service
SAP Group Reporting, Designed Around Finance.
Group Reporting succeeds when accounting policy, process design, master data, consolidation logic, reporting and system architecture work together. Radixa supports organisations from early design decisions through implementation, migration, assurance and optimisation.
When this matters
Most Group Reporting difficulty is a design problem, not a product problem.
SAP S/4HANA Group Reporting is capable of handling genuinely complex group structures. Where implementations struggle, the cause is usually upstream of the system: consolidation methods that were never agreed in accounting terms, master data that cannot support the required reporting view, a data model that assumes a simpler ownership structure than the group actually has, or a reconciliation approach that was designed after the build rather than before it.
These are the points at which a specialist perspective changes the outcome — early enough to be cheap, and late enough to be concrete. We are typically brought in when an organisation is deciding whether to adopt Group Reporting, designing it for the first time, migrating to it from BPC or a legacy consolidation platform, or trying to stabilise and improve an implementation that is already live.
Capabilities
Support across the full lifecycle.
Strategy & architecture
Roadmap, target operating model, consolidation architecture, deployment approach and integration landscape.
Solution design
Consolidation structures, FS items, methods, currency translation, eliminations, ownership and NCI, investment consolidation, cash flow, tax and segment reporting.
Data & ACDOCU architecture
Data sourcing and mapping, data preparation, the design implications of the consolidation journal, validation and reporting lineage.
Implementation support
Configuration, functional specifications, integration, test design, reconciliation and cutover support.
Migration
BPC and legacy consolidation migration, data mapping, historical data strategy, parallel run and reconciliation.
Connected Group Reporting
ICMR, Group Reporting Data Collection, SAP Analytics Cloud, Datasphere/BW, disclosure tooling and the surrounding reporting and data architecture.
Optimisation & assurance
Design reviews, performance, close-process improvement, controls, reporting and operating model refinement.
How we approach the work
Accounting first, then architecture, then configuration.
Establish the accounting answer
Group accounting policy, reporting requirements and the consolidation methods that follow from them — documented before configuration begins.
Design the solution
Consolidation structures, master data, methods, currency, elimination and reporting design, with the integration and data model made explicit.
Build, test and reconcile
Functional specification, configuration support, test design covering consolidation and reporting, and structured reconciliation against the legacy result.
Cut over and stabilise
Parallel run, opening balance strategy, historical data approach, cutover sequencing, defect triage and finance readiness.
Depth of scope
The consolidation topics that decide whether a design holds up.
A Group Reporting design is tested by the edge cases, not the base case. These are the areas we expect to work through with you.
- Ownership changes, step acquisitions and disposals part-way through a reporting period
- Non-controlling interests, including indirect and multi-level ownership structures
- Joint ventures and equity-method investments, and the point at which method changes
- Investment consolidation and the elimination of investment against equity
- Consolidated cash flow, and reconciling it back to a movement-based consolidation
- Other comprehensive income, retained earnings and equity roll-forward integrity
- Intercompany matching, elimination and the reconciliation differences that follow
- Currency translation, including CTA, average versus closing rates and historical rates
- Tax reporting and the segment reporting view of a consolidated result
The consolidation journal
Where the consolidated result actually lives.
Group Reporting stores consolidation data in ACDOCU, the universal consolidation journal — separate from ACDOCA, which holds the source accounting data in the universal journal. Reported values, manual and group journal entries, and the postings generated by consolidation tasks all land in ACDOCU. It is the reporting layer's single source for the group result.
That separation is the reason Group Reporting can consolidate without disturbing the underlying accounting, and it is also where several design decisions quietly get made. How data is released from the source ledger, what is prepared before it arrives, which postings are automatic and which are manual, and how much of the story can be traced back afterwards — all of those are ACDOCU architecture decisions, whether or not anyone described them that way at the time.
We work through them explicitly: the flow into the journal, the preparation and validation that precedes it, the consolidation tasks that write to it, and how reporting consumes it. Not as a field-level catalogue — at the level a finance solution architect has to make choices.
- Data flow into the consolidation journal, and what is prepared or mapped before it arrives
- Reported data, manual entries and group journal entries — what is posted where, and by whom
- Validation placement, and what a failed validation should block
- Reporting lineage: whether a figure can be traced from the group result back to its source
- The implications for restatement, comparatives and reruns after reporting has started
Connected architecture
Group Reporting rarely sits on its own.
Data collection
Group Reporting Data Collection for non-S/4 entities, and the validation, ownership and submission workflow around it.
Analytics & disclosure
How consolidated results are exposed to SAP Analytics Cloud, management reporting and disclosure tooling without duplicating finance logic in each layer.
What you get
Deliverables, not just attendance.
- Target consolidation architecture and design decision record
- Accounting and method design documentation traceable to group policy
- Functional specifications for configuration and integration
- Test strategy and test cases covering consolidation and reporting
- Reconciliation framework and parallel run comparison approach
- Migration and historical data strategy where legacy platforms are in scope
- Issue and risk log with recommended resolutions for design authority sign-off
Related
What usually sits either side of this.
- Consolidation Design & Architecture — the accounting and model design, agreed before configuration begins
- Group Reporting Health Check — a time-boxed independent review of a solution that is already live
- Last Mile Reporting — where the need extends beyond producing the consolidated number to filing it
- Finance Data & Reporting Architecture — how the consolidated result reaches everything downstream
- About Radixa — how we work, and the experience behind the advice
Next step
Discuss your Group Reporting programme.
Whether you are at design, mid-build, migrating from BPC or trying to stabilise a live implementation, start with a conversation about where the design is under strain.