How do you check CRM data automatically?

You check CRM data automatically by running fixed rules over your records: required fields left empty, values that contradict each other, deals that sit too long in one stage, and won deals with no order or invoice behind them. The rules run daily or on every change, and every exception becomes a task with an owner. The most important part is not the check inside the CRM but the comparison with the systems where the money really sits: your ERP and your billing.

Why doesn't manual checking work?

Most companies check their CRM once a quarter, just before a forecast review or a board meeting. Someone exports the pipeline to Excel, goes through the large deals and corrects what stands out. That catches the errors in the ten biggest deals. The hundred small ones stay.

The problem is not that people are careless. A CRM is filled in by salespeople who treat data entry as a side task next to their real job. Fields are completed when the deal is marked as won, not when the information changes. A customer who moves from a three-year to a one-year contract during negotiation is often still in the CRM with the original term. Nobody lied. Nobody updated it.

Automatic checking shifts the work. Instead of someone going through every record, a rule finds the records that deviate and puts them in front of the person who can fix them. That makes it possible to check every day instead of every quarter.

What kinds of CRM checks are there?

Not every check is equally valuable. It helps to divide them into four kinds, from simple to valuable.

1. Completeness

Is the field filled in? This is the easiest check and also the least interesting. A deal marked as won with no contract value, no start date or no linked company is an incomplete record. Most CRMs can enforce this themselves: Salesforce with validation rules, HubSpot and Pipedrive with required fields per stage.

Watch the side effect. Required fields lead to filled fields, not to correct fields. A salesperson who wants to close a deal and hits a required field called "expected term" enters something. Often "12". That is why completeness is only the start.

2. Internal consistency

Do fields within the same record contradict each other? Examples:

• Contract value divided by term differs sharply from the monthly price.
• The deal is marked as won, but the close date is in the future.
• The product on the deal belongs to a price list that is no longer valid.
• The discount is higher than the salesperson may give without approval, and no approval is recorded.

You catch these with rules that look at two or more fields at once. They find errors a required field will never find.

3. Behaviour over time

Does the history of a record match how your sales process works? A deal that sits in the "proposal" stage three times longer than the average deal is probably dead. A deal whose close date has been pushed back five times is unlikely to close when the CRM says it will. A deal that jumps from "first meeting" to "won" in one day was often entered after the fact.

These checks need history: you have to know how long deals normally stay in a stage. That differs by company, by product and sometimes by salesperson. A fixed rule of thumb such as "90 days" is worse than the actual cycle time from your own data. The same signals make a pipeline unreliable as a basis for a forecast.

4. Matching against other systems

Does what the CRM says match what the rest of the company does? This is the check that finds the most money, because this is where revenue leakage becomes visible:

• A won deal with no order in the ERP.
• An order with no invoice.
• A contract value in the CRM that differs from what is invoiced.
• A customer marked as active in the CRM who has not bought anything for months.
• A customer marked as cancelled in the CRM who still receives invoices, or the other way round.

This only works if you can link records between systems. How to do that is set out in CRM-to-billing reconciliation explained and in how to check CRM against billing.

How do you write a check rule?

A good check rule has five parts. Write them out before you build anything, in an ordinary document.

1. What is the error? In one sentence. For example: a deal is marked as won, but no order has been created in the ERP within 14 days.
2. What data do you need? Deal status, close date and deal number from the CRM. Order number and a reference to the deal from the ERP.
3. What is the threshold? Why 14 days and not 7? Look at your own cycle time. Too tight gives noise, too loose leaves errors sitting for too long.
4. Who fixes it? Not "sales" or "finance", but a role: the deal owner, order administration.
5. What is it worth? The contract value of the deal, or the monthly amount times the months it has been open. An alert with an amount attached gets picked up sooner.

Start with five to ten rules, not fifty. Every rule that produces many false alerts undermines trust in the rest. A team that gets twenty alerts a day, eighteen of which are nothing, stops looking after two weeks.

Where does it go wrong?

No shared key. The most common reason automatic checking across systems fails: the CRM knows the customer "Jansen Installation Services Ltd", the accounting system knows debtor 10442 "Jansen Install. Ltd", and nothing connects the two. Without a fixed customer ID or deal number that exists in both systems, you have to match on name, and that regularly goes wrong. So the first investment is often not the check itself but recording that key.

Checking what is easy instead of what is expensive. Finding empty phone numbers is simple. It just costs you nothing. A contract that is EUR 48,000 a year in the CRM and EUR 42,000 in billing costs you EUR 6,000 a year. Rank your rules by what an error costs, not by how easy it is to find.

Alerts without an owner. A dashboard full of red tiles that nobody is responsible for changes nothing. Every exception has to land with one person, with a deadline.

The rule fixes the data, not the cause. If the same error comes back every week, the check is a sticking plaster. Look at the process then: is a field missing, is the handover from sales to administration unclear, or is a price list not being updated? The article on revenue leakage from data problems goes into this in more depth.

Where should the checks run?

There are roughly three places.

For completeness and internal consistency, the CRM itself is the best place: you prevent the error at the moment it arises. For behaviour over time and matching against other systems you need something that reads several sources at once. Whether you build that yourself or buy it depends on whether you have someone who can maintain it for years. A check that stops running because an API field was renamed is only noticed once the money has already gone.

Worked example

Worked example: suppose a wholesaler of technical parts with EUR 8 million in revenue signs 400 new framework agreements a year through the CRM. An automatic check compares every won deal with the orders in the ERP and finds that 12 deals still have no order after 30 days. On investigation, 4 turn out to have been genuinely forgotten: the customer was expecting delivery, order administration knew nothing about it. The average first order per contract is EUR 6,500.

The direct value is then 4 times EUR 6,500, so EUR 26,000, which would otherwise have been invoiced late or never. The other 8 alerts were valid but harmless: the customer had moved the start date. That information still belongs in the CRM, because otherwise your forecast relies on it.

This is an example, not an average. What a check delivers depends on how well your handover from sales to administration works today.

A plan for the coming month

1. Choose three fields that determine money. Usually: contract value, term or end date, and price or discount.
2. Record which system leads for each field. The CRM, the ERP or the contract. Without that agreement every exception becomes a debate. See also which data source leads for revenue.
3. Put a shared key in place. A customer number or deal number that exists in both the CRM and the accounting system. Start with new deals and fill in existing customers step by step.
4. Write out five rules using the five parts above.
5. Run them once by hand first on an export, to see how many alerts they produce and how many are real.
6. Automate the rules that are worth it, with a fixed owner per alert and a euro amount attached.
7. Review after four weeks: which rule was noisy, which found money, which error kept coming back?

If you want to tackle this more broadly than the CRM alone, start with the question of how to get a single source of truth for revenue. Checks are then the tools that guard that truth.

Frequently asked questions

Can't my CRM do this itself?

Partly. Validation rules and required fields catch incomplete and contradictory records within the CRM. What a CRM cannot see is whether a won deal actually got an order and an invoice. For that you have to put its data next to that of other systems.

How often should a check run?

As often as the error costs money. A won deal with no order is something you want to see within days. A missing phone number can wait. Daily is a good default for most rules.

What if the error is not in the CRM but in billing?

Then the check has done its job. A difference between two systems does not tell you which system is wrong. That is why you decide in advance which source leads for each field, and why you also check billing itself. See how to check billing automatically.

Do I need AI for this?

Not for the basics. Most of the valuable checks are simple rules. AI helps with matching records that have no shared key, with spotting unusual behaviour you had not thought to write a rule for, and with reading contracts where the terms are in free text.

Where do I start if my CRM is a mess?

With the deals from the past twelve months and the three fields that determine money. Cleaning up old records takes a lot of time and delivers little. Getting new records right delivers something straight away.