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 explains 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 fifteen minutes to read.

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 the rest of this page is those rules.

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.

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 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-… and 012 … are three phone numbers to every automatic rule. So are Buyer.One@ and buyer.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 0123456789 does 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, and they cannot be used again
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.

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 sweep 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