One Customer, Two Ids.

Here is a report every owner asks for in the first month after the sales system and the accounting system are connected: orders this quarter against invoices this quarter, by customer. It should be the easiest report in the company. Both numbers exist. Both systems are Zoho. The connection is on. And the report comes back wrong. One customer appears twice with half the orders on each row. Another has invoices and no orders. The totals are right and every row is wrong. This video is about why, and about the one decision that fixes it, which has nothing to do with the report.

Everything on screen is a mock demo of Zoho CRM, Zoho Books and Zoho Analytics with sample data. Six minutes, one key. Underneath, every cross-system report is the same operation. Take a table from one system, take a table from the other, and line them up on a key: a value that means the same customer in both. Then group and add. On this mock report in Zoho Analytics, the left table is deals from Zoho CRM and the right table is invoices from Zoho Books. The key the report is using is the customer name, because that is what both tables have.

Names are the worst key there is. Lakeshore Foods in the sales system is Lakeshore Foods Inc in the accounting system, because the finance team typed it from the purchase order. Same customer, two rows. Harbor Dental has invoices under a parent company name nobody in sales uses. Invoices, no orders. The report did exactly what it was told. The name key also drifts. A rebrand, a merger, a typo fixed on one side and not the other, and a customer that matched last quarter stops matching this one. A report that was right in March is wrong in June and nobody changed the report.

The fix is not in the report. It is one decision made upstream: which system issues the customer id, and how the other system receives it. Our rule is that the system where the customer first exists issues the id. For most companies that is Zoho CRM, because a customer is a prospect before it is an invoice. The account record gets an id when it is created. When the deal closes and the customer is created in Zoho Books, the connection carries that id into a field on the Zoho Books customer, and Zoho Books never issues its own.

One system issues. One system receives. The id is a field on both records, and it is the key every report uses from then on, instead of the name. The decision is easy for new customers. The work is the ones that already exist in both systems with no shared id, which is every customer you had before the connection. That is a one-time reconciliation: a list of accounts from the sales system and customers from the accounting system, matched by a person who knows the business, with the id written onto the accounting record for each match.

On this mock list of four hundred customers, three hundred and sixty match on the first pass, thirty need a human, and ten are duplicates in one system or the other that get merged. It is a week of someone's time, and companies skip it because the report is not due yet. Then the report is due, and the week is spent anyway, in a hurry, during the quarter close. The person doing the matching should be from finance or from sales, not from us. We prepare the list and the tooling; they know that Harbor Dental and Harbor Health Group are the same customer, and no amount of fuzzy matching knows that.

Same report, joined on the id instead of the name. Lakeshore Foods is one row: forty-eight thousand in orders, forty-six and a half in invoices, and now the gap is visible, which was the point. Harbor Dental is one row. The customer with invoices and no orders turns out to have had orders all along, under the id. Now the report says something. Which customers were invoiced less than they ordered. Which were invoiced before the order was recorded. Where the cash is stalling between the two systems, which is the question the whole program is about, and we have a separate video on the four handoffs where it stalls.

None of that was visible on the first report, not because the data was missing but because the two systems had never agreed who the customer was. The customer id is the first of these decisions and the most visible, but every connection carries one. The item id between the inventory system and the accounting system. The project id between the sales system and the project tool. The ticket id between the help desk and the sales record. Each is the same shape: one system issues, the other receives, the field is on both records, and the reconciliation of what already exists is done once.

A company that makes the decision for the customer and then forgets it for the item will have an inventory report that breaks the same way in six months. The reports are not the hard part of connecting systems. The keys are, and they are decided in the integration layer, before anyone opens Zoho Analytics. If your cross-system report has a customer on two rows, the report is fine. The key is missing. Decide which system issues the id, carry it across, reconcile what exists once, and the report you wanted is a group-by.

We are CodeStringers, a Zoho authorised consulting partner. The link below is a no-risk discovery: we read your connected systems and show you which keys were never aligned.