incadea — A Dealer System on Familiar Ground

incadea has solved a problem that is harder than it looks from outside the industry. A dealership is not one business with four departments; it is four businesses with different economics and different customers, sharing a roof, a ledger and a car park. incadea covers all four in one application and holds certified interfaces to more than sixty manufacturers, each with its own data formats, warranty rules and submission obligations, each changing them on its own schedule. Maintaining that for a quarter of a century is a serious commitment, and incadea has met it.

Less appreciated is what sits underneath. incadea built its DMS on a Microsoft ERP platform rather than on a stack of its own — so a system that looks highly specialised from the front is, from the data layer’s point of view, familiar ground.

At a glance

What incadea is

incadea is a dealer management system: the operational and financial backbone of a car dealership, covering new and used vehicle sales, the workshop, the parts business and the accounting that ties them together. It began in Bavaria around the turn of the century and made one architectural decision early that has shaped everything since — it built the DMS on a Microsoft ERP platform rather than on a stack of its own.

That decision is why this page exists as a sibling to the Business Central article rather than as a standalone. A general ledger, receivables, payables, fixed assets and dimensions were already there. incadea’s work sits on top, adding what no general ERP ships — a vehicle as a first-class record with its own ledger entries, a service order that behaves like a job, a parts warehouse tuned to manufacturer catalogues, and the manufacturer interfaces themselves.

The ownership matters more to a dealer group than corporate history usually does. Volaris Group, and Constellation Software above it, run a model of long-horizon ownership of vertical software — which means the product is maintained rather than sunset.

The incadea lines, and the Microsoft platform under each

“incadea” names several things with different data stories. Anyone planning reporting needs to know which one.

The data story for most installations is inherited from Business Central — the dimension sets that have to be flattened, the company-prefixed tables, the batch consolidation into a company holding totals rather than transactions. It is set out in the Business Central article and it applies here. But that only tells you how to get the data out, not what a dealer group needs to do with it.

Who incadea fits

Franchised dealers, single-site or multi-site. If you hold a franchise, the manufacturer’s interface obligations are not optional, and a DMS carrying certified interfaces to your brands removes an entire category of problem.

Multi-brand dealer groups. This is where incadea’s design shows best. The International Make Layer lets one installation serve several franchises with different interface requirements, so a group holding three or four brands does not need three or four systems.

Importers and national sales companies. incadea extends the DMS into importer territory — import cost management, dealer claim handling, the position between the manufacturer and the network. Your questions differ from your dealers’, and the vendor has built for both.

Commercial vehicle and truck dealers, and independent workshops. The economics differ from passenger cars — contract maintenance, uptime obligations, a different parts profile. incadea’s CEE partner sells explicitly to commercial-vehicle dealers and service shops, so the truck side is scoped rather than assumed.

Groups that grew sideways. incadea in the dealerships, something else in the property company that owns the sites, a separate system in the leasing arm, a spreadsheet holding the bodyshop joint venture. Every one of those choices was locally correct. What nobody owns is the view across them, and this is how incadea most often reaches us.

What incadea holds — and why it is good material

Before the reporting question, the asset: incadea holds an unusually complete operational and financial picture in one place.

Because the vehicle is a first-class record, a car carries its own ledger entries. Purchase cost, transport, the workshop hours and parts spent making it saleable, financing, and finally the sale — all of it attaches to the vehicle. incadea’s own Automotive365 Accounting documentation shows the shape directly: a Vehicle Card, Vehicle Ledger Entries beneath it, and a Vehicle Trial Balance across them. For used-vehicle profitability that is the right structure to have inherited.

The service side is equally well formed: a service order carries labour, parts, warranty and internal work, and posts to the ledger as it goes. The accounting underneath is a real general ledger, not a reporting export bolted onto an operational system.

The dimension framework is where the analytical structure lives. incadea’s Automotive365 Accounting setup asks the implementer to nominate a Business Central dimension for Sales Channel, one for Department, one for Brand and one for Vehicle, with no pre-defined values, so each dealer chooses their own codes. Those are exactly the axes a dealer principal thinks in, and they are present. They are also, being Business Central dimensions, stored as dimension sets that have to be flattened before a data model can use them, and configured per installation rather than standardised across a group.

And the data quality is usually good, for a reason peculiar to this industry: the manufacturer checks. A dealer submitting a monthly statement in the OEM’s own format has an external party validating the books every month — a discipline most mid-market companies do not have.

What sits outside incadea’s scope

incadea is scoped to running a dealership well and satisfying the manufacturer. Three things sit outside that scope, each boundary deliberate.

The management chart of accounts, as distinct from the manufacturer’s. The structure is doing exactly what it was designed to do: a franchised dealer’s chart of accounts is largely imposed by the manufacturer, who requires a standard account structure and a periodic submission — the composite, or dealer statement — so that every dealer in the network can be measured on the same basis. The benchmarking that comes out of it is genuinely useful. It also means the reporting answers the manufacturer’s questions rather than the dealer principal’s. Holding a management structure alongside the manufacturer’s is not a workaround; it is the normal state of a well-run dealer group.

The view across dealerships, franchises and legal entities, at transaction level. incadea inherits Business Central’s consolidation — more capable than most systems in this series, but a batch transfer of totals into a consolidated company holding no live business data, with eliminations entered by hand. For statutory consolidation that is often enough. For a group view a dealer principal interrogates — drilling from a group used-vehicle margin to the car that produced it — the view has to sit above the ERP.

The view across systems. Whether the F&I commission statement matches the ledger, whether the leasing arm’s numbers square with the dealership’s, whether the bodyshop joint venture reconciles at all. No DMS does this, and no ERP does either. Not incadea, not Business Central, not SAP. Cross-system truth is a layer above every transaction system, which is the point we make at length here .

None of this is a reason to change system. It is a reason to add a layer.

How we elevate it

We connect incadea in dealer groups running it across several sites and legal entities, alongside whatever else the group has accumulated.

Getting the data out is the straightforward part, and it is straightforward because of what incadea is built on. Where incadea runs on Business Central on-premises or partner-hosted, or on Dynamics NAV, the database is SQL Server and our default is a read-only SQL login — or better, a read replica. We read the general ledger and the vehicle, service and parts subledgers from that one database, incrementally and nightly, allowing for the company-name prefix and, in the AL era, the extension GUID in the table name. Where a group runs incadea Automotive Cloud with Business Central behind it, we read both and reconcile them rather than assuming they agree. Read-only throughout, nothing written back, and users notice no difference in how the system performs.

What happens next is the incadea-specific work.

A management chart of accounts alongside the manufacturer’s

The manufacturer’s structure stays exactly as it is. Nothing we build touches it, and nothing changes what you submit. Alongside it we map a second structure built to answer the dealer principal’s questions rather than the OEM’s — revenue by what you actually sell, cost by what you actually control, margin at the level you actually decide. This mapping earns its keep faster in a dealer group than anywhere else in the series, because the gap between the imposed structure and the management one is wider here than in a company that chose its own accounts. More on the problem underneath: chart of accounts architecture .

True departmental contribution, including the internal transfers

Departmental contribution is hard not because the postings are missing — they are all in incadea — but because the four businesses trade with each other constantly. The workshop prepares used cars for sale. Parts issues stock to workshop jobs. Each of those is an internal charge, and each has to be handled consistently or all four departmental P&Ls are wrong at once, in offsetting directions that leave the group total looking fine.

So we do that work explicitly. Internal service orders and parts issues are treated as transfers rather than as revenue and cost, on a basis agreed with you and applied the same way every month. Preparation cost accumulated against a vehicle follows through to the used-vehicle department where it belongs. Warranty work is separated from customer-pay and internal work, because the gross margin on the three is not remotely the same. The dimensions are flattened and made consistent across every company, so “Service” means the same thing in every dealership. What comes out is four contribution statements that add to the group result and that a department manager will accept as fair — the real test of profitability analysis , and the point at which a cost centre structure starts being used rather than maintained.

The same layer carries the balance-sheet half: days in stock by unit, ageing bands by site and by brand, and the cash tied up in used-vehicle stock visible daily instead of monthly.

One view across every dealership, franchise and entity

Each incadea company becomes one entity in a common model — beside another incadea installation, a leasing or fleet system, a bodyshop’s own books, a payroll export or a spreadsheet, all producing the same standardised output. Group reporting in any currency with currency translation applied consistently, reconciliation across systems, intercompany elimination, and drill-down from a consolidated total back to the incadea entry behind it — the step the consolidated company inside Business Central cannot offer.

This is routine rather than aspirational: we work with 70+ companies across 11 countries, on 12+ different ERP and accounting systems. See Group Reporting & Consolidation .

On the governed layer, the rest is the platform doing its standing job: daily reconciliation against the ledger so the close confirms rather than rebuilds, a semantic model that Power BI and AI can both query reliably , and your business context accumulating so answers get sharper the longer it runs.

What becomes answerable

• Which of my four departments is actually funding the others, after internal transfers are charged properly?
• What is the true contribution on used vehicles at each site, after preparation cost and the workshop hours that went into it?
• How much cash is tied up in used-vehicle stock over ninety days, by site and brand, today rather than at month-end?
• Which franchise is earning its floorspace, when two brands share one site and one set of overheads?
• What is service absorption by workshop, against budget and last year?
• What is group EBITDA across every dealership and legal entity, in one currency, before the consolidation?

Every one of these is answered from data incadea is already holding. The information was there. What was missing was the structure to ask.

What it takes, and what does not change

Connection in days. First reports in the first week. For a single-entity incadea client, the connection is a read-only login and the first governed reports follow inside a week. A full build — management chart of accounts, dimension repair, consolidation across several entities, the reporting suite — runs in phases over the following months. The distinction matters, and we would rather be precise about it than promise a finished model in a fortnight.

What we need from you: an NDA, read-only access, and a conversation about what the numbers should mean.

What does not change: incadea stays your system of record. Your accountant keeps working the way they work. No migration, no data cleanse project, no retraining, nothing written back. Your OEM submissions carry on exactly as they do now.

Read-only access throughout. Your data stays in an EU-hosted Azure environment, aligned with ISO 27001 and GDPR, governed by you.

In practice

MB Trenčín runs incadea — worth naming for what it demonstrates.

incadea is built on the Microsoft Dynamics platform, so from the data layer’s point of view it reads like the Dynamics estate it descends from — the same lineage, the same dimension thinking, the same route to the data as Business Central . A system that looks industry-specific from the front is very often a familiar platform underneath, which is why “ours is a niche system” changes the answer far less often than people expect. The vertical is real and it matters operationally. It does not make the data unreachable.

When the system underneath changes

incadea is usually a long-term fixture, because a DMS is chosen against franchise obligations rather than a purchasing cycle. When it does change, the trigger is commercial: a group takes on a franchise whose manufacturer favours a different DMS, or acquires a dealership running something else that has to reach the group view long before it reaches the group system.

There is a second direction of travel specific to this system. incadea’s DMS line has moved from Dynamics NAV to Business Central, and any dealer group still on NAV faces a platform upgrade at some point — a real project, usually scheduled against operational priorities rather than reporting ones. Which is precisely why the reporting layer should not wait for it.

In both directions the same thing holds: because the governed layer sits above the system, only the connection changes. Groups that built the layer first find the migration easier, because they can prove the new system’s numbers against the old from day one.

This is not a theoretical claim. When JING Tea replaced its operational stack, the reporting layer carried through the change unaltered — the systems underneath moved, the numbers and the reports did not.

How incadea compares

incadea is one of several capable systems in the estates we work in, and the only vertical one in the series so far.

From a data-layer perspective the choice matters less than it appears: each becomes an entity in the same governed model, so the DMS decision can be made on operational fit rather than on reporting fear.

Frequently asked questions

Do we need to replace incadea to get proper management reporting? No, and we would usually advise against it. Keep incadea for what it does well — dealership operations, the manufacturer interfaces, statutory correctness — and build the reporting layer above it. In automotive, replacing a working DMS to solve a reporting problem is worse than merely expensive: your franchise obligations run through that system.

Is Onetribe a replacement for incadea? No. incadea remains your system of record and your team keeps using it exactly as they do now. We read from it, never write to it. If you change DMS later, the reporting layer stays.

Does this interfere with our OEM reporting submissions? No. The connection is read-only, so the manufacturer’s account structure, your postings and your monthly submission are untouched. We build a management view alongside the manufacturer’s structure, not instead of it — and seeing both side by side is usually where a dealer principal stops treating them as competing versions of the truth.

What database does incadea use, and can we read it directly? Where incadea runs on Business Central on-premises, partner-hosted, or on Dynamics NAV, the database is SQL Server and can be read directly, read-only — our default. Two things to know before anyone writes a query: company-specific tables are separated by a company-name prefix rather than a company column, so a five-dealership database has five separate general ledger entry tables; and incadea’s own objects carry the extension GUID as a further name segment. On Business Central online, APIs are the only supported read path.

Can we get true departmental profitability across new, used, workshop and parts? Yes, and it is the most requested thing we build for dealer groups. The postings are all in incadea; the work is in handling the internal transfers consistently, and in separating warranty, internal and customer-pay work, because their margins differ. We agree the transfer basis once and apply it every month.

Can incadea consolidate several dealerships or legal entities? It inherits Business Central’s consolidation, which handles differing charts of accounts, fiscal years and currencies. But it transfers totals rather than transactions, so there is no drill from a group figure to the vehicle behind it, and eliminations are manual. Wanting to interrogate the group number is the most common reason multi-entity dealer groups come to us.

Does incadea have an API? Yes, on more than one level. incadea describes an API-first approach for its cloud platform and maintains certified OEM interfaces through the International Make Layer. Underneath, where incadea runs on Business Central, that platform’s REST v2.0, OData v4 and custom AL API pages are available, with the same constraints described in the Business Central article . For analytical extraction against an on-premises installation, direct SQL remains the better route.

Is incadea’s own reporting enough? For a single dealership, often yes — and worth using before adding anything. incadea’s Automotive BI carries a substantial library of operational reports, KPI dashboards and cash-flow forecasting, and it knows what a service order and a vehicle are. It runs out in the same three places every vendor’s reporting does: across legal entities, across systems, and anywhere a definition needs to be shared and governed rather than held locally. See what a governed BI layer adds when one dealership is not the business.

Official incadea resources

• incadea — company and product overview
• About incadea and current ownership
• Dealer management system overview
• OEM integrations and the International Make Layer
• Data and insights — incadea’s BI
• incadea product documentation
• incadea apps on Microsoft AppSource
• incadea in Czechia, Slovakia and Poland — Seyfor

Onetribe is not an incadea partner or reseller. We build the governed data layer above your system, whichever system that is.

Next steps

• Every source system we connect — the series hub, with the full matrix
• How we consolidate any combination of systems — group reporting
• Why your ERP doesn’t govern your data — the cross-system layer, in detail
• Discuss your dealer group’s estate — free assessment