Dealer Management Systems: What to Buy and What to Build Around It

A dealer management system (DMS) runs a car dealership's back office: vehicle deals, F&I, service, parts and accounting. For franchised dealers in the US, UK and Australia, buy it; CDK Global says $540 billion in automotive commerce runs through its systems each year. Build around it instead: lead routing, a used-car inventory website, trade-in tools and data sync.

This guide is for dealer principals, dealer group operations leads and automotive software founders deciding what to buy and what to build. A plain statement first: RAITHub has not shipped an automotive product, and has not shipped a DMS integration. What follows is engineering guidance drawn from patterns RAITHub has built elsewhere: lead routing on BlockEstate, Stripe payments on PropDesk (1,024 automated tests), and inventory plus role-based access on Sundor Skin.

What does a dealer management system actually cover?

A DMS is the system of record for the dealership's money and stock. It is where a vehicle is received into stock, costed, sold, financed, invoiced, serviced and accounted for, and where the numbers the manufacturer and your accountant see come from. The large vendors describe broadly the same core:

Vendor	What its own site lists	Source
CDK Global (North America)	Sales and digital retail, F&I, service and parts, business office and payments, data and analytics; a "Fundamentals Suite" for one- and two-site dealers; 1,000+ integrated partners	CDK Global
Reynolds and Reynolds (US)	ERA-IGNITE dealer management software covering sales, finance, service and parts, plus accounting, inventory and contract documents	Reynolds and Reynolds overview
Tekion (US)	An Automotive Retail Cloud with DMS, CRM, digital service, digital retail, parts, payments and payroll; says it powers 3,000+ dealerships	Tekion
Keyloop (UK and Europe)	Keyloop DMS alongside sales, acquisition, vehicle and service "hubs" on its Fusion platform	Keyloop

Vendor pages checked on 1 October 2026. Coverage differs by market and plan, and Australian dealers should ask each vendor what it supports locally before assuming a US feature list applies.

The point of the table is the overlap. Every serious DMS already handles deal structuring, finance and insurance products, repair orders, parts stock, the general ledger and manufacturer reporting. Those are the parts you should not rebuild.

Should a dealership build its own DMS?

Almost never. A DMS carries decades of accounting rules, manufacturer reporting formats, tax handling, finance-contract paperwork and parts catalogues, and franchised dealers are usually expected by their manufacturer to run an approved system. A custom rebuild costs years and gains you nothing a customer can see.

The one case where a custom back office makes sense is a business that is not really a franchised dealership: an online used-car retailer, a subscription or leasing start-up, or a specialist importer whose workflow the dealer systems do not model. Even then, the usual move is an accounting package plus a custom operations layer, not a DMS clone.

For everyone else the question is narrower and more useful: what sits around the DMS, and which of those pieces is worth owning?

What should you buy, and what should you build around the DMS?

Buy anything that is regulated, accounting-heavy or identical across dealers. Build the thin layers where your process is the difference: how fast a lead reaches the right salesperson, how your used stock appears online, how a trade-in turns into a booked appraisal, and how your group sees numbers across rooftops.

Capability	Usually	Why
Deals, F&I, accounting, repair orders, parts	Buy (the DMS)	Rules-heavy, manufacturer-facing, identical across dealers
Manufacturer reporting and warranty claims	Buy	Formats set by the manufacturer; the DMS vendor maintains them
CRM for a single rooftop	Buy	DMS vendors and third parties sell dealer CRMs with routing built in
Lead routing across several rooftops, brands or your own rules	Build a routing layer beside the CRM	Your territories, brands and capacity rules are data only you hold
Used-car inventory website and vehicle detail pages	Buy a dealer website, or build if search and speed are your channel	A group selling online at volume often outgrows template sites
Trade-in valuation data	Buy (licensed data)	You cannot produce market valuations yourself
Trade-in flow: photos, condition, appraisal booking	Build, if it is part of how you win stock	The flow, not the number, decides how many customers finish it
Data sync and a group reporting warehouse	Build	Cross-rooftop and cross-system reporting rarely exists off the shelf
Payment links and deposits on vehicles	Buy the processor, build the flow if the DMS option does not fit	Card handling stays with the processor either way

Before you build any of these, ask your DMS vendor what it already offers and what access it allows. CDK Global, for example, runs Fortellis, a platform with 135+ published APIs and 425+ marketplace apps (Fortellis). Other vendors run their own certified-partner programmes. Access, fees and dealer consent are set by the vendor and your contract, not by your developer.

How does lead routing work for a dealership group?

Every lead goes to exactly one salesperson by rule: a returning customer's own salesperson first, then the rooftop that stocks the vehicle, then the brand specialist, then round-robin, with a response deadline that reassigns ignored leads. The hard parts are the same in cars as in property, which is why the pattern transfers.

• A common lead format. Much of the automotive industry exchanges leads as ADF (Auto-lead Data Format), described by its maintainers as "an industry standard for sharing lead information" between the tools manufacturers and dealers use (ADF XML). Accept ADF in, normalise it to one internal shape, and route on that.
• Stock decides the rooftop. An inquiry on a specific VIN should go to the rooftop holding that vehicle, not the one nearest the customer. That needs the inventory sync below to be current.
• Duplicates are the norm. The same shopper submits through your site, a marketplace and the manufacturer's site in one evening. Match on email, phone and VIN within a window, and keep one owner.
• A record of why. Save the rule that fired with every assignment, so a sales manager can answer "why did this lead go there?" from data.

RAITHub built lead routing at the core of BlockEstate, a multi-tenant listing and inquiry platform whose MVP shipped in 6 weeks (BlockEstate case study). The rule order, fair round-robin, SLA reassignment and a TypeScript sample are in real estate lead routing; swap "listing agent" for "rooftop holding the VIN" and most of it applies to dealer groups unchanged.

How do you keep a used-car website in sync with the DMS?

Treat the DMS as the source of truth and the website as a read-only mirror. Pull the stock export on a schedule, validate every row, compare it with what the site shows, and apply only the differences. Never let a bad export empty the site.

The failure modes are predictable:

• Sold cars still listed. A customer drives an hour for a car that went yesterday. The sync interval and the "sold" status decide how often this happens.
• The empty feed. An export job fails halfway and sends 40 vehicles instead of 400. A naive sync unpublishes 360 cars. A circuit breaker refuses to apply a feed that shrinks suspiciously.
• Bad identifiers. A modern VIN is 17 characters, and under the US rule the letters I, O and Q are never used (49 CFR 565.13). Reject rows that fail the check instead of publishing them. Older or imported vehicles may need a manual path.
• Duplicates. The same VIN appears twice after a transfer between rooftops. Keep the most recently updated row.
• Prices in the wrong unit. Store integer cents or pence, never floating-point dollars.

The same thinking, applied to stock you sell rather than list, is in how to prevent inventory oversells.

What does DMS inventory sync look like in TypeScript?

A pure function that takes the validated feed and the site's current stock, and returns a plan: rows to upsert, VINs to hide, rows rejected with a reason. The database transaction applies the plan; the function itself touches nothing, so it is easy to test. This sample was written for this post as a minimal illustration, not taken from any client codebase.

type Status = 'in_stock' | 'in_transit' | 'sold'

type FeedVehicle = {
  vin: string
  stockNo: string
  rooftopId: string
  status: Status
  priceCents: number
  mileage: number
  updatedAt: string // UTC ISO 8601, same format on every row
}

type SiteVehicle = {
  vin: string
  status: Status | 'hidden'
  priceCents: number
  mileage: number
}

type Plan = {
  upserts: FeedVehicle[]
  hide: string[] // VINs listed on the site but missing from the feed
  rejected: { row: FeedVehicle; reason: string }[]
}

// 17 characters, letters I, O and Q excluded (49 CFR 565.13).
const VIN = /^[A-HJ-NPR-Z0-9]{17}$/

export function planSync(feed: FeedVehicle[], site: SiteVehicle[], minRatio = 0.5): Plan {
  const rejected: Plan['rejected'] = []
  const latest = new Map<string, FeedVehicle>()

  for (const row of feed) {
    const vin = (row.vin ?? '').trim().toUpperCase()
    if (!VIN.test(vin)) {
      rejected.push({ row, reason: 'bad_vin' })
      continue
    }
    if (!Number.isInteger(row.priceCents) || row.priceCents <= 0) {
      rejected.push({ row, reason: 'bad_price' })
      continue
    }
    const prev = latest.get(vin)
    if (!prev || row.updatedAt > prev.updatedAt) latest.set(vin, { ...row, vin })
  }

  const live = site.filter((v) => v.status === 'in_stock' || v.status === 'in_transit')
  const unsold = [...latest.values()].filter((f) => f.status !== 'sold').length

  // Circuit breaker: a feed that shrinks by half is far more likely
  // a failed export than a sell-out. Alert a human instead.
  if (live.length > 0 && unsold < live.length * minRatio) {
    throw new Error('Feed has ' + unsold + ' unsold vehicles, site shows ' + live.length + '; refusing to sync')
  }

  const current = new Map(site.map((v) => [v.vin, v]))
  const upserts = [...latest.values()].filter((f) => {
    const s = current.get(f.vin)
    return !s || s.status !== f.status || s.priceCents !== f.priceCents || s.mileage !== f.mileage
  })
  const hide = live.filter((v) => !latest.has(v.vin)).map((v) => v.vin)

  return { upserts, hide, rejected }
}

How it fits together: a scheduled job fetches the export through whatever access your DMS vendor grants, calls planSync, and applies the upserts and hides in one transaction, writing the plan to a sync log. Hidden vehicles are unpublished, never deleted, so a car that reappears in the next feed comes back with its photos and page history. Rejected rows go to a daily report for the stock controller.

Two honest limits. Comparing updatedAt as strings only works if every row uses the same UTC ISO format; parse to timestamps if your export does not guarantee that. And a 50% breaker is a starting guess: tune it to how much your stock really moves in one sync interval.

How do you build a trade-in tool that customers finish?

Keep the valuation number licensed and the flow your own. The customer enters a registration or VIN, confirms the vehicle, answers a few condition questions, adds photos, and books an appraisal slot. The number shown is a range with its source and conditions stated, and the appraisal confirms it.

• Short first step. Registration or VIN plus mileage gets a first range; ask for condition and photos after the customer has seen a number.
• A booked slot, not a form. The lead is worth most when it ends in an appraisal time at a specific rooftop, routed like any other lead.
• Say what the number is. An estimate, subject to inspection, from a named data source. Clear wording prevents most disputes at the appraisal.
• Photos are personal data too. Number plates and faces appear in them; store them with access controls and a retention period.

What data and security rules apply to software around a DMS?

Dealer data includes identity documents, finance applications and payment details, so anything you connect to the DMS needs strict access control, encryption and an audit trail. In the US, the FTC's Safeguards Rule guidance sets out expectations such as encrypting customer information, multi-factor authentication and overseeing service providers (FTC Safeguards Rule guidance). Whether and how it applies to your dealership depends on your business; the UK and Australia have their own data protection regimes. This is general information; confirm with your adviser.

In engineering terms that means per-rooftop and per-role permissions, so a salesperson at one site cannot browse another's finance files; an append-only log of who viewed and changed what; and least-privilege credentials for every integration. Sundor Skin, the B2B wholesale platform RAITHub built, runs 88 permission codes across 12 staff roles on PostgreSQL row-level security, which is the same shape of problem (Sundor Skin case study). The patterns are in SaaS authorisation and RBAC design and how to design a SaaS audit log.

RAITHub is not SOC 2 or ISO 27001 certified. It signs DPAs and follows your controls and your DMS vendor's integration terms.

Why RAITHub for this

• The adjacent patterns are built and shipped. Lead routing on BlockEstate, Stripe payments on PropDesk with 1,024 automated tests, and inventory with 12 staff roles and 88 permission codes on Sundor Skin. The automotive specifics are new; the engineering underneath is not.
• Honest about the DMS boundary. RAITHub has not shipped a DMS integration. Access runs through your vendor's programme and your contract, and scoping starts by confirming what the vendor allows.
• Sync treated as money logic. Validation, circuit breakers, idempotent jobs and a test for every rule, because a wrong price or a sold car online costs real money.
• Hours that reach you. RAITHub works from Dhaka (UTC+6). US clients get a daily 2-hour evening overlap, Dhaka 19:00 to 21:00, which is 08:00 to 10:00 in New York in winter. UK teams get about 3 hours (4 in British Summer Time); Sydney and Melbourne about 5 (4 in daylight saving), Brisbane 5 and Perth 7. The working week is agreed per client, and the rest runs on written daily handoffs.
• Fixed scope. A free 15-minute technical audit, then a written fixed quote. You own the code, and an NDA is standard.

When you don't need us

• You run one rooftop with standard processes. Your DMS vendor's CRM and a dealer website provider will cover it. Configure them.
• You want to replace the DMS itself. For a franchised dealer that is a vendor selection, not a build.
• Your vendor already sells the integration. If a marketplace app does the sync or routing you need, buying it is faster than a custom build.
• You need a native mobile app for sales staff. RAITHub builds responsive web applications and PWAs, not mobile apps.
• You want developers placed in your team by the hour. RAITHub offers fixed-scope builds and dedicated teams, not staff augmentation.

If the layer around your DMS is where leads, stock or reporting break, the API and backend development service covers integrations, sync jobs and routing services, and /fix handles a single broken job or feed. Book the free 15-minute technical audit with your DMS vendor, how stock and leads move today, and the one step that fails most often.

Last reviewed: 1 October 2026. Vendor pages checked on 1 October 2026.

Frequently asked questions

What is a dealer management system?

A dealer management system is the software a car dealership runs its back office on: vehicle stock, deals, finance and insurance, service repair orders, parts, accounting and manufacturer reporting. Vendors include CDK Global, Reynolds and Reynolds and Tekion in the US and Keyloop in the UK and Europe.

Can a dealership build its own DMS?

It can, but a franchised dealer rarely should. The accounting, manufacturer reporting and finance paperwork a DMS handles take years to rebuild. Build the layers around it instead: lead routing, an inventory website, trade-in flows and group reporting.

How do third-party tools connect to a DMS?

Through the access the DMS vendor grants: published APIs, a certified-partner programme or scheduled data exports. CDK Global's Fortellis, for example, lists 135+ APIs. Access, fees and dealer consent are set by the vendor and your contract.

How often should a used-car website sync with the DMS?

Often enough that sold cars disappear before a customer travels to see one; many groups aim for minutes rather than hours. More important than the interval is validation and a circuit breaker, so a failed export never unpublishes your stock.

What is ADF in automotive leads?

ADF, the Auto-lead Data Format, is an XML standard for sharing lead information between the tools manufacturers and dealers use. Accepting ADF and normalising it to one internal format lets you route leads from many sources with one set of rules.

Has RAITHub built a DMS integration?

No. RAITHub has not shipped an automotive product or a DMS integration. It has shipped the adjacent patterns: lead routing on BlockEstate, Stripe payments on PropDesk and inventory with role-based access on Sundor Skin. Automotive work is scoped as engineering guidance on that basis.