Why Shared Service Centres Drive Most Power BI Demand (And How To Survive It)

The Scenario: A Shared Service Centre Drowning in Excel

Picture a finance shared service centre supporting:

• 7 countries
• 3 ERPs
• A mix of local Excel trackers, Access databases, and CSV exports

The centre is asked to build a global monthly performance dashboard in Power BI for:

• AP processing times
• AR ageing
• GL close status

Before Power BI, the process looked like this:

1. Local teams send Excel files every month.
2. A central analyst copies everything into a “master” workbook.
3. Pivot tables and charts are refreshed manually.
4. The resulting PDF deck is emailed to managers.

Pain points:

• Late files break the schedule.
• Different column names and formats for each country.
• No single version of truth; everyone keeps their own copy.

Now the centre wants Power BI to fix it. That’s where the real demand comes from.

Why Shared Service Centres Generate So Much Power BI Work

Shared service centres are designed to centralise processes. That centralisation naturally creates Power BI demand because they:

1. Own Cross-Country, Cross-System Data

They sit on top of:

• Multiple ERPs (e.g., one per region)
• Local tools (Excel trackers, legacy databases)
• Corporate data warehouse feeds

Every time management asks for a single global view, the shared service centre becomes the data integration hub — and Power BI is the interface.

2. Need Standardised KPIs Across Regions

Local teams measure things differently:

• Country A: AP SLA measured in calendar days
• Country B: AP SLA measured in business days
• Country C: AP SLA includes weekends

The shared service centre is asked to:

• Define common KPI logic
• Implement it centrally
• Roll it out in one report everyone uses

Power BI becomes the place where messy reality is translated into clean, standardised measures.

3. Are Under Pressure to Show Efficiency

Shared service centres constantly need to prove:

• Cost per invoice processed
• Tickets closed per FTE
• Time saved via automation

These are exactly the kind of metrics that:

• Need data from multiple systems
• Need refreshable, visual reporting
• Are easier to maintain in Power BI than in a 20-tab Excel file

4. Have Central BI Capacity (Even If It’s Just You)

Often there is:

• One small BI/analytics team
• Or one “Power BI person” in finance or operations

So every cross-functional reporting idea lands there. Shared service centres become Power BI demand funnels, even if they didn’t plan to.

Designing the Data Model for a Shared Service Centre Reality

Back to our scenario: global AP/AR/GL dashboard.

You’re given:

• Monthly AP transaction dumps from each ERP
• AR ageing extracts
• A GL close status file from the consolidation system

The first trap is trying to wire everything directly into visuals. In a shared service centre environment, the data model is the main defence against chaos.

Key Principles for the Model

1. Separate fact tables per process

   • FactAPTransactions
   • FactARBalances
   • FactGLCloseStatus

2. Shared dimensions

   • DimDate
   • DimEntity (company/country/region)
   • DimVendor / DimCustomer (if feasible)

3. Explicit mapping layers

   • DimSourceSystem
   • DimProcessOwner

This lets you:

• Keep process-specific logic isolated
• Still report consistently across entities and time

Example: Standardising AP Cycle Time

You receive AP data with different column names:

• ERP1: InvoiceDate, PaymentDate
• ERP2: Inv_Date, Paid_On
• ERP3: DOC_DATE, PAYMENT_DT

In Power Query, you create a normalised AP table:

let
    SourceERP1 = Excel.Workbook(File.Contents("ERP1_AP.xlsx"), true),
    ERP1_AP = SourceERP1{[Name="AP"]}[Content],
    ERP1_Renamed = Table.RenameColumns(ERP1_AP,
        {{"InvoiceDate", "InvoiceDate"}, {"PaymentDate", "PaymentDate"}}),

    SourceERP2 = Excel.Workbook(File.Contents("ERP2_AP.xlsx"), true),
    ERP2_AP = SourceERP2{[Name="AP"]}[Content],
    ERP2_Renamed = Table.RenameColumns(ERP2_AP,
        {{"Inv_Date", "InvoiceDate"}, {"Paid_On", "PaymentDate"}}),

    SourceERP3 = Excel.Workbook(File.Contents("ERP3_AP.xlsx"), true),
    ERP3_AP = SourceERP3{[Name="AP"]}[Content],
    ERP3_Renamed = Table.RenameColumns(ERP3_AP,
        {{"DOC_DATE", "InvoiceDate"}, {"PAYMENT_DT", "PaymentDate"}}),

    Combined = Table.Combine({ERP1_Renamed, ERP2_Renamed, ERP3_Renamed}),
    AddedCycleDays = Table.AddColumn(Combined, "CycleDays", each
        Duration.Days([PaymentDate] - [InvoiceDate]), Int64.Type)
in
    AddedCycleDays

Now your DAX measure can be standard across all entities:

Average AP Cycle Days = 
AVERAGEX(
    FactAPTransactions,
    FactAPTransactions[CycleDays]
)

This is typical shared service centre work: normalise first, measure later.

Handling Shared Service Centre Stakeholders Without Losing Your Mind

The technical work is only half the story. The demand pattern from shared service centres creates a specific stakeholder environment:

• Central leadership wants global views.
• Local teams want their nuances respected.
• IT wants governance and performance.

Stakeholder Mapping for Our Scenario

For the global AP/AR/GL dashboard, you’ll deal with:

• Global process owner – defines KPIs and owns the narrative.
• Local country leads – care about exceptions, edge cases, and data quality.
• BI/IT team – cares about refresh, gateways, and security.

If you treat all of them as generic “users”, the report will never stabilise.

Practical Steps

1. Lock KPI definitions early

   • Run a short workshop with the process owner.

   • Document each KPI in a simple table:

     KPI	Definition	Owner
     AP Cycle Days	PaymentDate - InvoiceDate, calendar days	Global AP Lead
     Overdue AR %	Past due balance / total balance	Global AR Lead
     GL Close On-Time %	Entities closed by deadline / total entities	GL Manager

2. Separate global vs local views

   • Global summary page for leadership.
   • Local drill-down pages with more filters and details.

3. Agree on refresh and cut-off rules

   • Example: data is considered final 3 days after month-end.
   • Communicate this inside the report (e.g., a text box or card).

4. Use row-level security (RLS) deliberately

   • Global users see all entities.
   • Local users see only their country.

Example RLS pattern using a bridge table:

-- DimUserEntity contains mapping between UserPrincipalName and EntityKey

UserEntityFilter = 
VAR CurrentUser = USERPRINCIPALNAME()
RETURN
    FILTER(
        DimEntity,
        DimEntity[EntityKey] IN
            CALCULATETABLE(
                VALUES(DimUserEntity[EntityKey]),
                DimUserEntity[UserPrincipalName] = CurrentUser
            )
    )

This kind of setup is standard in shared service centres where access needs to match organisational boundaries.

Governance: When Power BI Becomes the Shared Service Centre’s Operating System

Once the first global dashboard works, something predictable happens:

• HR asks for headcount and attrition dashboards.
• Procurement wants vendor performance dashboards.
• Operations wants SLA dashboards for ticket handling.

Your shared service centre slowly turns Power BI into a platform, not just a reporting tool.

To avoid chaos, you need lightweight governance.

Minimal Governance That Actually Helps

1. Report catalogue

   • Keep a simple list:

     • Report name
     • Owner
     • Purpose
     • Data sources
     • Refresh schedule

2. Naming conventions

   • For workspaces:
     • SSC_Finance_Prod
     • SSC_Finance_Dev
   • For datasets:
     • DS_Finance_AP_Global
     • DS_Finance_AR_Global

3. Template pages

   • Standard layout for:
     • Filters
     • KPI cards
     • Trend charts
     • Commentary

4. Shared measures

   • Create a measures table:

-- In a dedicated Measures table

[AP Invoices Count] = COUNTROWS(FactAPTransactions)

[AP Cycle Days Avg] = 
AVERAGEX(
    FactAPTransactions,
    FactAPTransactions[CycleDays]
)

[AR Overdue %] = 
DIVIDE(
    [AR Overdue Balance],
    [AR Total Balance]
)

Re-using measures across reports keeps KPI logic consistent and reduces maintenance.

Performance and Refresh: The Unseen Shared Service Centre Problem

Shared service centres often run into performance issues because:

• Data volumes grow quickly as more countries join.
• Refresh windows are tight (e.g., nightly or even hourly).
• Gateways and network paths are shared with other systems.

In our scenario, the global AP/AR/GL dataset grows from a few hundred thousand rows to many millions as:

• More historical data is included
• More entities are onboarded

Practical Performance Tips for This Kind of Setup

1. Incremental refresh for fact tables

   • Especially AP and AR, which are date-based.

2. Pre-aggregation where useful

   • Use Power Query or the source system to summarise old data.

3. Avoid unnecessary columns

   • Drop columns that are:
     • Not used in visuals
     • Not needed for filtering or relationships

4. Push heavy calculations to the source when possible

   • Example: calculate ageing buckets in SQL instead of DAX.

Sample ageing bucket in SQL for AR:

SELECT
    CustomerID,
    InvoiceID,
    InvoiceDate,
    DueDate,
    Balance,
    CASE
        WHEN DATEDIFF(DAY, DueDate, GETDATE()) <= 0 THEN 'Current'
        WHEN DATEDIFF(DAY, DueDate, GETDATE()) BETWEEN 1 AND 30 THEN '1-30'
        WHEN DATEDIFF(DAY, DueDate, GETDATE()) BETWEEN 31 AND 60 THEN '31-60'
        WHEN DATEDIFF(DAY, DueDate, GETDATE()) BETWEEN 61 AND 90 THEN '61-90'
        ELSE '90+'
    END AS AgeBucket
FROM AR_Transactions;

Bringing pre-bucketed data into Power BI makes visuals faster and measures simpler.

Before and After: What Changes When Power BI Is Embedded in the Shared Service Centre

Back to our global AP/AR/GL scenario, the difference looks like this.

Before Power BI

• 10+ Excel files per month.
• Manual consolidation and pivot refresh.
• Late, error-prone PDF decks.
• No easy drill-down by entity or vendor.

After Power BI (When Done Properly)

• Central dataset with:
  • Normalised AP/AR/GL fact tables
  • Shared DimDate, DimEntity, DimVendor/Customer
• Scheduled refresh aligning to month-end cut-offs.
• One global dashboard with:
  • Summary KPIs
  • Regional breakdowns
  • Drill-through to transaction-level detail
• RLS ensuring:
  • Global leadership sees everything
  • Local teams see only their own data

The shared service centre still does a lot of work, but:

• The process is repeatable.
• The KPIs are consistent.
• The noise level from stakeholders drops over time.

One Concrete Takeaway: Treat the Shared Service Centre as a Product Owner

If you’re working in or with a shared service centre, assume they will drive most Power BI demand, whether formally or informally.

The practical move: stop treating each report as a one-off request and instead:

• Identify the core global processes (AP, AR, GL, HR, Procurement).
• Build stable, reusable datasets around those.
• Let individual reports be thin layers on top.

Do that once, and the next “Can you build us a dashboard?” email becomes a matter of adding a page, not rebuilding the world every month.