When Power BI and SharePoint Disagree: Making Your Intranet Numbers Defensible

By Nicolas Saliba · Published October 2025, Updated August 2026 · 8 min read

You are twenty minutes into the quarterly business review. The slide says the transformation announcement reached 4,100 people across the intranet. Someone from finance has the SharePoint site usage export open on their laptop, because they asked for it last week, and it says 3,600 for what looks like the same period. They ask, reasonably, which number is right.

Whatever you say next determines how the rest of the year goes. If you cannot explain the gap in one sentence, the credibility damage lands on the whole reporting pack, not just that slide. This article is about that moment: why the two disagree, how to decide which one is the number of record, and what reconciliation looks like when it is done properly.

Neither number is lying, and that is the problem

The instinct is to look for a bug. Usually there is not one. The two figures disagree because they are answers to slightly different questions, produced by different systems, on different clocks.

Start with what each one actually is. SharePoint site usage reports are generated inside the service and surfaced in the site itself, aggregated over fixed windows of 7, 30, 90 days and the last 12 months^[1]. A Power BI report built by your IT team is almost always reading the Microsoft Graph reporting endpoints, which expose tenant-level activity data on their own schedule and with their own aggregation rules^[2]. Two pipelines, two definitions of a day, two definitions of a unique person.

Four differences account for most of the gap you will ever see.

The clock. Graph reporting data is expressed in UTC. Your Power BI model may be rolling it up in local time, and your SharePoint window may be anchored somewhere else again. A campaign that ran on a Monday in Singapore and a Monday in Chicago is not the same Monday.
The unit. A view is not a visit is not a unique viewer. If the Power BI measure counts distinct users and the native panel counts page views, the two will never agree and should not.
The scope. A Power BI model that pulls every site in the tenant is counting team sites and personal OneDrive activity alongside the intranet. That is a large and mostly invisible inflation, and it is the single most common cause of a Power BI figure being higher than the native one. We cover the mechanics of that boundary in detail in the piece on OneDrive and SharePoint.
The latency. Activity data appears in the reporting endpoints with a lag. Pull the same period a week later and you may legitimately get a larger number.

The three things you must say out loud about Power BI

Beyond definitional drift, three properties of this stack need stating plainly, ideally before an executive discovers them.

First, the Microsoft Graph reporting API is not consistently reliable. It produces days with missing data. Not corrupted, simply absent, and a chart that silently draws a line between the two surrounding points will show a smooth trend that never happened.

Second, customers have observed KPI values in Power BI that do not reconcile with the native SharePoint reports for the same period. This is not a rare edge case. It is the normal condition of an unreconciled build, and it is exactly the situation described at the top of this article.

Third, a dependable build needs a robust ingestion process and scheduled reconciliation against the native figures. The dashboard is the cheap part. The pipeline that fills gaps, detects missing days, retries failed pulls and compares itself to a known reference every month is the expensive part, and it is the part that gets cut when the project is scoped. Budget for the pipeline rather than the dashboard. If you are at the stage of deciding whether to build at all, the honest guide to building SharePoint analytics with Power BI works through the total cost properly.

Pick a number of record, and write it down

Here is the position this article argues for: the failure in that quarterly review was not analytical, it was governance. Nobody had decided, in advance and in writing, which system is authoritative for which claim. Once two systems can both answer a question and neither has been declared the answer, every meeting is a negotiation.

A number of record is a short written statement covering four things: the metric, the system that produces it, the exact definition, and the person who owns it. It takes an afternoon to write and it ends the argument permanently.

In practice the sensible split is usually this. Native SharePoint reporting is the reference for anything scoped to a single site over a standard window, because it is the system of origin and you cannot out-argue it. Power BI is the reference for anything that requires combining sites, joining to organisational attributes, or covering a period longer than the native retention window. Where the two overlap, the native figure wins and the Power BI model is corrected to match it.

Claim you want to make	Number of record	Why
The news page got 3,600 views last month	SharePoint site usage	System of origin, single site, standard window. Anyone can check it.
The campaign reached 41 per cent of the commercial function	Power BI or a dedicated layer	Requires a join to organisational attributes that native does not hold.
Intranet reach is up 12 points over three years	Power BI or a dedicated layer	Exceeds the native retention window, so the history must live elsewhere.
The safety notice landed on the plant floor	Whatever holds site and role attributes	Native reports on the page, not on the population it was written for.
Total activity across intranet, Viva Engage and newsletter	Cross-channel layer	No single native panel spans the channels, and the units differ across them.

The reconciliation ritual

Once the number of record exists, reconciliation stops being a crisis and becomes a monthly chore. It should take under an hour and it should be somebody’s named job.

Pick three or four reference sites, ideally including your busiest news site and one quiet regional site. Every month, pull the native usage figure for the standard 30-day window and compare it to what the Power BI model reports for the same site, same window, same measure. Record both numbers and the variance in a table that never gets deleted. Set a tolerance in advance, five per cent is a common starting point, and treat anything outside it as an incident rather than a curiosity.

Two things make this work. The log is kept even when the variance is zero, so you can show a year of stability rather than asserting it. And the missing-day check runs separately: count how many days in the period returned no data at all, because a model can reconcile perfectly on totals while quietly having lost a Tuesday.

When you present, show the variance. An IC director who says “these two systems agree within three per cent, and here is the log” has effectively ended the line of questioning. One who says “I will check” has invited it back every quarter. Our note on executive reporting for internal communications covers how much of this belongs on the slide and how much belongs in the appendix.

When Power BI is genuinely the right home

None of the above is an argument against building. Power BI is a capable modelling and visualisation tool, it is already licensed in most Microsoft 365 organisations, and it is the natural place to combine sources^[3]. If you have a data engineer who owns the pipeline, a reconciliation process running, and a reporting need specific enough that no product covers it, building is the right call and the result is yours forever.

It is the wrong call in two situations. When nobody owns the pipeline, the build degrades quietly and you find out in a meeting. And when the real requirement is cross-channel segmented reporting, because at that point you are building a data platform rather than a report. For the architecture questions, the guide on how to analyse SharePoint with Power BI sets out what a build that survives review requires, and the walkthrough on creating internal communication reporting with Power BI covers the report design itself.

Where a dedicated measurement layer changes the question

Tryane sits above Microsoft 365 rather than beside it. It reads SharePoint, Viva Engage, Teams and newsletter platforms together, joins that activity to your organisational structure through Entra ID or an HR file, and keeps history across product transitions. The reconciliation work still happens, but against a stable definition inside the product rather than in a spreadsheet you maintain.

The practical facts: SOC 2 Type 2 certified, GDPR compliant by design, EU hosting by default with US data residency on request, single sign-on through Azure AD or Entra ID, no agent to install, and a deployment measured in a couple of hours. Tryane publishes to Power BI through its API, so a team that has standardised on Power BI as the presentation layer keeps it and replaces only the fragile ingestion underneath. If you are rebuilding the measurement set at the same time, the guide to internal communication KPIs is the companion piece, and the article on the limits of native SharePoint analytics explains where the native figures stop being enough.

Frequently asked questions

Why does my Power BI report show more views than SharePoint?

Most often because the model is pulling a wider scope than the intranet. A tenant-wide query includes team sites and personal OneDrive activity, which inflates the total against a native report scoped to one communication site. Check the scope first, then the measure definition, then the time zone. Those three account for the large majority of gaps.

Which number should I put on the executive slide?

The one you have declared as the number of record for that claim, and you should be able to name it before the meeting. For a single site over a standard window, use the native figure. For anything segmented by function, country or role, or anything spanning more than the native retention period, use the modelled figure and say so in a footnote.

How often should we reconcile?

Monthly, on a fixed set of reference sites, with the variance recorded whether or not it is interesting. Reconciliation that happens only when someone complains is not reconciliation, it is firefighting, and it never produces the evidence you need in the room.

Is the Microsoft Graph reporting API reliable enough to build on?

It is reliable enough to build on with care, and not reliable enough to build on casually. It produces days with missing data, and customers have observed KPI values in Power BI that do not reconcile with native SharePoint reports for the same period. A dependable build needs a robust ingestion process, gap detection, retry logic and scheduled reconciliation. Budget for that pipeline rather than for the dashboard.

Does Tryane replace our Power BI reporting?

Not necessarily. Many customers keep Power BI as the presentation layer and use Tryane as the source, through the API, so the visuals stay where the organisation already reads them. What changes is underneath: a maintained ingestion layer with organisational attributes joined in, instead of a bespoke pipeline one person understands.

Sources

• Microsoft Learn, SharePoint site usage and portal health

• Microsoft Learn, Microsoft Graph reports overview

• Microsoft Learn, Power BI overview