How does AI work within Revenue Intelligence?

AI within Revenue Intelligence is not a single model, but a chain of different techniques: rules and statistics that find anomalies in revenue data, predictive models that estimate probabilities and amounts, language models that read contracts and notes and explain findings, and agents that prepare or carry out actions within fixed limits. The figure itself almost always comes from database queries and predictive models, not from a language model. Whether it works depends less on how clever the models are than on three things around them: which data they may see, how their output is checked, and who decides before anything changes in your systems.

Four kinds of AI in one system

The word AI is used for things that have little to do with one another. In a Revenue Intelligence system you encounter four, each with its own job.

Confusion arises when these four are mixed up. A language model is good with text, not with arithmetic. A predictive model is good with probabilities but cannot read a contract. A system that lets a language model come up with a revenue figure gives you a number that sounds convincing and rests on nothing. The difference between the two big families is explained in predictive AI vs generative AI.

What a Revenue Intelligence system is in the broader sense, apart from the AI, is covered in what is Revenue Intelligence. This article is about the AI underneath.

The chain, from source data to action

A well-built system works in layers. Each layer does one thing and passes its result to the next. That makes it verifiable: when something goes wrong, you can see in which layer. How such a structure fits together technically is worked out in AI architecture for Revenue Intelligence. Here I go through the layers from the point of view of what they do in practice.

1. Access: reading data from CRM, billing, ERP, contracts and support.
2. Connecting: linking the same customer, contract and order across different systems.
3. Finding anomalies: comparing what should be there with what is there.
4. Predicting: estimating what will happen.
5. Explaining and reading: understanding text and reporting findings in plain language.
6. Acting: preparing actions or, with permission, carrying them out.
7. Control: monitoring across all layers whether it is right.

Layer 1: access to the data

Everything starts with the question of what the AI may reach. A Revenue Intelligence system needs to be able to read deals, invoices, contracts and customer data. But whoever grants read access to a CRM also grants access to names, email addresses and notes about people.

Two principles determine whether that is safe. The first is least privilege: read-only access where reading is enough, only to the systems that are needed, through a connection that can be revoked per system. Why that weighs more heavily than the quality of the model is covered in how do you give AI access to business data.

The second is that personal data travels no further than necessary. To find a revenue leak, an AI model does not need to know that the contact person is called Jane Smith. It needs to know that customer K-1042 has a contract with an indexation clause. By replacing names, email addresses and other identifying data with tokens before anything reaches a model, the analysis remains possible without the model seeing the people. How that works is explained in how does tokenisation of business data work, and more broadly in how do you protect personal data in AI systems.

Layer 2: connecting systems

Revenue leakage almost never sits in a single system. It sits between systems: a deal in the CRM with no order in the ERP, a contract with an indexation clause that was never processed in billing, a licence expansion the account manager promised that appears on no invoice.

To see that, the system has to know that "Jansen Construction Ltd" in the CRM, "Jansen Constr." in the accounting system and debtor 20417 in billing are the same customer. That matching is less spectacular than a predictive model, but it is the work where most errors arise. A link that merges two customers who have nothing to do with each other, or splits one customer into three, makes every analysis after it worthless.

AI helps here in a modest way: it can suggest which records probably belong together, based on name, address, company registration number and transaction patterns. But a suggestion is not a link. The consequences of wrong or polluted data being used anyway are covered in what happens when AI uses the wrong business data.

Layer 3: finding anomalies

This is the layer where most revenue leaks are found. There are two ways to spot an anomaly.

Rules. You know what should be there and check whether it is. Every won deal should have an invoice within thirty days. Every contract with an indexation clause should have a higher price in January. Every hour of additional work in the timesheets should appear on an invoice. Rules are precise, explainable and find most of the known leaks.

Anomaly detection. You do not know exactly what can go wrong, but you know what normal looks like. A customer who has bought around EUR 12,000 every month for three years and has now been at EUR 7,000 for three months. A product group where the average discount in a quarter is suddenly four points higher. A model learns the normal pattern and reports what deviates from it. How that works and where it goes wrong is covered in what is anomaly detection.

In practice you need both. Rules find what you already know. Anomaly detection finds what you had not thought of. A system that runs on only one of the two misses half.

The most important work in this layer is translating an anomaly into an amount. "This customer pays 4 percent less than their contract says" is an observation. "This customer has been paying EUR 3,800 a year too little since January 2025" is a finding someone can act on.

Layer 4: predicting

Predictive models estimate what will happen: the probability that a deal closes and when, the probability that a customer leaves, next quarter's revenue with a range. They learn from your own history, and they are as good as that history. The general principle is explained in what is predictive analytics. Applied to revenue it is called forecasting, explained in AI revenue forecasting.

For Revenue Intelligence, the most important thing is that a prediction always comes with an uncertainty. A model that says "this customer has a 70 percent chance of leaving" without showing what that is based on gives you little to work with. A model that says "purchases have fallen for four months, there have been three escalations in support and the contract expires in March" gives you a conversation to have.

Layer 5: reading and explaining text

Language models have two jobs in a Revenue Intelligence system.

Reading what is not in fields. Contracts, quotes, notes in the CRM, emails containing agreements. An indexation clause is usually not a field in your ERP, but a sentence in a PDF. A language model can find that sentence and turn it into data a rule can check: annual indexation on 1 January, based on a published price index (for example the national consumer price index), capped at 5 percent.

Explaining what was found. A finding in plain language, with its source: which invoice, which contract, which deal. And an answer to a question such as "why did the forecast fall this week?"

How a language model gets to the right information is a technical choice with big consequences. For questions about figures, you want the system to query the database and return the exact answer, not a model searching documents for something that looks similar. For questions about text, such as contract terms, searching documents is the right route. That difference is explained in RAG vs database queries for business data. Searching text works with embeddings, explained in embeddings explained for business software.

A language model can only process a limited amount of text at once. What fits determines what it can see; what falls outside does not exist for the model. That is why you do not give a model "the whole CRM"; see context windows explained for AI systems. Every time a model processes something, it costs computing power and time; what that means for speed and cost is covered in inference explained. And the question of whether to train a model on your own data or let it look up the right information is dealt with in fine-tuning vs RAG for business software. For revenue data the answer is almost always: look up and query, do not train, because your data changes every day.

Layer 6: acting with agents

A finding that stays on a dashboard delivers nothing. Someone has to correct the invoice, call the customer, apply the indexation. Agents take over part of that work.

An agent is a language model with tools: it can look up an invoice, retrieve an order, create a task, prepare a draft. The model itself touches nothing; it asks the software around it to use a tool. What an agent is, is explained in what is an AI agent. How that request for a tool works technically is covered in what is tool calling.

In revenue operations the useful tasks are usually mundane: investigating an anomaly across three systems and summarising the findings, preparing a reminder to a late payer, updating a CRM record after a signed contract, moving support tickets from valuable accounts to the front of the queue. Applications and pitfalls are covered in what are AI agents in RevOps.

The safety of an agent lies not in the model, but in what the software around it is allowed to do. An agent that may read invoices but not send them cannot send an invoice out of the door, whatever the model thinks. The narrower the tools, the less that can go wrong.

Layer 7: control across everything

AI makes mistakes. Not often, if it is set up well, but in a way that is hard to see: a language model misreading a clause, a link confusing two customers, a model seeing a pattern that is coincidence. That is why every layer needs control.

Monitoring. Is a model's accuracy declining? Is the connection still reading all the data, or has a field gone missing since an update? Is an agent doing something it did not do before? See AI monitoring explained.

Checking output. A finding must be traceable to the source data: which invoice, which contract, which rule. A finding without a source cannot be checked and therefore cannot be trusted. Why that is not a formality is explained in why AI output must be checked.

Showing confidence. Every finding and every prediction should carry a confidence, and that confidence should prove correct afterwards. A system can also choose not to show a finding at all if the confidence is too low. How to judge whether such a confidence means anything is covered in how do you know whether an AI recommendation is reliable.

A person decides. The most important distinction in the whole system is between recommending and deciding. An AI that proposes correcting a customer's price is something different from an AI that does it. That difference is explained in AI recommendations vs AI decisions, and the way you keep people in the right places in the process in human-in-the-loop AI explained.

Worked example: one leak through the whole chain

Worked example: suppose you have 180 service contracts with an annual indexation clause. This is how one leak passes through the layers.

1. Access. The system reads the contracts from the document folder, the invoices from billing and the customers from the CRM. Names and contact details are replaced by tokens.
2. Reading. A language model extracts the indexation clause from each contract: percentage or index, date, cap. For twelve contracts the wording is unclear; those are flagged for a person rather than guessed.
3. Connecting. Each contract is linked to the correct debtor and the correct invoice lines.
4. Finding the anomaly. A rule compares the price on the January invoice with December's, per contract. For 23 contracts the price has not risen, although the clause required it.
5. Amount. Those 23 contracts have a combined annual value of EUR 460,000. With an indexation of 3.5 percent, the missed amount is EUR 16,100 a year, and because indexation compounds into every following year, after three years it is already close to EUR 50,000.
6. Confidence. For 19 contracts the clause is unambiguous and the anomaly certain. For 4 contracts there is an annex that may contain an exception. Those get a lower confidence.
7. Recommendation. The system proposes correcting the 19 certain cases and having the contract owner assess the 4 doubtful ones.
8. Action. After approval, an agent prepares the corrections in billing and a draft message to the customer. A person sends it.
9. Control. In February the system checks whether the new prices appear on the invoices.

The amounts are an example. The pattern shows why no single layer can do it alone: the language model read the contracts, the rule found the anomaly, the person decided, the agent did the work. More on this kind of leak in revenue leakage from missed price indexation.

What AI cannot do here

• See revenue that is recorded nowhere. Additional work agreed on site and never recorded does not exist for any system. AI can, however, flag that a project has noticeably little additional work compared with similar projects.
• Make up for polluted data. A model on bad data gives bad results with a convincing explanation. It can help find the pollution.
• Know what you agreed with a customer on the phone. The account manager knows this year's indexation was waived to secure a renewal. The system sees an anomaly. That is why a person decides.
• Take over responsibility. A system can propose, prepare and carry out what has been approved. The choice to send a customer a correction remains a business decision.

How to assess a system

Whether you choose a Revenue Intelligence platform, switch on a module in your CRM or build something yourself, these questions separate a usable system from a demo.

1. Which kind of AI does what? Does the revenue figure come from a database query or predictive model, or from a language model?
2. What can it reach, and with which rights? Read-only, or write as well? Under which account?
3. What does the model see of your customers? Is personal data replaced before anything reaches an AI model?
4. Is every finding traceable? Can you click through to the invoice, the contract, the deal?
5. Does it show a confidence, and does that hold? What happens to findings below the threshold?
6. Who decides? Which actions does it carry out itself, and which only after approval?
7. Is it monitored? Does the system notice by itself when a connection or model starts performing worse?
8. Is there a log? Can you see afterwards what it read, what it concluded and what it did?

How RiOS approaches this

RiOS, AutoMaat's platform that is currently in beta, is being built on a number of these principles. The read layer pulls data from your systems and does not write back on its own; automations only run after approval. A tokenisation layer strips out names, email addresses and other identifying data before anything reaches an AI model. Row-level security in the database determines who sees what, and a finding that does not clear the confidence threshold is not shown. That model is set out on the security page. The questions above apply to every system, this one included.

Frequently asked questions

Is Revenue Intelligence the same as a chatbot on your CRM?

No. A chatbot can answer questions about what is in the CRM. Revenue Intelligence connects several systems, actively looks for anomalies, puts an amount on them and makes sure something is done about them. A language model is one part of that.

Does the AI learn from my data?

Predictive models learn from your historical data, because that is how they recognise your patterns. In a well-designed system, language models are not trained on your data, but receive only the information needed for each question. Always ask a supplier how they handle this.

Can AI fix errors in invoices by itself?

Technically, an agent can prepare or carry out a correction. Whether that is wise depends on the action. Preparing a draft that a person sends is different from creating credit notes on its own. Start with proposing and preparing, and leave execution to people until the system has proven itself.

How do I know whether a finding is right?

By tracing it to the source. A good finding names the invoice, the contract and the rule it is based on, with a confidence. If you cannot see that, you cannot check it.

Do you need a data team to use this?

Not if the system already contains the connections, definitions and controls. You do need someone who assesses the findings and decides what happens with them. That is not data work, but business judgement.