Ask three stores in the same group how many cars they sold last month and you'll get three answers that are all correct. The problem was never lying. It's that "a sale" means something different in every system — and nobody built the layer that settles it.
The short answer: dealer groups don't struggle to consolidate reporting because their people are careless. They struggle because each rooftop defines the same word differently — booked vs. delivered, who owns a transferred unit, whether wholesale counts — and the monthly spreadsheet that papers over it is stale, manual, and quietly distrusted. The fix isn't a bigger spreadsheet. It's defining each metric once, reconciling every store's feed to that definition, and putting the result on one live board every rooftop shares.
Picture a five-rooftop group. Two of the stores run one DMS, two run another, one came in through an acquisition and still runs its own. Each has its own CRM habits, its own service system, its own idea of when a deal is "done." None of that is wrong. It's just local.
Now ask for one number. Watch what happens:
Every one of these is a definition, not a data-entry error. And definitions don't reconcile themselves in a spreadsheet — someone has to decide, once, and then make every feed obey the decision.
Almost every group already has a "solution": a controller or a GM pulls each store's numbers, pastes them into a master workbook, and hand-reconciles the differences from memory. It works, sort of. It also has four fatal properties:
The spreadsheet isn't the disease. It's the scar tissue that grew over the real wound: no shared definition and no automated reconciliation.
Getting to a board-ready group number that every rooftop trusts is three jobs, in order. Skip step one and the other two just automate a lie faster.
Before any tool, the group has to decide: a sale is counted on delivery (or on booking — pick one), a transferred unit belongs to the delivering store (or the sourcing store — pick one), wholesale is reported in its own line, and the administrative branch is excluded from retail entirely. Write it down. This is a governance decision, not a software feature — but it's the one everyone skips, and it's why the software never sticks.
Now each rooftop's data has to be transformed to obey the shared rule, regardless of which system it came out of. The delivery-basis store and the booking-basis store get put on the same basis. Transfers get resolved to one owner so no car is counted twice or zero times. The excluded branch is dropped consistently, everywhere, automatically — not remembered by hand each month. This is the layer that sits above your DMS and CRM: it doesn't replace them, it makes them agree. That distinction is the whole definition of dealer intelligence software.
The reconciled number belongs on a screen the whole group sees, refreshed continuously, drillable from the group total down to the store, the branch, the individual deal. When someone questions a figure in the meeting, you click into it instead of defending a spreadsheet. Same definition, same board, same day — for every rooftop.
The hardest version of this is the group that genuinely runs more than one DMS — usually because it grew by acquisition and never force-migrated the stores it bought. The instinct is to rip and replace onto one system. Sometimes that's right. Often it's a year-long, revenue-risking project to solve a reporting problem that doesn't require it.
The alternative is to stop treating the DMS as the reporting layer at all. Let each store keep the operational system its people know. Put the group's intelligence layer on top, and make that the place where "a sale" is defined and every store's feed is reconciled to it. The DMS runs the store; the intelligence layer runs the group. You get one number without betting the year on a migration.
| Where they differ | Rip-and-replace to one DMS | Reconcile above the stack |
|---|---|---|
| What changes at the store | Everything — new system, retraining, cutover risk | Nothing — keep the system they know |
| Time to one trusted number | Months to a year | Weeks |
| Revenue risk during the project | Real — cutovers stall stores | Low — nothing operational is touched |
| Where "a sale" is defined | In whichever DMS won | Once, at the group layer |
| At the next acquisition | Another migration | Point the layer at the new feed |
Neither is free, and a genuinely messy multi-system group will still need real data work to reconcile the feeds. But you don't have to solve a migration to solve reporting — and most groups have been told, by people who sell DMSs, that you do.
One trap worth naming: consolidation makes good data agree, and it makes bad data agree confidently wrong. If each store's lead source is guessed at the desk — "walk-in," "drive-by," "manual add" — rolling five stores' guesses into one group report doesn't produce truth, it produces a bigger, more authoritative-looking guess. That is its own fixable problem: why the lead-source field is wrong and how to clean it up. A group number is only as honest as the attribution underneath each store. The same holds for cost per sale: it's meaningless at the group level until every rooftop computes spend and sold units the same way. Fix the definitions and the source quality, or you've just scaled the error.
For a dealer group, "we have reporting" should mean all of this:
Before you trust a group number, confirm all six:
Get those six and the group conversation changes. The owners' meeting stops being an argument about whose numbers are right and starts being an argument about what to do — which is the only argument worth having. The single-store version of that board is the daily KPI dashboard; a group is the same idea, one level up.
Why do two dealerships in the same group report different sales numbers? Almost always because they define "a sale" differently, not because anyone is wrong. One store may count a unit when the customer signs (booked), another when it's delivered — in a month with a delivery backlog those differ by days and by units on the identical cars. Add inter-store transfers that both stores feel they earned, and differences in whether wholesale or house-branch activity is folded into "units sold," and two honest reports diverge. The fix is a single group-level definition of each metric that every rooftop's data is reconciled to, rather than a spreadsheet that papers over the gaps by hand.
How do you consolidate reporting across a dealer group that runs more than one DMS? You don't have to migrate everyone onto one DMS to get one number. Put an intelligence layer above the stack: let each store keep the operational system its people know, define each metric once at the group level, and reconcile every store's feed to that definition automatically. The DMS runs the store; the group layer defines "a sale," resolves transfers to one owner, excludes administrative branches, and produces a single reconciled board. That's weeks of data work instead of a year-long, revenue-risking cutover — and the next acquisition is a new feed to point at, not another migration.
Why isn't a month-end spreadsheet enough for a dealer group? Because it's stale, manual, unauditable and fragile. By the time it's assembled it describes a month already gone, so it can't change any outcome; it depends on one person re-doing the same reconciliations and remembering which store double-counts transfers; when a number looks wrong nobody can trace it to source, so the meeting argues about whose spreadsheet to trust; and if that person leaves, the group's single source of truth leaves too. A live, reconciled board drillable to the deal removes all four problems at once.
GhostDrive defines each metric once, reconciles every store's feed to it — sold-vs-delivered basis, transfer ownership, excluded branches — and puts one live, drillable number in front of the whole group. No month-end workbook, no "whose spreadsheet do we trust."