If your group runs several legal entities on SAP, you know the month-end ritual: each entity exports its balances, someone builds a master Excel, balances get pasted in, currencies are converted by hand using whatever exchange rate someone remembers, intercompany transactions are cross-checked by eye… and only then does a consolidated number appear. By the time it's ready, it's already stale.
The problem isn't SAP. SAP does exactly what it was designed to do: record each entity's accounting with rigor. The problem is that SAP wasn't built to automatically consolidate multiple legal entities — with different charts of accounts and currencies — into a single group view. And forcing it into that role ends in endless spreadsheets, two-week closes, and decisions made on month-old data.
The solution is to extract your data from SAP and move it somewhere purpose-built to consolidate and analyze. In this guide, we'll show you exactly how we do it.
What "unifying legal entities" really means
In SAP, each legal entity is a company code (the BUKRS field). And that's where the differences that make manual consolidation so painful begin:
- Each entity may have its own local chart of accounts. The "Sales revenue" account might be
410000in one entity and700001in another. If you don't map them to a common structure, there's no way to add up group revenue. - Each entity may operate in its own currency. To get a group number, you have to convert everything into a single currency, using a consistent exchange rate across all of them.
- There are transactions between group companies (intercompany). If entity A invoices entity B, that revenue isn't group revenue: it has to be identified and eliminated, or the consolidation is overstated.
Unifying legal entities means solving these three things automatically and repeatably: one group chart of accounts, one currency, and intercompany flagged — so the consolidation runs on its own, every month, without Excel.
The complete architecture: from SAP to dashboard
Before diving into the steps, here's the full picture of what we build:
SAP FI/CO → Extraction (SLT / OData / CDS) → Google Cloud Storage (raw) → BigQuery (data warehouse) → dbt (mapping + conversion + consolidation) → Power BI (dashboards)
It sounds like a lot, but each piece has a clear role and, once it's set up, it runs on its own. Let's go piece by piece.
Step 1: Understand what data SAP holds
All the financial information for your entities lives in tables you can query directly. The ones relevant for consolidation are:
Transactional (the numbers):
ACDOCA— the Universal Journal in S/4HANA. A single table with FI and CO. Key fields:RBUKRS(company code),RACCT(account),RYEAR/POPER(fiscal year/period),HSL(amount in local currency),RASSC(partner company for intercompany).BKPF+BSEG— accounting document header and line items (in ECC, or for detail).FAGLFLEXA— New GL line items (New GL in ECC).
Master data (the context and the unification keys):
T001— the legal entities: company code, name, chart of accounts (KTOPL), and local currency (WAERS).SKA1/SKAT— G/L account master and its texts.T004— the charts of accounts.T011— the Financial Statement Versions (the P&L and balance sheet reporting hierarchy).TCURR— exchange rates.
All extraction is read-only. You never modify tables in the SAP production system. Working against SAP must always be SELECT / read access via CDS or OData — modifying data breaks the integrity of the accounting system.
Step 2: Extract the data from SAP
Extraction can be done several ways, depending on your SAP landscape:
- CDS / OData views — the native path in S/4HANA. Data is exposed as services and read incrementally.
- SAP SLT or SAP Datasphere — managed replication, useful if you already license these tools.
- Google Cloud Cortex Framework — Google's accelerator for moving SAP data into BigQuery with predefined models.
- Custom agent — a lightweight Python extractor that runs incrementally and uploads to the cloud, when you want full control and low cost.
In every case, extraction is incremental (only what's new or changed since the last run) and scheduled — typically in the early morning.
Extraction doesn't touch the SAP application or consume dialog user licenses. It connects to the data layer (CDS/OData or replication) with a read-only technical user. It doesn't interfere with daily operations.
Step 3: Store the raw data in the cloud (Data Lake)
Data lands first in Google Cloud Storage, organized by date and by entity. It's your "smart backup": even though SAP keeps operating normally, you have a historical, versioned, queryable copy of your accounting data. If you ever need to see what one entity's balance sheet looked like six months ago, it's there.
Storage cost for a typical group is pennies per month.
Step 4: Load into BigQuery (Data Warehouse)
From Cloud Storage, data loads into BigQuery exactly as it came out of SAP: same field names, same codes, same currencies. It's not easy to analyze yet, but it's now in a place where we can work with it — without touching SAP and without slowing down operations.
BigQuery
└── group_raw
├── raw_acdoca (journal: company code, account, period, amount)
├── raw_t001 (legal entities)
├── raw_ska1_skat (chart of accounts + texts)
├── raw_t011 (financial statement versions)
└── raw_tcurr (exchange rates)
Step 5: Unify in dbt (the key step)
This is where raw data becomes a real consolidation. dbt transforms with pure SQL, with tests and documentation. The three transformations that solve the unification of legal entities are:
- Account mapping → each local account is translated to a group chart of accounts line (the Financial Statement Version from
T011). That way410000in one entity and700001in another add up on the same "Revenue" line. - Currency conversion → local amounts (
HSL) are converted to the group currency using the exchange rate fromTCURR, applying a single rate type across all entities. - Intercompany → transactions between group companies are identified by trading partner (
RASSC) so they can be flagged or eliminated.
In SQL, the core logic looks like this (simplified):
-- Consolidate ACDOCA across all company codes into group currency
select
acd.rbukrs as company_code,
t001.butxt as entity_name,
map.group_line as fs_line, -- local account → group FSV
acd.ryear,
acd.poper as period,
sum(acd.hsl) as amount_local,
sum(acd.hsl * fx.ukurs) as amount_group -- conversion with TCURR
from acdoca acd
join t001 t001 on t001.bukrs = acd.rbukrs
join account_mapping map on map.ktopl = t001.ktopl
and map.account = acd.racct
join tcurr fx on fx.fcurr = t001.waers
and fx.tcurr = 'USD' -- group currency
and fx.kurst = 'M' -- exchange rate type
group by 1, 2, 3, 4, 5The result is clean, auditable tables ready to report: a group P&L and balance sheet model, with the entity and the source document always traceable.
The advantage of doing this in dbt is that the account mapping and conversion rules are versioned, documented, and tested. If a P&L line doesn't reconcile against the SAP close, there's a test that catches it. It's the difference between a fragile spreadsheet and a system finance can audit.
In S/4HANA, ACDOCA already stores a group-currency amount (KSL). Even so, consolidation usually needs a single, uniform exchange rate across all entities and a mapping to the group FSV — which is why the dbt model is still necessary.
Step 6: Visualize in Power BI (Dashboards)
With consolidated data in BigQuery, dashboards are the fastest part. A single Power BI model connected to BigQuery, with drill-down from group → entity → document. The dashboards we build as a baseline:
- Consolidated P&L: revenue, gross margin, EBITDA, and net income — group and by entity, actual vs budget.
- Balance Sheet: assets, liabilities, and equity by entity and consolidated; working capital and net debt.
- AR / AP & Cash: receivables and payables aging, DSO/DPO, cash position by entity and currency.
- Intercompany & FX: balances between group companies, currency exposure, and translation adjustment.
- Executive: consolidated in group currency, contribution mix by entity, margin by entity, year-over-year growth.
Each dashboard updates automatically with every extraction. Finance opens a link and sees the group consolidation — without asking anyone to "build the Excel."
What this costs
Monthly infrastructure costs for a typical group:
- Google Cloud Storage: less than USD 1/month
- BigQuery: between USD 10 and USD 40/month depending on volume and queries
- Power BI: Pro license, around USD 10-14 per user/month
- SAP extraction: depends on the method — with native CDS/OData the cost is low; with SLT or Datasphere it may lean on SAP licenses you already own
Total infrastructure: on the order of USD 30-80 per month for a mid-size group. Development and implementation is separate and one-time; once built, the pipeline runs on its own.
How long does implementation take
For a group with several legal entities on SAP:
- Week 1: Map entities (
T001), charts of accounts, and define the target group FSV - Week 2: SAP extraction (
ACDOCA+ master data) → GCS → BigQuery - Week 3: Local-to-group account mapping and currency conversion (
TCURR) in dbt - Week 4: Intercompany rules and validation — reconcile the consolidation against the real SAP close
- Weeks 5-6: Power BI dashboards and adjustments with the finance team
The part that takes the most care isn't the technical work, it's the reconciliation: making the number the pipeline produces match the accounting close to the cent. Once that validates, finance trusts the dashboard.
What if I run ECC instead of S/4HANA?
The architecture is the same. What changes is the source tables: instead of ACDOCA, you extract from BKPF + BSEG and FAGLFLEXA (New GL) or GLT0 (classic GL). The rest of the pipeline — GCS, BigQuery, the dbt mapping, the dashboards — is identical.
And if your group has a mixed landscape (some entities on SAP, others on a different ERP, or one still on Excel), it still works: each source comes in through its own extractor and they all converge into the same group model. Unifying legal entities doesn't depend on everyone being on the same system.
Conclusion
Having your group consolidation trapped in a two-week manual close is like driving while looking in the rearview mirror: you see where you were, not where you are.
Unifying the financial reporting of your legal entities from SAP isn't an innovation project. It's basic infrastructure every group with multiple entities should have: a consolidation that runs on its own, in one currency, with accounts aligned and intercompany resolved — every month, without Excel.
The cost is low, implementation takes weeks, and the impact shows from the first close finance runs in hours instead of days.
At Richmond Analytics, we design and build this architecture for groups with multiple legal entities. If you want to see your group's consolidation in dashboards that update automatically, let's talk.
