All insights

    Part of our work on automotive

    Auto Industry

    What a Twelve-Location Dealership Group Loses to Inconsistent DMS Usage

    Big Sky Consulting Group · September 14, 2026 · 8 min read

    The question that takes a week to answer

    The dealer principal asks a simple question at the monthly meeting. Which of our twelve stores has the best customer-pay effective labor rate, and why is the worst one so far behind?

    The controller says they will get back to you. They mean it literally. Someone on their team exports twelve reports, discovers that three stores count internal work inside customer pay, that two stores discount labor through a line on the repair order and two others discount it through a separate op code, and that one store's "maintenance" category includes tires. By Thursday there is an answer. It comes with a footnote, and nobody in the room fully trusts it.

    That footnote is what inconsistent DMS usage costs. It is not a one-time cleanup bill. It is a tax on every question the group asks about itself, paid every month, mostly in salaried time that never shows up as a line item.

    Every vendor sells the same diagnosis

    Search for this problem and page one is DMS and finance software vendors, and they all read it the same way: your stores are on different systems, so you need one system, or one layer that sits over all of them.

    Sometimes that is true. A group assembled through acquisition often runs two or three DMS instances, and the symptoms are exactly what the vendors describe. OnPhase, which sells accounts payable software to dealer groups, puts it plainly: in a multiple-DMS group, each instance carries its own vendor master, approval routing, and chart of accounts, so group-wide AP visibility is the first thing to disappear and the work of stitching it back together falls to people exporting reports by hand.

    What none of the pitches address is the group that already consolidated. Twelve stores, one DMS, sometimes one login. The dashboards are there. They are just not believable.

    Two stores on the same DMS with different code sets are still two systems. The software is shared. The meaning of the data is not.

    Where the drift lives

    The pattern is consistent enough that we can usually predict where it sits before we look.

    Labor operation codes. Warranty op codes come from the manufacturer, which is one reason warranty is the most consistent data in the building. Customer-pay and internal op codes are invented locally. One store has 90 active codes. The store it acquired has 900, most of them a service advisor's shortcut from 2017. The same brake job is coded four ways across the group, so any group view of menu penetration or labor rate by job type starts with somebody mapping codes by hand.

    Pay types and labor types. Whether a get-ready on a used car is internal, whether a goodwill repair is customer pay at zero or a policy adjustment, whether a sublet is labor or parts. Each is a local decision. Each one moves a store's effective labor rate and gross percentage, which means the store that looks best on the group report may simply code most generously.

    Expense accounts. Every franchise submits a monthly financial statement to its manufacturer in the manufacturer's format, so the top-line structure is imposed from outside. Below that, stores sub-account however the office manager who set them up preferred. Policy expense, advertising, and demo costs land in different places at different rooftops, and a group-level comparison of controllable expense turns into a reclassification exercise.

    Technician time. Flag hours, clock hours, and how shop time is booked. When one store clocks technicians on and off every job and another only clocks attendance, their productivity numbers are not measuring the same thing, and the group's staffing decisions are made on a ratio that means twelve different things.

    None of these is a software defect. Each is a decision made locally because it was never made centrally.

    Why fixed ops is where it hurts most

    It would be easier to ignore if the drift sat in a small department. It does not.

    NADA's 2025 annual financial profile counts 16,990 franchised light-vehicle dealerships writing more than 276 million repair orders, with service and parts sales above $164 billion against total dealership sales of roughly $1.3 trillion. Fixed operations is about an eighth of the revenue. It is also the department that carries a disproportionate share of gross profit and the one that pays the bills when vehicle margins compress.

    So the department where coding is least governed is the department carrying the group's margin. Nobody would tolerate a new-car department where each store defined "gross" differently. In service, that is normal.

    We wrote about the same shape in hotel management companies, where every property runs the same PMS and still reports six definitions of "group" business. There, inconsistent PMS usage quietly blends different occupancy math into one portfolio number. The industries are different. The mechanism is identical.

    This is the general shape of the problem. Which parts apply to your process depends on answers only your systems can give.

    Put us on it, from $5,000

    What it costs, in the order it costs it

    The direct cost is the reconciliation time, and it is the number a vendor will quote you as payback. Count the hours your controller's office spends mapping codes and re-cutting exports at each close. It is real. It is rarely the biggest line.

    The controller's team becomes the integration layer. In a group without a shared code set, the most expensive people in the back office spend their month translating between stores instead of analyzing them. That work does not scale. Add a thirteenth store and you add its dialect, and the translation lives in one analyst's spreadsheet. When that analyst leaves, the group loses its ability to compare itself.

    Good practice does not travel. The best service director in the group has figured out something about menu selling or dispatch. You cannot see it in the numbers because that store's numbers are not comparable to anyone else's, so you cannot prove it, price it, or copy it. Groups buy scale partly to spread what the best store knows. Inconsistent coding quietly cancels that.

    Acquisitions stay acquisitions. A store bought three years ago still reports in its previous owner's language. Integration was declared complete when the DMS conversion finished. The operating integration never started.

    Pay plans reward coding, not performance. Where advisor and manager pay is tied to gross or labor rate, a store's coding habits flow straight into compensation. Two advisors doing the same work earn different money because their stores book internal work differently. Eventually someone notices, and that conversation is more expensive than any software.

    We will not put a dollar figure on this for a twelve-store group. We have not seen a credible published one, and any number that fit on a slide would be invented. The cost shows up as headcount in the controller's office, as decisions made on numbers nobody trusts, and as the gap between the group's best store and its median that never closes.

    Consolidation is not standardization

    The standard advice is to get everyone onto one DMS. For a group with three platforms it is often correct, and it is also a large, disruptive project with a real conversion risk in the service department.

    But a group that consolidates without standardizing the code sets first migrates the drift. The conversion vendor maps each store's existing op codes, pay types, and sub-accounts into the new instance faithfully, because that is the job. Eighteen months and a lot of money later, the group has one system with twelve dialects inside it. The dashboards look better. The footnotes are the same.

    The inverse also holds, and it is the part vendors have no reason to tell you. A group on two DMS platforms with one governed code set can compare its stores reasonably well, because the meaning is shared even where the software is not. Consistent definitions are the asset. The platform is the container.

    This is the same sequencing argument we made for franchise groups deciding whether to automate reporting or standardize the reports first. Automating a report that means different things at each location produces the wrong answer faster.

    Why standardization stalls

    If the answer is to govern the codes, why has almost no group done it well?

    Because nobody owns it. The controller owns the chart of accounts but not the op codes. The fixed ops director owns the service department but not the accounting. The general managers own their stores and have no reason to adopt another store's habits. The DMS vendor configures whatever each store asks for. Each of those people is behaving rationally. The code set is the thing that sits between all of them, which is why it drifts.

    It also stalls because it touches pay. Change how internal work is coded and some advisor's commission changes. Change how technician time is booked and some store's productivity drops on paper overnight. Standardization is announced as a data project and experienced as a compensation change, and the second one is what people push back on.

    Finally, it stalls because groups try to standardize everything. A master code list with every op code for every franchise is a year of committee meetings. The honest finding in most groups is that a small set of definitions decides whether the group report is believable, and the rest can stay local without much harm. Knowing which ones matter for your group is the work. It depends on your franchise mix, your pay plans, and what decisions the owners actually make from the numbers.

    This is a close cousin of why warranty claims stay manual: the problem looks like software, and it is really a question of who owns the rules.

    Where to start

    Before you price a DMS consolidation or a reporting layer, ask one question of your own group. Could your controller answer the labor rate question above, for all twelve stores, from the DMS alone, without a phone call to any store?

    If the answer is no, the gap is not software. It is a set of definitions nobody owns, and every tool you buy will inherit it.

    That diagnosis is what we do. We sit in the stores and the back office, find which definitions are actually breaking the group view, and tell you whether you need a new system or just a shared language inside the one you have. If your group can't compare its own rooftops without a week of reconciliation, let's talk it through.

    AutomotiveDealership OperationsFixed OperationsDMSGroup Reporting

    Want this applied to your business?

    A paid working session on one of your processes, ending in a written implementation plan. Not a sales call. Consults start at $5,000, and you see the price before you commit.

    Book a consult