What Joins Customer Records, and What a Merge Changes
This page explains the rules that create duplicate customers, what already ties the records together, and what a
merge changes that you cannot change back. You are here: it follows the four records on
Duplicate Customers, and the decisions and
Step 1 there lean on it. The example is the
same: a GadgetSphere buyer who gave +60 12-345 6789 to the web store, was created again at the GS-KV-03 till
under 0123456789, took a member card at GS-PEN-01 with 0123456789, and asked for her laptop’s e-invoice in her
employer’s name.
What joins the records — and when
When a customer is saved without an identity key, BigLedger looks for an existing key whose ID number, e-mail or phone equals what was typed. Any one field is enough, the comparison is exact (no trimming, no lower-casing, 012-345 6789 is not 0123456789), and if several keys match, the oldest wins. No match makes a new key.
A few minutes after a customer is saved, a background sweep looks at contacts with the same e-mail or phone. If it finds several, it moves all of them onto the oldest key and deletes the others, and points the customer records and member cards that carried those keys at the survivor. The same sweep runs when a member card is saved. The Contact keys page walks through both passes line by line, including the capital-letter e-mail that never matches.
When a member card is created, it looks for its customer: a customer linked to the same login first, then one with the same phone, then the same e-mail — and creates a new customer if none matches. That is how the walk-in record got its card: the card’s 0123456789 equalled the walk-in’s phone exactly, so the card joined it and not the web-store record.
When a customer file is imported, by default a row without a customer code is matched against every record you hold, suppliers and employees included, on ID number, tax registration number, SST number, e-mail and phone, and it overwrites the first record it finds. Importing Customers: What a Row Overwrites has the rules and the safe way to import.
When an e-invoice is prepared, the buyer is the document’s buyer block if somebody filled it, and the customer on the document otherwise — one or the other, never a mix.
When a contact-centre agent opens a conversation, the Contact Merging panel lets them attach it to a contact, customer, member card or login. That is a person choosing, not the system matching.
What never joins them
- A name. Nothing matches on name. Two customers with the same name are two customers until somebody decides otherwise — which is right, because a name is the weakest evidence there is.
- Two ways of writing the same thing.
+6012…,012-…and012 …are three phone numbers to every automatic rule. So areBuyer.One@andbuyer.one@to the sweep. - The identity key never merges records. It groups customers, contacts and cards under one person; it never turns two customers into one, never combines two cards’ points, and never moves an invoice. Two customer records on one key are still two statements.
- The till does not look at the key. The cashier’s search runs over customer records by name, code or phone. A key that already ties the web-store customer to
0123456789does not make that customer appear at the counter. - The e-invoice buyer is not the customer, on purpose. An employee buys a laptop and the e-invoice names the employer; a director pays at the counter and the company is the buyer. The buyer block exists so that the tax document can name the right party without changing who you billed. It is not a duplicate to clean up, and the employer should never be merged into the person.
- Two member cards never combine. Each card keeps its own balance. Nothing in the product merges cards.
What merges, and what never does
There is exactly one merge a person can run: Entity Merging on the Customer Maintenance applet (the Supplier applet has the same tool for suppliers). You pick one record to Keep as main and one or more to Merge and delete.
| A merge… | Details |
|---|---|
| re-points everything that referred to the merged-away records: sales and purchase documents — finalised, posted and in closed periods alike — and their journal lines, member cards, points history, contacts and identity links | The survivor’s statement and aging now include the merged-away record’s history. That is the point of merging, and it is also why merging, not editing documents one by one, is the right tool for duplicates that already have transactions |
| rewrites the stored copy of the customer on every document that names the survivor — the billing details, the delivery party, and the e-invoice buyer block | Old invoices reprint with the survivor’s details. A buyer block somebody completed by hand is rebuilt from the survivor too, whenever the buyer is the surviving customer. What LHDN already validated does not change |
| sets the merged-away records to INACTIVE | They are not deleted; they are set INACTIVE, so they drop out of the customer pickers — the server itself does not refuse a document that still names one |
| never copies anything across | A tax number, address, credit limit or e-invoice detail held only on a merged-away record stays only on it |
| never merges member cards | After the merge both cards point at the survivor, each with its own balance |
| never merges identity keys | The keys are tidied by the sweep the next time the surviving customer is saved |
| cannot be undone | BigLedger records how many references each merge changed, not which. There is no reverse |
Not every reference is followed: a few fields that hold a customer or employee under another name — the default sales agent on other records is the known one — keep pointing at the merged-away record. The Supplier applet carries the full warning.
The mistakes these rules lead to are on the guide’s first page, under Common mistakes.
Related documentation
- Duplicate Customers — the guide this page belongs to: deciding, merging and checking the result
- Importing Customers: What a Row Overwrites — the import-matching rules in full
- Contact keys — the identity key in detail: both matching passes, the key lookup, and a procedure for joining keys
- Supplier applet — Entity merging — the full reference for the merge and its limits
- My E-Invoice Admin applet — where the e-invoice buyer is completed or corrected