Which system is the source of truth for revenue — CRM, billing, or ERP?
None of the three alone — each is authoritative for a different fact. CRM is authoritative for what was agreed to sell. Billing is authoritative for what was actually invoiced. The GL is authoritative for what's recognized as revenue under ASC 606, applied to what billing invoiced. When they disagree, the GL wins for reporting — but the disagreement itself is worth investigating.
By Zuny Fester, Head of Operations and MarketingPart of the finance integrations guide.
| CRM is authoritative for | What was agreed with the customer — deal terms, pricing, contract structure at the point of sale |
|---|---|
| Billing is authoritative for | What was actually invoiced — which can differ from the CRM deal if terms changed between close and invoicing |
| ERP/GL is authoritative for | What's recognized as revenue under ASC 606, applied to what billing actually invoiced |
| Why they can legitimately disagree | A CRM deal amount isn't necessarily the recognized revenue amount — SSP allocation, contract modifications, and recognition timing all sit between the two |
| For financial reporting purposes | The GL is the number that goes on the financial statements, full stop — CRM and billing feed it but don't override it |
Why this isn't actually a single-answer question
"Which system is the source of truth" assumes one system should win outright, but CRM, billing, and the ERP aren't competing to answer the same question — they're each authoritative for a different question entirely. A CRM's Opportunity record answers what the sales team agreed to sell the customer. A billing system's invoice answers what was actually charged. The ERP's general ledger answers what's allowed to be recognized as revenue under ASC 606, applied against what billing invoiced. Treating any one of the three as the universal answer to all three questions is where this actually goes wrong.
Why the CRM number and the recognized revenue number differ by design
A CRM deal amount reflects the negotiated contract value at close — it's a sales fact, not an accounting one. The path from that number to recognized revenue passes through several steps a CRM record doesn't model: allocating the total price across distinct performance obligations by standalone selling price, applying the recognition pattern each obligation calls for (ratable over a subscription term, point-in-time for a one-time item), and reflecting any contract modification that happened after the deal closed. A $120,000 CRM opportunity and its eventual recognized revenue over the contract's life are two different numbers, telling two different truths, by design — not because either system made an error.
Why billing sits between the two, and can itself drift from the CRM
Billing is meant to invoice what was actually agreed, but the gap between deal close and invoice generation is exactly where drift creeps in — a manual invoice adjustment, a billing-system default that doesn't match the CRM's negotiated term, or a renewal invoiced at list price when the CRM shows a negotiated discount that should have carried forward. Billing's own record is authoritative for what the customer was actually charged, even when that turns out to differ from what the CRM says was agreed — but that difference itself is worth catching, since it usually means either billing or the CRM needs correcting, not that one of them is simply "right" by default.
Why the GL wins for reporting, without making the other two irrelevant
For what actually appears on the financial statements, the GL's recognized revenue figure is the number that matters — that's simply what "revenue" means for reporting purposes under ASC 606. But that doesn't make the CRM or billing numbers irrelevant; a persistent, unexplained gap between CRM deal value and eventual recognized revenue for the same customer is a real signal something upstream needs attention, whether that's a billing configuration error, a modification that wasn't properly reflected, or a CRM record that was never updated after a renegotiation.
Next step
Map the finance workflow with the most exposure and prove the automation path.
Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.
Field mapping
The same $96,000 deal, three different numbers, all correct for what they answer
| System | What it shows | What question it's answering |
|---|---|---|
| CRM (Salesforce Opportunity) | $96,000 Closed Won, annual SaaS + $18,947 onboarding | What did sales agree to sell? |
| Billing system | One $114,947 invoice issued at contract start | What was the customer actually charged, and when? |
| ERP / GL | $18,947 recognized in month 1; $96,000 recognized at ~$8,000/month over 12 months | How much revenue is recognized, and in which period? |
None of the three numbers is wrong. The CRM correctly shows the full deal value at close. Billing correctly shows the full invoiced amount, issued as one transaction. The GL correctly spreads recognition across the periods ASC 606 actually calls for. A report that simply pulls "revenue" from the CRM's Closed Won total would overstate any single month's recognized revenue by treating the whole deal as if it recognized immediately — the GL's period-by-period figure is the one that belongs on the income statement.
Frequently Asked Questions
Sources
Related
Topic
Integrations
Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch…
Read moreHow-to
How do I map Salesforce Opportunity Amount for revenue recognition?
Loopfour's Salesforce integration reads Opportunity.Amount as a single lump total — Salesforce describes it as the estimated total sale amount, with no built-in recurring-vs-one-time split. To build a revenue recognition schedule from it, that split has to be captured elsewhere, such as a custom field, not assumed from Amount alone.
Read moreDiagnostic
What breaks when a Salesforce Opportunity can't distinguish recurring revenue?
A closed-won Opportunity's Amount is a single total with no field for recurring vs. one-time — unlike HubSpot's optional recurringbillingfrequency, Salesforce's base Opportunity has nowhere to put that distinction at all. Without a custom field added to carry it, every synced Opportunity defaults to one-time revenue, misclassifying any subscription or multi-year deal.
Read moreDiagnostic
How do I reconcile when my billing system and ERP disagree on invoice totals?
First check whether the gap is a real data mismatch or just a rounding convention difference — a common, benign cause. Some tax engines sum line amounts sharing a tax rate first, then round once; others round each line individually and sum the rounded results. The same invoice can legitimately total a cent differently under each method, which isn't a sync bug.
Read more