One customer object
The CRM account, the ledger customer, and the billing subscriber resolved to a single identity with source identifiers retained, so cross-system questions stop needing a spreadsheet.
Services · integration
The CRM says the account is worth $840,000. The ledger says $612,000. Both are correct about different things — bookings against recognised revenue, one entity against a group, a renewal counted twice — and reconciling them is a recurring argument nobody wins.
Tell us your CRM and where it disagrees with finance. We will scope the reconciliation.
The situation
Accounts, opportunities, and closed-won deals joined to invoices, payments, and recognised revenue on a shared customer identity.
The CRM account, the ledger customer, and the billing subscriber resolved to a single identity with source identifiers retained, so cross-system questions stop needing a spreadsheet.
Sales sells to a group; finance invoices a subsidiary. Both views held on the same hierarchy rather than as two incompatible customer lists.
Closed-won value mapped to contract value, invoiced value, and recognised revenue, with the differences explained rather than argued about monthly.
Forecast joined to actual collection behaviour, which is how a forecast becomes a cash plan rather than a sales narrative.
A salesperson working a renewal can see the account is ninety days overdue, because it is the same object rather than a different system they never open.
Sales and marketing spend joined to the customers it produced, which requires both systems and is why almost nobody computes it honestly.
The disagreement is not usually a data problem. It is that sales and finance measure different things by design: bookings versus revenue, contract value versus invoiced value, the group versus the entity that signs.
Those differences are legitimate and they should be explainable. What is not acceptable is that explaining them takes a person two days a month, and that the explanation is rebuilt from scratch each time because nothing holds the mapping.
Nothing else works until the CRM account and the ledger customer are the same object. Matching runs across name, email domain, tax identifier, and billing address, and it proposes rather than merges — because an incorrect merge combines two companies’ balances and history and is worse than a duplicate.
In a typical mid-market stack, the initial match rate is around eighty percent, with the remainder needing a person. That is a week of work once, rather than a recurring reconciliation forever.
A salesperson negotiating a renewal without knowing the customer is significantly overdue is negotiating with one hand tied. Finance usually knows; the information simply does not reach the room, because it lives in a system sales does not open.
Putting exposure on the account record is the single change customers most often tell us changed a behaviour rather than a report.
Customer acquisition cost requires marketing spend from the ledger, attribution from the CRM, and customer identity joining them. Most companies compute it from one side and accept the resulting number because there is no practical alternative.
With both connected, the figure becomes computable by cohort and by channel. It is frequently worse than the internal assumption, and that is the point of measuring it.
Where to start
Export both customer lists and measure the overlap, the duplicates, and the unmatchable remainder. You get this figure in week one whether or not you proceed.
Automatic matching on strong signals, manual review for the rest, hierarchy established where a group structure exists.
Opportunities to contracts to invoices to payments to recognised revenue, with the definitional differences documented rather than smoothed over.
A standing bookings-to-revenue bridge that explains the gap every month automatically, replacing the spreadsheet that did it manually.
Questions
Send both customer lists. We will show you the overlap and the reconciliation you would get.