The CRM says sixty-two, the DMS says fifty-eight, and the manager trusts neither

Sixty-two and fifty-eight are almost never 62 real deals and 4 missing ones. In nearly every store the gap is definitional: the CRM is counting deals a salesperson marked sold, the DMS is counting deals the office posted, and those are different events happening on different days. Prove that before anyone starts hunting for lost records, because the hunt costs a week and finds nothing.

The proof is a record-level reconciliation of one month at one store. Not a total against a total — a list of deal identifiers from each system, matched, and sorted into 4 buckets. The bucket sizes tell you the cause faster than any conversation with either vendor, and the exercise is small enough to finish in an afternoon.

Sixty-two minus fifty-eight is four buckets, not one gap

Pull both lists for a single closed month, at a single store, and match them on whatever key the 2 systems share — usually a deal number, sometimes a VIN plus a customer surname. Then count.

1. Export every deal the CRM counts in the month, with its identifier, VIN, customer, salesperson and the date the CRM used to place it in that month.
2. Export every deal the DMS counts in the same month, with the same columns and the date the DMS used.
3. Match on the shared key. Where there is no shared key, match on VIN, then fall back to customer surname plus deal date within 7 days, and mark those matches as inferred.
4. Sort every deal into exactly 1 of 4 buckets: in the CRM only, in the DMS only, in both but placed in different months, or in both and agreeing.
5. Count each bucket and check the arithmetic closes. Agreeing plus different-month plus CRM-only must equal the CRM total; agreeing plus different-month plus DMS-only must equal the DMS total.
6. Read the individual rows in the 3 non-agreeing buckets. There will be fewer than 15 of them, and each one has a specific, findable story.

What the size of each bucket tells you immediately

The last row is the one worth ruling out first, because it is the only one that is genuinely a defect. A field-shift caused by a new column in the export will happily move a date value into the wrong column and produce dozens of deals in the wrong month, which reads exactly like a definition dispute until you look at the file — the diagnosis in the export gained a column overnight.

Booked, delivered, funded: one word, three events

The word sold does not identify an event. At least 3 candidate events sit behind it, and a store can be 10 days apart on the same deal between the first and the last.

• Booked. The customer has agreed and signed. This is what a salesperson marks, and it is what a CRM naturally counts, because a CRM exists to track intent through to commitment.
• Delivered. The vehicle physically leaves with the customer. This is the event most managers mean when they say the month's number, and it can trail booking by days when a vehicle is being prepped, located or fitted with accessories.
• Posted or funded. The office has completed the paperwork and the deal has hit the ledger. This is what the DMS counts, because the DMS is an accounting system first, and financing or documentation can hold it back further.
• Unwound. The deal is reversed after any of the above. Whether an unwound deal disappears, flips negative or keeps its original row is a per-system behaviour that has to be established rather than assumed.

None of these is the correct definition. They serve different purposes: a salesperson's pay plan and a manager's daily board reasonably run on booking, and an accounts department reasonably runs on posting. The failure is not having 2 definitions. It is having 2 definitions that nobody has written down, so that every report inherits whichever one its author happened to assume.

Which date each system stamps, and which one your report used

A deal record carries several dates and they rarely agree. Before comparing anything, establish which column each system's own report is filtering on, and then make sure your report is filtering on the one you intended rather than the one that happened to be convenient.

The service side has exactly the same disease under different names, which is worth mentioning because teams often assume sales reporting is uniquely messy. Whether a given job counts as one operation or two, and whether a particular repair obliges a further procedure, is a definitional question with money attached — the same shape of argument as which repairs trigger a calibration.

The month-end back-date, and why the gap closes by the fifth

Run the same month's report on the 1st and again on the 6th and you will often get 2 different numbers. That is not a bug in either system. Deals signed in the final days are posted in the first days of the next month with the previous month's date, and the office deliberately holds the period open to let that happen.

A month is not closed on the last day of the month. It is closed when the office says it is, and any report that quotes it before then is quoting a moving figure.

• Stamp every report with the load it was computed from and the date that load arrived. A figure without a provenance stamp cannot be compared with the same figure quoted last week.
• Do not lock a month in your own warehouse before the store's office has closed it. Ask the controller how many days they allow, and use that number.
• Make sure your loader actually re-reads rows it has already seen, or back-dated corrections will never reach you at all — the row-hash comparison in building a change stream from a full nightly file.
• If one system's count stops moving entirely while the other keeps changing, suspect the sync rather than the definitions. A write path running under a named person's login stops silently the day that person's password changes, which is the argument in the integration ran under a person's login.

Writing the definition where the report can read it

The reconciliation is worth doing once. Making it stay done is a different job, and a document does not achieve it — definitions written in a document drift back within a quarter because nothing enforces them.

1. Name the metric for its event, not for the outcome. 'Units delivered, delivery date, this store' is a name nobody can misread. 'Sales' is not.
2. Encode the definition in one place — a view, a model, a single query — and make every dashboard read from it rather than reimplementing the filter.
3. State the exclusions in the metric itself: unwound deals, wholesale, staff purchases, fleet. An exclusion that lives only in someone's head is a future 4-unit gap.
4. Publish both numbers side by side where both are legitimate, with the bridge between them shown. A manager who can see the 3 straddlers stops distrusting both systems.
5. Re-run the 4-bucket reconciliation monthly and automatically, and alert only when the non-agreeing buckets change shape. Under 15 exceptions a month is a healthy store; a sudden 40 is an integration incident.

That last item is a small, specific build: 2 extracts, a matcher, 4 counts and an exception list emailed to whoever owns the number. It is the sort of narrowly scoped internal product we take on under MVP and product builds, and it is worth doing before a group-level dashboard is attempted rather than after. The rest of this silo sits under DMS, CRM and shop-system integration, inside our automotive work.

• dms integration
• crm
• reporting
• reconciliation