Duplicate Customers — Why One Person Appears Three Times

A customer tells the counter she has been buying from you for two years, and the counter finds nobody. Or the statement you send her shows half her invoices. Or her loyalty points are split across two cards. One person appears three times — and before anybody merges anything, it is worth knowing why BigLedger created three records, what (if anything) already ties them together, and what a merge will change that you cannot change back.

This page is for whoever looks after the customer list: it shows why the records exist, points you to how BigLedger recognises a person, and then hands you the part that is still a person’s job — deciding which records really are the same person, who may merge them, and how to check the result. About ten minutes to read, and ten more for the page on what joins and what merges.

Meet GadgetSphere

A buyer orders an ultraportable laptop from the GadgetSphere Online (GSO) web store and gives +60 12-345 6789 and Buyer.One@example.com. A month later she walks into GS-KV-03 for a charger; the cashier searches by 0123456789, finds nothing, and creates a new customer. At GS-PEN-01 she signs up for a member card with the same 0123456789. And the laptop was really for her employer, so she asks for the e-invoice in the employer’s name.

BigLedger now holds two customer records, one member card attached to the walk-in record, and one e-invoice whose buyer is a company — all for one person. None of that was a mistake by the software. Each record was created by a different route that followed its own rule, and What Joins Customer Records, and What a Merge Changes sets those rules out.

Cleaning up duplicates, at a glance

Find the candidates on Customer Maintenance → Entity Merging, searching every format of the phone number you know is in use (Step 1).
Decide each pair on evidence: the same ID number, registration number or login, or the same phone or e-mail confirmed by a document. A name is never enough, and when you are unsure, leave the duplicate (Step 2).
Copy onto the survivor what only the other record holds, and settle member-card points first. A merge copies nothing across (Step 3).
Merge outside trading hours, then watch Entity Merge Processing until it reads SUCCESSFUL. A merge cannot be undone, and the success message means only that it was queued (Step 4).

Steps 1 to 4 are all on this page. Why BigLedger made three records, and what a merge changes, are on What Joins Customer Records, and What a Merge Changes.

Four records, one person

Record	What it stands for	Created by
Customer	The account you bill and the ledger tracks. One record can serve the whole group — `GS`, `GSO` and `GSD` can all bill the same customer through Company Linking	The customer screen, the till, the web store and marketplace integrations, imports, and a member card that finds no customer
Contact	One sighting of a person from one source — a web sign-up, a marketplace order, an e-mail, a contact-centre conversation	Mostly automatic; see Contact keys
Member card	A loyalty membership and its points balance	The membership screens, the storefront, enrolment forms
E-invoice buyer	The party named as buyer on one e-invoice	The document, or whoever completes the buyer on My E-Invoice Admin

Behind the first three sits an identity key — a small record (phone, e-mail, ID number) that BigLedger uses to say “these are sightings of the same person”. The key is how customers, contacts and member cards find each other. It is not a customer, it has no ledger, and nothing you invoice ever points at it.

Read What Joins Customer Records, and What a Merge Changes before your first merge. It sets out what joins these records automatically and when, what never joins them, and what a merge rewrites — every document naming the merged-away record, posted or not — and what it never copies across. It also says what a merge leaves behind: a default sales agent still pointing at the merged-away record, and a record set inactive rather than deleted, which only the pickers hide — the server still accepts a new document that names it.

Your job: decide which records are the same person

The software links on any one matching field, because linking is cheap and never touches a ledger. A merge rewrites posted history. So the evidence you need before a merge is much stronger than the evidence BigLedger used to link, and weighing it is yours.

Three grades of evidence, strongest first:

Something only that person controls or was issued — the same MyKad or passport number, the same business registration number, the same sign-in login. Two records sharing one of these are almost certainly one party.
A matching attribute — the same phone or e-mail. Strong, but shared phones are common: a family number, a company switchboard, a till placeholder like 0000000000.
Something the person told you — “I’m already a customer”, a name, an address. Useful for finding candidates; never enough to merge on its own.

Merge on grade 1, or on grade 2 confirmed by a document (the same person signed both delivery orders, the payments came from one card). A name match is never enough — merging two different people puts one person’s invoices on another’s statement, and that is a privacy failure as well as an accounting one.

Do not merge a company and its director, a parent and a child sharing a phone, two branches of one business customer that you bill separately, or an employer who appears only as an e-invoice buyer.

Weigh what each mistake costs. A duplicate costs a split statement, a split loyalty balance, a message sent twice and an awkward “we have no record of you” — annoying, visible, and fixable at any time. A wrong merge costs another person’s history on this customer’s statement, forever. When unsure, leave the duplicate.

Your job: decide who merges, and when

The product has no approval step on a merge. Whoever holds the Entity Merging permission can merge any two customers. So the control is yours to build:

Give the permission to one or two people — whoever owns the customer list, usually in finance, not the counter.
Separate proposing from merging. Branch staff or the contact-centre team flag suspected duplicates; the list owner checks the evidence and merges. The flagging can be as simple as a shared sheet.
Merge outside trading hours. Nothing stops a cashier invoicing a record while the merge is rewriting it.
Keep your own merge log — survivor code, merged codes, the evidence, who, when. BigLedger keeps only counts, so your log is the only record of why two customers became one when an auditor, or the customer, asks.

Check your own data

This takes about twenty minutes for a first pass and ten minutes a week after that.

Before you start: you need access to Entity Merging and Entity Merge Processing on the Customer Maintenance applet (your administrator grants the merging permission), read access to customers’ statements, and — if you run a loyalty programme — the loyalty administrator on hand for Step 3. Agree with finance when merges may run; Step 4 belongs outside trading hours.

Step 1: Find the candidates

By the end of this step you have a short list of pairs worth checking.

Customer Maintenance → Entity Merging

Choose Entity Phone, type a number, and search. The search compares by similarity rather than exact match and returns up to 50 active customers; within the results, numbers that differ only in spaces, dashes and + are grouped together. A differently punctuated number can still fall below the similarity threshold, so search each format you know is in use — 0123456789, 012-345 6789, +60123456789. Lower the threshold (0.7 by default) if a record you know exists is missing; raise it if the list is noise. Repeat with Entity Email and Entity ID No, then with Entity Name for the names you were told about. A name group is a list of questions, not answers.

For GadgetSphere, searching 0123456789 finds the walk-in record; searching +60 12-345 6789 finds the web-store record. Two searches, one pair to check.

Where to look first: customers created at the till in the last month, and any phone that appears on many records — that is usually a placeholder, and those records are not one person.

Step 2: Decide with evidence

By the end of this step each pair is marked merge, leave or ask the customer.

Open both records. Compare the ID number, e-mail and login; then open each one’s Statement Of Account and Documents tabs and look for a document that proves one person — the same signature, the same card, the same delivery address. Record the decision and the evidence in your merge log, whichever way it goes.

Most common failure: merging on the phone alone when the phone is a household or company number. If the two records have different ID numbers, they are different people.

Step 3: Carry over what only the losing record holds

By the end of this step, the merge will lose nothing you need.

Pick the survivor — normally the record with the most history, or the one your integrations know by code. Then copy onto it anything only the other record has: tax identification number, e-invoice ID, addresses, credit limit and terms, the alert message. If both records have member cards, have the loyalty administrator move the points to the card being kept and set the other card inactive before you merge (Membership data management gives the order). If a document for the survivor carries an e-invoice buyer somebody completed by hand and it has not yet been submitted, note the document number — the merge rebuilds that buyer from the survivor, so whoever handles e-invoices re-checks it on My E-Invoice Admin the day after the merge, before it is submitted.

Step 4: Merge, and make sure it actually ran

By the end of this step the duplicate is inactive and its history belongs to the survivor.

Customer Maintenance → Entity Merging → select the group → Keep as main on the survivor, Merge and delete on the duplicate → confirm

The screen says Success Merging Entities as soon as the request is queued — not when the merge is done. Open Entity Merge Processing and watch the request move from IN_QUEUE through MERGING and DATA_REPLACING_IN_PROGRESS to SUCCESSFUL. A FAILED request shows its error on the row.

If the request is still IN_QUEUE the next day, nothing is going to run it — the merge job is not switched on for every company’s system. Ask BigLedger support to run or schedule it; do not queue the same merge again.

Then open the surviving customer and save it once without changes. That gives the background sweep (what joins the records) a chance to join the identity keys behind it, where they share a phone or e-mail.

What success looks like

Run these on the survivor the day after the merge. Two minutes.

Entity Merge Processing shows the request as SUCCESSFUL.
The merged-away customer shows INACTIVE on the customer listing.
The survivor’s Statement Of Account includes the invoices that used to be on the duplicate — pick one you noted in Step 2 and find it.
The survivor’s Membership tab shows one active card with the combined points (or the cards you meant to keep).
In each company, the survivor’s debtor aging equals the two old balances added together.

If check 3 or 5 fails, stop and contact support before anyone posts against either record.

Common mistakes

Mistake	What you see	Fix
Merging on a name match	Another person’s invoices on this customer’s statement	Irreversible. Prevent it: merge only on grade-1 evidence, or grade 2 confirmed by a document
Merging a household or company phone	Two people’s histories on one statement	Check ID numbers first; different IDs mean different people
Believing the success message	The duplicate is still active a week later	Check Entity Merge Processing; ask support if it stays `IN_QUEUE`
Merging before moving points	Two cards on the survivor, one balance nobody remembers	Move points and retire the card first
Merging the employer named as e-invoice buyer into the person	A company’s details on a personal account	Never merge the buyer; it is independent of the customer on purpose
Fixing duplicates by editing the customer on old documents one at a time	Slow, and easy to leave a document or a balance behind	Use Entity Merging, which moves documents and their journal lines together
Formats that differ by channel (`+6012…` online, `012…` at the till)	New duplicates every week	Agree one phone format and one lower-case e-mail rule for the group, and search by phone at the till before creating a customer