One identity
The CRM account, the ledger customer, the billing subscriber, and the support organisation resolve to a single object with the source identifiers retained on it.
Platform · front office
Most companies have the same customer four times: in the CRM, in the accounting system, in the billing platform, and in support. Each has a slightly different name, none is authoritative, and every question that spans two of them becomes a spreadsheet.
What it does
The CRM account, the ledger customer, the billing subscriber, and the support organisation resolve to a single object with the source identifiers retained on it.
Parent, subsidiary, division, and bill-to versus ship-to, so a group can be reported on as a whole while each entity keeps its own terms and balance.
Limit, current balance, unbilled work, and open orders in one place, visible at the point where a new order or quote is raised rather than in a report afterwards.
Quotes, orders, invoices, payments, credits, disputes, projects, and contracts on one timeline, sourced from whichever system holds each.
Fuzzy matching across name, domain, tax ID, and address, proposed for review rather than merged silently — a wrong merge is worse than a duplicate.
A portal user, a salesperson, and a controller each see a different subset of the same record, enforced in the data layer rather than in the interface.
Nobody set out to keep four customer lists. They accumulated because each system needed a customer record to function and none of them could reach the others. Sales created accounts, finance created customers, billing created subscribers, and support created organisations.
The cost is not the storage. It is that every cross-system question — what is this customer worth, what do they owe us, are we still profitable on them — requires somebody to reconcile four lists by hand, and that reconciliation is redone every time the question is asked.
Matching runs across name, email domain, tax identifier, billing address, and existing cross-references, and produces proposals with a confidence score and the evidence attached. High-confidence matches on an exact tax ID or domain can be configured to merge automatically; everything else waits for a person.
That conservatism is deliberate. An incorrect merge combines two companies’ balances, contracts, and history into one record, and unpicking it is materially harder than living with a duplicate for another week.
Credit exposure is usually knowable and almost never visible where it matters. The salesperson raising an order and the operations manager scheduling work rarely see that the customer is ninety days overdue on $180,000, because that lives in the accounting system they do not open.
Because the record is shared, the exposure appears on the quote and the order — as a warning or a hard block depending on your policy, with the override recorded either way.
Limits
This is a commercial master record, not a marketing profile with behavioural events and web activity. Those belong in a customer data platform.
If sales and finance disagree about who may change a customer name or terms, no master data system resolves that. The governance decision comes first.
Two subsidiaries with different names, no shared domain, and different addresses will not match automatically, and should not. Some merges will always be manual.
Questions
Two exports from two systems is enough to show you the overlap and the duplicate rate.