Most dealer groups did not set out to end up with five different ways of calculating gross profit per vehicle. It happens gradually, one rooftop at a time, as locations are acquired or opened, each arriving with its own dealer management system, its own reporting habits, and its own version of what "in stock" actually means. By the time a group reaches even three or four rooftops, pulling a single trustworthy view of sales and inventory across the network has usually become a monthly exercise involving several spreadsheets and a fair amount of manual reconciliation.
At Versich, we build Power BI reporting for dealer groups facing exactly this problem. This guide covers why multi-rooftop reporting breaks down in the first place, how Power BI consolidates sales and inventory data across locations and dealer management systems, the architecture that makes this reliable rather than fragile, and the dashboards that tend to matter most once the data is unified.
If your group is also weighing how this consolidated layer should be structured technically, our overview of Power BI architecture covers the underlying connectivity and refresh design decisions that apply directly to a multi-location reporting build.
Why Reporting Breaks Down Across Multiple Rooftops
A single-location dealership can usually get by on whatever reports its dealer management system provides natively. The moment a second rooftop is added, and especially once a group crosses into double digits of locations, the native reporting in any one DMS stops being enough, for reasons that compound rather than simply add up.
The most common failure points we see in dealer groups before consolidation include:
- Different rooftops running different DMS platforms, commonly a mix such as CDK Global at one location and Dealertrack at another, each with its own data structure and terminology
- Core metrics calculated inconsistently between systems, where something as fundamental as gross profit per vehicle can mean different things depending on which DMS produced the number
- Inventory visibility that stops at the rooftop level, making it difficult to know where a specific unit sits across the whole network when a customer asks about it
- Monthly performance reports assembled manually in spreadsheets, often taking a controller or general manager several days each cycle
- Executives unable to compare rooftop performance on a like-for-like basis because each location's reporting reflects local habits rather than a shared standard
None of this is a failure of any individual DMS. Each one does its job well at the rooftop level. The problem is structural: there is no layer above the individual systems built specifically to consolidate and standardise what they produce.
What Power BI Adds That a Single DMS Cannot
Power BI does not replace any dealer management system. It sits above them, pulling data from each rooftop's DMS, along with any other systems in use such as a CRM or a separate parts and service platform, into one consolidated reporting layer.
This matters because the value is not just visual polish on top of existing reports. It is the ability to define gross profit per vehicle once, in one place, and apply that definition consistently across every rooftop regardless of which DMS produced the underlying transaction. The same applies to inventory aging, sales velocity, and any other metric that needs to mean the same thing everywhere it appears.
| Capability | Individual DMS Reporting | Consolidated Power BI Layer |
|---|---|---|
| Cross-rooftop comparison | Limited or not available natively | Built in, with consistent metric definitions across all locations |
| Multi-DMS environments | Each system reports only on its own data | Unifies data from CDK, Dealertrack, or any mix of platforms into one model |
| Inventory visibility | Stops at the rooftop where the vehicle is logged | Network-wide visibility, including in-transit and inter-rooftop transfers |
| Custom KPIs and drill-down | Fixed report templates with limited flexibility | Fully customisable, with drill-through from group level to rooftop to individual deal |
| Distribution to stakeholders | Manual export or login required per system | Scheduled refresh and automated distribution to the right people automatically |
Connecting Multiple Dealer Management Systems to Power BI
The technical starting point for any multi-rooftop build is establishing a reliable connection from each DMS into a shared data layer. The right approach depends heavily on which systems are involved and how each one exposes its data.
Native or partner connectors: Some dealer management systems offer direct database access, an API, or an established partner integration that Power BI can connect to relatively directly. Where this exists, it is usually the fastest path to a working connection.
Extract and stage in a central database: Where a DMS has no clean direct connection, or where multiple different systems need to be unified into one consistent schema, the more reliable pattern is to extract data from each system on a schedule into a central database, typically Azure SQL, that you own. Power BI then connects to that single database rather than juggling several different live connections with different refresh behaviours and reliability characteristics.
Standardising the schema during extraction: This is the step that actually solves the inconsistent-metric problem. As data lands in the central database, field names, units, and calculation logic are mapped to a single shared standard, so that gross profit per vehicle, inventory age, and every other core metric mean exactly the same thing whether the underlying transaction came from one DMS or another.
For groups running a genuine mix of DMS platforms across rooftops, this staging layer is almost always the right architecture, since it isolates the messy work of reconciling different source systems into one place rather than repeating that logic inside every report.
Consolidated Sales Reporting Across the Network
Once sales data from every rooftop lands in a unified model, the reporting that becomes possible goes well beyond what any single DMS offers on its own.
- Group-level sales dashboard showing units sold, gross profit, and average days to sale, filterable by rooftop, brand, or region, with the group total always visible alongside individual location performance
- Sales rep leaderboard that works across rooftops, useful for groups that move staff between locations or want to benchmark performance on a consistent basis network-wide
- New versus used vehicle performance broken out separately, since the economics and inventory dynamics of each differ substantially and rarely belong on the same chart without clear separation
- Finance and insurance product attachment rates compared across rooftops, often one of the most variable metrics between locations and a common target for standardisation efforts
- Month-over-month and year-over-year trend views that let group leadership spot a softening rooftop early, well before it shows up as a problem in the monthly close
Network-Wide Inventory Visibility
Inventory is where the cost of fragmented reporting shows up most directly. A vehicle sitting unsold for an extra two weeks at one rooftop while a customer at another location is asking for exactly that model is a cost most groups pay regularly without ever seeing it clearly quantified.
A consolidated inventory dashboard typically covers:
- Real-time stock levels by rooftop, model, and trim, viewable as a single network-wide list rather than requiring a separate login per location
- Inventory aging bands, flagging units approaching the point where holding cost starts eroding margin, with the threshold set consistently across all rooftops rather than left to local judgement
- Reconditioning status pulled in alongside inventory age, so a vehicle held up in the service bay is distinguished from one simply not selling
- Transfer opportunity flags, surfacing cases where a slow-moving unit at one rooftop matches active demand or a customer request at another
- Days supply by segment, helping purchasing decisions reflect actual demand patterns across the group rather than each rooftop ordering independently based on local guesswork
This is also where the standardised metric definitions from the data layer matter most. Average dealership throughput and inventory turn benchmarks are only meaningful when every rooftop's numbers are calculated the same way before they are compared.
Refresh, Scheduling, and Keeping the Data Current
A consolidated dashboard that shows yesterday's numbers is still useful for monthly reviews, but groups making same-day decisions, particularly around inventory transfers and sales pacing, generally need something closer to real time.
The refresh cadence we set up typically depends on what each metric is used for:
| Report Type | Typical Refresh Cadence | Why |
|---|---|---|
| Inventory and stock levels | Every few hours during business hours | Supports same-day transfer and pricing decisions |
| Sales pacing dashboards | Hourly or near real-time during peak selling periods | Lets sales managers adjust tactics within the day, not after it |
| Monthly performance and financial summaries | Nightly | Aligns with how monthly close and group reviews are actually run |
| F&I and product attachment trends | Daily | Useful for weekly coaching cycles without needing minute-by-minute accuracy |
Security and Access Across a Dealer Network
Multi-rooftop reporting raises access questions that single-location dealerships rarely need to think about. A general manager at one rooftop typically should not see every other location's gross profit figures, while group leadership needs the full picture, and a regional manager might need visibility into a subset of locations rather than all or nothing.
Power BI's row-level security handles this directly inside the same report, rather than requiring separate reports built per audience. Roles are defined once, mapped to rooftop, region, or group level access, and every user sees the same dashboard filtered automatically to what their role permits. This also means a single dashboard update benefits every audience simultaneously, rather than requiring the same change to be made across several parallel report versions.
Common Mistakes When Consolidating Dealer Network Reporting
A few patterns come up repeatedly when groups attempt this consolidation without addressing the underlying data architecture first.
Building dashboards before agreeing on metric definitions. If gross profit per vehicle or inventory age is not defined consistently before report building starts, the dashboard will simply make the inconsistency more visible rather than solving it.
Treating every rooftop's DMS export as already clean. Different systems use different field names, units, and even different fiscal calendars in some cases. Skipping the standardisation step in the data layer pushes that mess into every report instead of resolving it once.
Refreshing everything on the same schedule regardless of use case. Inventory dashboards used for same-day decisions need far more frequent refresh than monthly financial summaries, and treating them identically either wastes refresh capacity or leaves time-sensitive reports stale.
Skipping row-level security in the rush to get dashboards live. Retrofitting access control after a dashboard is already in wide use across multiple rooftops is considerably more disruptive than designing it in from the start.
Underestimating the work of connecting a genuine multi-DMS environment. Groups running more than one dealer management system across their rooftops often underestimate how much of the project is data reconciliation rather than dashboard design. Budgeting time for this upfront avoids a project that looks finished but produces numbers nobody fully trusts.
How Versich Approaches Dealer Network Power BI Projects
Most engagements start with an audit of exactly which systems are in use across the network, since the answer is rarely as simple as "everyone uses the same DMS." From there we agree on a single set of metric definitions with group leadership before any dashboard work begins, since this single step prevents the majority of trust issues that surface later in similar projects.
A typical project covers data source mapping and connection setup across every rooftop's systems, building the standardised data layer, designing the consolidated sales and inventory dashboards, configuring row-level security by role and rooftop, and a handover so the group's own team can extend reporting as the network grows.
For groups also weighing how this reporting layer should be structured for long-term performance and governance, our guide on Power BI data modelling best practices covers the structural decisions that keep a consolidated model fast and maintainable as more rooftops and data sources are added over time.
To learn more about how our Power BI team works with clients more broadly, visit our Power BI services page.
Conclusion
Consolidating sales and inventory reporting across a dealer network is less about visual dashboards and more about solving the underlying problem of inconsistent data across systems that were never designed to talk to each other. Once gross profit per vehicle, inventory aging, and every other core metric mean the same thing at every rooftop, the reporting itself becomes the easy part.
At Versich, we have built this consolidated layer for dealer groups running everything from a handful of rooftops on a single DMS to larger networks managing a genuine mix of dealer management systems across locations. If your group is still relying on manual spreadsheet reconciliation to get a network-wide view, contact our team and we will help you design the right consolidation approach for your network.
