Why Systems Show Different Numbers for Revenue

Your systems show different numbers because each one records a different event at a different moment: the CRM books a signature, the billing system books an invoice, the ledger books recognized revenue. Nothing is broken. Reconciling them for good requires a shared definition and a shared record of which customer is which.

TL;DR

Why do disconnected systems report different numbers?

You need last month's revenue for a board update. Salesforce says 1.42 million. Stripe says 1.31 million. QuickBooks says 1.27 million. Three systems, three answers, and a Tuesday afternoon spent deciding which one goes on the slide.

The instinct is to assume somebody made a mistake. Usually nobody did. Each system was bought to run one job, and each job has its own definition of the event worth counting. The CRM counts a closed opportunity on the day the signature lands. The payment processor counts money captured on the day the card clears. The accounting ledger counts revenue in the period the service was delivered, which may be six months of a twelve-month contract and nothing more.

Every one of those numbers is correct inside its own system. None of them is the answer to the question you asked, because the question spans all three and no system can see past its own edge. A company running 10 to 40 systems does not have one revenue number with two errors in it. It has three or four legitimate revenue definitions that were never written down in the same place.

This is the problem decision intelligence exists to solve: not making any single system more accurate, but making the systems agree on what they are counting and who they are counting it for.

Where do the numbers actually drift?

The drift is not random. It comes from five recurring causes, and once you can name which one is active, the argument stops being about who is wrong.

Two of these causes have their own walkthroughs: why your dashboards do not match covers the definition and refresh gap between two reports, and where did this number come from covers tracing a figure back to the rows that produced it.

Where the numbers drift

Cause	What happens	Which systems it shows up between	How a Knowledge Graph resolves it
Different definitions of revenue	One system counts contract value at signature, another counts cash collected, a third counts revenue recognized in the period of delivery	CRM and accounting ledger, most visibly Salesforce or HubSpot against QuickBooks, Xero or NetSuite	Each definition is stored as a named metric with its own rule, so booked, collected and recognized revenue are three labelled answers rather than one disputed figure
Timing and cut-off differences	An order placed on the 31st invoices on the 2nd, so the same sale lands in two different months depending on which system you ask	Order management or ecommerce against billing and accounting, for example Shopify against QuickBooks	Every record keeps its own event dates, and a question specifies which date drives the period, so the same month means the same window in every system
Duplicate customer records	One customer exists three times under slightly different names, so revenue per account and customer counts are both wrong	CRM against billing and support, for example HubSpot against Stripe and Zendesk	Entity resolution matches those records to one customer entity across systems, and every later question inherits that match
Currency and rounding	Multi-currency invoices convert at different rates on different dates, and per-line rounding compounds across thousands of rows	Billing and accounting, and any regional subsidiary ledger rolling into group reporting	Amounts stay in their original currency with the rate and date attached, so a converted total can be traced back to the rate that produced it
Manual spreadsheet edits	A figure is corrected in a spreadsheet, the source system is never updated, and next month the correction is gone	Any system against the spreadsheet the finance or operations team actually reports from	Spreadsheets connect as first-class sources, so the edited figure is visible next to the system value instead of living only on one laptop

Two of these five are worth dwelling on, because they cause the most damage and get the least attention.

Duplicate customer records quietly break every per-customer metric you own. Average revenue per account, retention, expansion, support cost to serve: all of them divide by a customer count that is inflated. Nobody notices until an account manager finds two open renewals for the same company.

Manual spreadsheet edits are the other one. Almost every mid-market company reports from a spreadsheet that holds corrections nobody pushed back into the source. That spreadsheet is a real system of record, and pretending otherwise is why the numbers reset every quarter.

How do you tell which number is right?

Stop asking which number is right and ask what each number is counting. In practice that means answering four things about any figure before you present it.

Which system produced it, down to the table or report
Which definition it uses: booked, invoiced, collected or recognized
Which date field drives the period, and where the month starts and ends
Which records were excluded, including test accounts, internal orders, refunds and credits
Who last edited it by hand, and whether that edit exists anywhere except a spreadsheet

A figure that can answer all five is defensible in a board meeting even if it disagrees with another figure, because the disagreement is now explained. A figure that cannot answer them is a guess with a decimal point.

This is also the fastest way to end a reconciliation argument. When the CRM number and the ledger number are both traced, the gap almost always resolves into one of the five causes above: a contract signed in March recognized across twelve months, or 40 duplicate accounts, or a cut-off that moved. The gap becomes a list of specific records rather than a suspicion about somebody's process.

What does it take to reconcile them for good?

Most companies reconcile the same three numbers every month by hand. Someone exports three reports, pastes them into a spreadsheet, matches customers by eye, and writes the difference at the bottom. It works, and it fixes exactly one month. The next month starts from zero, and the knowledge of which records matched leaves with whoever built the sheet.

A durable fix has four parts.

Read-only connections to every system that holds part of the answer, including the spreadsheets, so nothing is left out because it was inconvenient to export
One record of which customer, product, order or vendor in system A is the same as the one in system B, stored once and reused
Written definitions of each metric, so booked revenue and recognized revenue stop competing for the same word
A path from any presented number back to the rows that produced it, so a challenge takes a minute instead of a morning

Notice what is not on that list: moving all your data into a warehouse first, hiring a data engineer, or replacing any of the systems you already run. Warehouse projects are a legitimate path for companies with data teams, and /compare lays out how those platforms differ from this approach. For a 40-person company with no analyst, a six-month modelling project is not the fix for a question the CFO needs answered this week.

The reason the manual version does not stick is that the matching work is thrown away every cycle. Everything durable depends on storing that work somewhere both systems can read.

Doing that across a leadership team is its own exercise, laid out in how to get one set of numbers your team can trust. If the gap you keep hitting is between the CRM and the ledger specifically, AI that connects your CRM and accounting system and connecting Stripe and QuickBooks for one financial picture work through both pairs in detail.

How does a Knowledge Graph give one answer instead of five?

A Knowledge Graph stores your business as entities and the relationships between them rather than as separate tables in separate systems. The customer in the CRM, the payer in Stripe, the account in QuickBooks and the requester in Zendesk become one customer entity with four sources attached.

SIGNLD, a decision intelligence platform by Inzata Analytics, connects read-only to 800+ business systems and builds that graph automatically. Entity resolution runs on connect rather than waiting for someone to define a schema, so the matching work happens once and every later question inherits it. The /connectors list covers the accounting, CRM, billing, support and spreadsheet sources most of these disputes run through, and /how-it-works walks the path from a connected system to a returned answer.

For a one-off check between two exports of the same report, the free spreadsheet diff tool compares two CSV or Excel files in the browser and lists every row that changed.

Three things change once the graph exists.

Definitions live in one place. Booked, invoiced and recognized revenue are three named metrics with three rules, and a question that says revenue gets asked which one it means instead of silently picking a favorite.

Answers cite their sources. Every figure names the system, table and row it came from, so a disagreement gets settled by opening the evidence rather than by seniority.

The work compounds. Once the graph knows that Acme Corp, Acme Corporation and ACME Corp. are one customer, every future question about margin, retention or support cost uses that resolution without anyone rebuilding it.

Inference runs on a single-tenant AWS Bedrock instance, a private LLM powered by AWS Bedrock. Connections are read-only, your data stays yours, and we never train on it.

Three systems will still hold three figures, because they were built to count three different things. The difference is that you can state which is which, show where the gap comes from, and stop rebuilding the answer every month.

Key takeaways

Three systems reporting three revenue figures is usually a definition and timing problem, not a data-quality failure in any single system.
The five recurring causes are conflicting definitions, cut-off timing, duplicate customer records, currency and rounding, and manual spreadsheet edits.
A number is only defensible when you can name the system, the table, the date range and the filter that produced it.
Monthly manual reconciliation in a spreadsheet fixes one month and leaves the next month exactly as fragile.
A Knowledge Graph resolves the same customer across systems once, so every later question inherits that work instead of repeating it.

FAQ

Why does my CRM show different revenue than my accounting system?

Because they count different events. A CRM books revenue when an opportunity closes, using total contract value on the signature date. An accounting ledger recognizes revenue in the period the service is delivered, so a twelve-month contract signed in one month appears across twelve. Both figures are correct for their own purpose, and the gap between them is a definition difference rather than an error.

Which system should be the source of truth for revenue?

For reported financials, the accounting ledger, because it follows the recognition rules an auditor will test. For pipeline and forecasting, the CRM, because it holds the commitments the ledger has not seen yet. Rather than picking one winner, name each metric separately, booked versus recognized, and state which system owns each definition.

Do I need a data warehouse to make my systems agree?

No. A warehouse copies data into one place and still needs someone to model tables, join them and maintain the model as sources change. That is reasonable work for a company with data engineers. A Knowledge Graph approach resolves entities across the live systems instead, which is why companies with 10 to 500 employees and no data team usually get to an answer faster that way.

How long does it take to reconcile numbers across systems?

Manual monthly reconciliation across three systems typically consumes a full day of finance time and has to be repeated every close. Connecting a system to SIGNLD takes about 15 minutes, and the first answer comes back in minutes. The durable difference is that the entity matching persists, so the second month does not restart from an empty spreadsheet.

Will connecting my systems change any data inside them?

No. Connections are read-only, so nothing is written back to QuickBooks, Salesforce, Stripe or any other source. Data is encrypted with AES-256 at rest and TLS 1.2 or higher in transit, inference runs on a single-tenant AWS Bedrock instance, and we never train on your data.

What about the spreadsheets my team actually reports from?

Connect them. Spreadsheets hold corrections and allocations that never made it back into a source system, which makes them a real system of record whether or not anyone calls them that. Treating them as a source puts the manual figure next to the system figure, so the difference becomes visible instead of disappearing into one person's file.

Try SIGNLD free

Connect your accounting system and your CRM, ask for last month's revenue, and see where the two figures separate. Try SIGNLD free or browse all articles.

Why your business systems do not agree on the numbers