How do you get a single source of truth for revenue?

You get a single source of truth for revenue by first agreeing which system leads for which figure, and then connecting and reconciling those systems so that every difference between them becomes visible and has an owner. The CRM leads for what was sold, the contract for what was agreed, the billing system or ERP for what was invoiced, and the accounts for what counts as revenue. A single source of truth does not mean one system. It means one agreed set of definitions and a continuous reconciliation between the sources.

Why is there no single truth about revenue?

Ask three people at a typical B2B company with EUR 10 million in revenue what last quarter's revenue was, and you get three answers. The sales director looks in the CRM and counts won deals. The financial controller looks in the accounts and counts booked revenue. The operations manager looks in the ERP and counts delivered orders. All three are right, within their own system.

That is not carelessness. Each system is built for a different purpose:

• The CRM (Salesforce, HubSpot, Pipedrive) is built to steer sales. It records expectations: opportunities, stages, deal values. A deal marked as won means the customer said yes, not that money is coming.
• The ERP (SAP, NetSuite, Dynamics, or in the Netherlands AFAS and Exact) is built to steer delivery and administration. It records orders, stock, projects, hours and invoices.
• The billing system, sometimes part of the ERP, sometimes a separate subscription platform, records what was charged.
• The accounts (Xero, NetSuite, Exact, Twinfield) record revenue under reporting rules: in which period each item of income counts.
• The bank records what came in.

Each system has its own definition of revenue, its own moment at which something counts, and its own keys for customers and products. Why the gap between the first two is so wide is covered in CRM vs ERP: where does your real revenue come from and why CRM data is not the same as financial data.

Four numbers that are all called revenue

Much of the confusion disappears once you accept that there is not one revenue figure, but at least four. All of them are useful, for different questions.

Between each pair there is a difference, and each difference has an expected and an unexpected component. A EUR 120,000 deal over twelve months is fully booked in January, invoiced and recognised at EUR 10,000, and perhaps collected at EUR 0. That is expected. A EUR 120,000 deal that has been invoiced at EUR 40,000 after six months is unexpected, unless there is a reason.

A single source of truth for revenue therefore means: for each of these four numbers you know where it comes from, and for each difference between them you know whether it is expected. What remains is where revenue is leaking.

Which source leads for what?

The first decision is not a technical one. It is an agreement: which system is the source of truth for which piece of data? Without that agreement every integration goes wrong, because nobody knows which system wins when two systems contradict each other.

A workable split for most B2B companies:

• Customer data for invoicing (legal entity, company registration number, billing address, VAT number): leads in the ERP or the accounts. That is where it has to be legally correct.
• Contacts and the commercial relationship: leads in the CRM.
• What was sold and for what value: leads in the CRM, up to the moment of won.
• What was agreed on price, term and conditions: leads in the contract, and after that in the system invoicing is run from.
• What was delivered: leads in the ERP, the time-tracking system or the product system.
• What was invoiced: leads in the billing system.
• What counts as revenue: leads in the accounts.

The most important principle: for each piece of data there is exactly one leading source, and every other system takes it over without changing it. A billing address changed in the CRM but not in the ERP is the start of a wrongly addressed invoice. The trade-offs per data item are worked out in which data source leads for revenue.

How do separate systems let revenue leak?

When each system has its own truth, gaps open up between the systems. Revenue disappears into those gaps without any one system doing anything wrong:

• A deal is marked as won in the CRM, but nobody passes it on to billing.
• An upgrade is sold, but the subscription in billing stays on the old package.
• A contract includes indexation, but it is not in the system invoicing runs from.
• Extra work is delivered and recorded in time tracking, but not recharged.
• A customer cancels a module with support, and billing either carries on or stops altogether.

Each of these leaks is a handover between two systems that did not happen. Nobody sees it, because nobody looks at both systems at once. Why silos cause leaks in exactly this way, and why more reports do not help, is explained in why silos cause revenue leakage.

The chain from first contact to money in the bank

Revenue does not arise in one system but in a chain of steps. That chain goes by different names, depending on where you start counting and which document is central. They all describe the same principle: a sales agreement has to turn into money received without loss along the way.

Which chain is central depends on your business model. A wholesaler thinks in orders, an installation company with maintenance contracts in contracts, a software company in subscriptions. Each chain has its own handovers and therefore its own leaks. Each is covered separately: lead-to-cash for the full journey, quote-to-cash for companies where the quote sets the price, order-to-cash for order flows, and contract-to-cash for recurring agreements.

For a single source of truth it does not matter which name you use. What counts is that you know the chain: which steps, which systems, which handovers, and who is responsible for each handover.

How do you connect the systems?

Once the agreements about sources are in place, the technology follows. Connecting means that data flows automatically from one system to another, or that a third system reads both. Two connections do most of the work for revenue.

CRM to billing

The connection between CRM and billing makes a won deal lead automatically to an invoice or a subscription. It closes the largest and most common gap: deals that are won and never invoiced. What to watch: which deal stage triggers invoicing, which fields are mandatory, and what happens when a deal changes after it is won. The options and pitfalls are set out in how to connect CRM to billing.

CRM to ERP

The connection between CRM and ERP goes further than invoicing. It synchronises customers, products, prices and orders, so that sales works with the same customer data and prices as the finance team. That connection is more complex, because the data models of CRM and ERP differ widely. A CRM thinks in accounts and deals, an ERP in debtors, items and orders. How to align the two, and why two-way synchronisation often creates more problems than it solves, is covered in how to connect CRM to ERP.

Sales and finance in one view

Connecting is not only about passing data along. The aim is for sales data and financial data to come together in one view: per customer you see what was sold, what was agreed, what was invoiced and what was paid. That requires shared keys (a customer number, contract number and order number that appear in every system) and shared definitions. How to build that without a large integration project is described in how to connect sales data with financial data.

How do you reconcile the sources?

Integrations reduce the number of differences, but never remove them completely. An integration can fail, someone can edit a record by hand, an exception does not fit the rule. That is why, alongside connecting, you need reconciliation: regularly checking that what sits in one system matches what sits in the other.

You know the principle from accounting: you reconcile the bank to the general ledger. For revenue, you reconcile the CRM to billing, and billing to the contracts. Every won deal should have an invoice, every invoice should belong to a deal or a contract, and every difference is explained or resolved. How that works, which differences to expect and how to assess them is explained in CRM-to-billing reconciliation explained.

The difference between a company with a single source of truth and one without often lies not in the systems but in this reconciliation. A company that reconciles monthly knows within a month where a difference sits. A company that never does finds out at year-end, or never.

Checking automatically

Manual reconciliation works up to a certain volume. With hundreds of deals a month and thousands of invoice lines, it turns into sampling. Automated checking means rules run continuously and only the exceptions are put in front of a person.

Two kinds of check complement each other:

• Checks on the CRM. Are the fields invoicing needs filled in? Are there won deals without a customer number, without a contract date, without product lines? Are there duplicate accounts? Checks like these stop an error in the CRM from flowing through to the invoice. See how to check CRM data automatically.
• Checks on billing. Does the price match the contract or the price list? Are there customers with an active contract and no invoice this month? Have discounts expired? Do quantities match usage? See how to check billing automatically.

Both checks only pay off if someone picks up the exceptions. A check that generates fifty alerts every night that nobody reads is worse than no check at all: it gives the impression that things are under control.

The architecture behind it

There are roughly three ways to set this up technically, and most companies use a combination.

1. Direct integrations between systems. The CRM talks directly to the ERP, the ERP to billing. Quick to build for two systems, but with five systems you have ten integrations that can each fail. Maintenance becomes the problem.
2. A central data store. Every system delivers data to a data warehouse, such as Snowflake, where it is combined. Reports in Power BI or a similar tool read from that warehouse. Powerful, but it needs someone to build and maintain the data model, and it only shows; it does not intervene.
3. A layer on top of the systems. A platform that reads the existing systems, links the records, calculates the differences and proposes what should happen. The systems remain the source of truth; the layer makes the connections. That is the approach RiOS is built on: it reads your CRM, billing and other systems and does not replace them.

Which architecture fits depends on the number of systems, the volume of data, in-house expertise and what you want to do with the result: only see, or also act. The choices and trade-offs are set out in revenue data architecture for B2B. Which data a system gets to see and how that is secured is a separate question for every architecture. For RiOS it is set out on the security page.

Worked example: what it costs not to have a single source of truth

Worked example: suppose you have EUR 12 million in revenue, a CRM, an ERP and a separate billing system for recurring services. There is no structural reconciliation.

Time. For every monthly report and every board meeting, the figures are pulled manually from three systems and pieced together. Suppose that takes two days of a controller's time and one day of a sales manager's time each month. That is 36 days a year, just to agree on the numbers.

Decisions. A forecast based on CRM data, with no reconciliation to billing, is structurally too optimistic if deals are marked as won that are never invoiced. Hiring and investment decisions are taken on a figure higher than reality.

Leakage. Suppose 1.5 percent of revenue leaks between the systems: won deals without an invoice, upgrades not carried through, extra work not recharged. That is EUR 180,000 a year. The range commonly cited for revenue leakage is 1 to 5 percent of revenue. That is a widely used estimate, not a fixed figure for your company. Whether you sit inside or outside that range you only know once you measure it.

The lost time is the visible part. The leakage is the invisible part, and usually the larger one.

Step-by-step plan: from three truths to one

This is an order that works, even without a large IT project.

Weeks 1 to 2: agree the definitions

1. Write down the four revenue numbers (booked, invoiced, recognised, collected) and the definition your company uses for each.
2. Record, for each data item, which system leads: customer, contract, price, delivery, invoice, revenue.
3. Agree which deal stage in the CRM means invoicing must follow.

Weeks 3 to 6: get the keys in order

4. Make sure every customer in the CRM has a customer number that also exists in the ERP or accounts.
5. Make sure every won deal refers to a contract or order number that appears on the invoice.
6. Clean up duplicate accounts, starting with the customers that bring in the most revenue.

Weeks 7 to 10: the first reconciliation

7. Set all won deals from the past year against all invoices. Flag deals without an invoice and invoices without a deal.
8. Have the account owner review every flagged deal. Record the reason.
9. Add up the uninvoiced revenue that comes out of it. That amount is your business case for the rest.

Week 11 onwards: make it structural

10. Run the reconciliation monthly, with an owner and a fixed date.
11. Automate the checks that are the same every month.
12. Integrate the systems where the reconciliation shows the most differences.

The order is deliberate: agreements first, then data, then reconciliation, and only then integration and automation. Start with integration and you automate the confusion.

What a single source of truth does not mean

Three misunderstandings that cost a lot of time:

• It does not mean one system. An ERP that also wants to be a CRM, or a CRM that also invoices, rarely solves the problem. It moves the gap between systems into a gap between modules. The question of which definition applies remains.
• It does not mean all the numbers are equal. Booked and invoiced revenue are never equal, and they do not need to be. What matters is that you can explain the difference.
• It does not mean it is finished. New products, new pricing models, a new system: every change needs a new agreement about sources and a new check. A single source of truth is a process, not a project.

Frequently asked questions

Which system should be the source of truth for revenue?

For the revenue that counts in your annual accounts, the accounting system. For what was sold, the CRM. For what was agreed, the contract. There is not one source for everything; there is one agreed source per data item.

Do I need a data warehouse?

Not to start with. The first reconciliation between CRM and billing can be done with two exports and a spreadsheet. A data warehouse becomes worthwhile when you have many systems, high volumes and people who can maintain it.

How long before the CRM and the accounts tell the same story?

The first reconciliation can be done within a few weeks. Making it structural, with keys in order, monthly reconciliation and automated checks, takes a few months. Exactly how long depends on the state of your data and the number of systems.

Who owns the single source of truth for revenue?

Someone who understands both sales and finance and has the authority to enforce agreements between the two. In larger companies a RevOps function or the CFO, in smaller ones often the finance director or the managing director. Without an owner, it falls back into three truths.

What is the first step I can take tomorrow?

Request an export of all won deals from last quarter from the CRM and all invoices for the same period from the accounts. Set them side by side for your ten largest customers. What you find there tells you how big the problem is.