How does Revenue Intelligence work?

Revenue Intelligence works in four steps. It reads data from your existing systems, connects the records that belong to the same customer and the same agreement, compares what should have happened according to the deal and contract with what was invoiced and paid, and turns every difference into a task with a euro amount. The hardest and most important part is connecting: until it is settled which invoice lines belong to which deal, there is nothing to compare.

Below we follow those four steps through a single deal, from the CRM to the paid invoice. For the wider story of what Revenue Intelligence is, see the complete guide to Revenue Intelligence.

Revenue Intelligence from CRM to invoice

Take a concrete deal. An installation company sells a maintenance contract to a healthcare organisation:

• Deal in Pipedrive: EUR 36,000 a year, three years, closed on 15 March.
• Contract: monthly invoicing of EUR 3,000, annual indexation every 1 January in line with a published wage index with a minimum of 2 percent, additional work at EUR 85 an hour.
• Billing in AFAS: monthly invoice set up from April.
• Hours in the planning tool: additional work twice in June, 14 hours in total.

At this point there are four systems that each know part of the story. None of them knows whether the whole is correct.

Step 1: Read

Revenue Intelligence starts by pulling data from each system. In the example:

• From the CRM: the deal, the value, the term, the close date, the customer, the owner.
• From the contract: the monthly price, the indexation clause, the rate for additional work. If the contract exists only as a PDF, it is extracted. That can now be done with AI, with a person checking the extracted values.
• From billing: all invoice lines for this customer, with date, description, quantity and price.
• From planning: the hours per customer per project, with a flag for additional work.

The data is pulled through connections to the systems, preferably with read access, and the process repeats continuously. Which systems to connect is covered in which systems to connect for Revenue Intelligence. Which fields really matter is covered in what data Revenue Intelligence uses.

Step 2: Connect

Now there are four piles of data. The question is which pieces belong together. In the jargon this is called entity resolution or matching, and it happens at two levels.

The customer. In Pipedrive the customer is called "Linden Care Group", in AFAS "Linden Care Group Foundation", in the planning tool "Linden, North site". The system has to see that this is the same party. Preferably on a hard key, such as a company registration number or customer account number that appears in every system. Where that is missing, on the basis of name, address and pattern, with a confidence score.

The agreement. Within that customer, the deal has to be linked to the contract, the contract to the monthly invoices, and the additional hours to any invoices for additional work. Order numbers and contract numbers help here, provided they are passed along everywhere. In many companies that does not happen consistently, and then the connection has to be made on amount, date and description.

This is the step where home-built solutions in spreadsheets or Power BI usually get stuck. Connecting is not a one-off job. Every new customer, every new deal and every typo in a name calls for a new decision.

A practical principle: for every connection, show how it was made. A match on contract number is reliable. A match on a similar-looking name is a proposal. That distinction later determines how certain a finding is.

Step 3: Compare

With the records connected, the system sets the expectation beside reality. In the example:

The first two checks are fine. The last two are not. The additional work was never invoiced, and in January the indexation was not applied.

Checks like these are rules you can write down. In addition, Revenue Intelligence looks for patterns that do not fit a rule. For example: this customer has had additional work every quarter and nothing has been invoiced this quarter. Or: customers of this type pay more per hour on average than this customer. That pattern recognition is a form of anomaly detection: looking at what deviates from normal, without having defined the error in advance.

Step 4: Act

A difference becomes a finding with four parts:

1. What is going on. 14 hours of additional work in June were not invoiced.
2. The evidence. The time entries from planning, the rate for additional work from the contract, the absence of an invoice line in AFAS.
3. The amount. EUR 1,190 one-off. For the indexation: at least EUR 60 a month, so at least EUR 720 a year, recurring.
4. The owner and the action. The project manager confirms the additional work, the finance team prepares the invoice. The account manager makes sure the indexation is included in the next monthly invoice.

Where it is responsible to do so, the action can be prepared: a draft invoice for the additional work, a task in the CRM for the indexation. Whatever goes to the customer is approved by a person.

The system then measures whether it has been resolved. Is the invoice for the additional work there? Was the rate adjusted in February? If not, the finding stays open.

Worked example: from one deal to the whole company

In the example, the amounts were EUR 1,190 one-off and at least EUR 720 a year recurring for one customer. That looks small.

Worked example: suppose the same installation company has 220 maintenance contracts. For 30 of them the indexation was not applied, on average EUR 50 a month. And for 25 customers there is on average EUR 1,500 a year of additional work that is not invoiced.

• Indexation: 30 x EUR 50 x 12 = EUR 18,000 a year, and it compounds every year.
• Additional work: 25 x EUR 1,500 = EUR 37,500 a year.
• Together: EUR 55,500 a year.

These are assumptions for the example, not averages. It shows how small differences per customer add up to an amount that does interest a board.

Why continuously and not once

A one-off check finds what has gone wrong. But the causes remain: the handover from planning to billing still runs through an email, the indexation is still not recorded as a date in any system. Next year the same leaks open again.

Continuous checking changes the dynamic. June's additional work is flagged in July, not in December or never. The indexation date arrives as a task in December, so the January invoice is right first time. The value shifts from recovering to preventing, and preventing is always cheaper, including for the customer relationship. A customer who receives an invoice for additional work in July finds that normal. A customer who receives an invoice in December for work done in January asks questions.

Where set-up goes wrong

Three pitfalls come up again and again:

• Starting with dashboards. A polished overview of data that is not connected only shows what you already knew. Start by connecting deals and invoices.
• Wanting everything at once. Start with the connection between CRM and billing. That is often where the largest differences are, as set out in revenue leakage between CRM and billing. Contracts, hours and usage come after.
• Not recording exceptions. A deal that was deliberately delivered free of charge is not a leak. If you do not record that, it comes back every month and everyone loses faith in the signals.

Step-by-step: walking the chain yourself

You can do the four steps by hand for part of your customer base. It is laborious, but it shows exactly what state your chain is in.

1. Choose twenty customers with a contract that has been running for more than a year.
2. For each customer, pull the deal from the CRM, the contract from the folder and all invoices from the last twelve months from the accounting system.
3. For each customer, write down what should have been invoiced according to the contract: amount per period, indexation, volume tiers, additional work.
4. Set that beside the actual invoices and note every difference with an amount.
5. Add it up and extrapolate cautiously to your whole customer base.

If you already find several differences among twenty customers, you know it is worth doing structurally.

Frequently asked questions

What is the hardest part of Revenue Intelligence?

Connecting records across systems. Without a reliable link between customer, deal, contract and invoice, you cannot compare anything meaningfully.

Do I need AI for Revenue Intelligence?

Not for the basics. Most checks are rules. AI helps with reading contracts, connecting messy data and finding deviations that do not fit a rule.

How often should the check run?

As often as your data changes. Daily is more than enough for most companies. Monthly is the minimum, so that leaks do not run for longer than one invoicing cycle.

What if my contracts exist only as PDFs?

Then the relevant terms have to be extracted from them: price, term, indexation, volume tiers, rate for additional work. That can be done with AI, followed by a check by a person. It is often the step with the biggest return, because those terms cannot be checked anywhere else.