Free in-page template

Customer master cleanup sheet, one decision per candidate pair.

A worksheet for finding the same real customer entered more than once: the candidate pair, the fields the two records disagree on, how you matched them, which record survives, what moves with it, and who decided. One pair is shown field by field, one is held, and one turns out not to be a duplicate at all. Copy it as CSV and work a pass.

Jump to the template All free templates

The template, filled with an example

The example is a fictional workshop with 1,148 customer records and 3 candidate pairs, carrying an as-on date of 4 October 2026. Three pairs were chosen to show three different decisions, not to suggest a ratio: one merged, one held for a person, one confirmed as two different companies. The figures for the merged pair are totalled in code, so the arithmetic on the page is the arithmetic you can check.

Illustrative example only. The business, every record ID, every company and contact name, every date, and every amount on this page are invented. No duplicate rate, no typical number of records per customer, and no benchmark of any kind is claimed anywhere on it. Nothing here is tax or compliance advice: a tax registration number appears only as one field that happens to differ between two records, and this page says nothing about what any rule requires of an invoice.

Customer master cleanup — illustrative exampleAs on 04-10-2026 · 1,148 records · 3 candidate pairs

Pass header

Worksheet: Customer master cleanup, first pass
As on: 04-10-2026
Business: Sample Furniture Workshop — Pune (example)
Master reviewed: Sample customer master, 1,148 records
Matching rules used: Same phone; same email; normalised name plus locality; same tax registration number
Candidate pairs found: 3 pairs from 1,148 records
Who reviews a flagged pair: A named person. The rules produce candidates; they do not produce decisions
Reviewed by: Sample Accounts Owner (example)
Pairs merged this pass: 1 — pair A
Pairs still open after this pass: 1 — pair B, held
Currency: INR

Candidate pairs and the decision on each

Customer master cleanup worksheet, illustrative example
Pair	Records compared	Fields that disagree	How we matched them	Record that survives	What moves with it	Decision	Decided by and when
Pair A	C-1041 “Sample Sunder Interiors”, created 12-06-2026, against C-1188 “Sample Sunder Interioors”, created 22-09-2026	Tax registration number — on one record only. Phone — on the other record only. Billing address — on one record only. And the name itself, by one transposed letter.	Same trading locality and the same first-line address on the two most recent invoices. The names match once normalised and sorted. The phone could not be used, because one record has no phone at all.	C-1188 — it holds the tax registration number, the billing address the invoices were raised against, and every invoice issued since 22-09-2026.	9 invoices and one payment re-pointed at C-1188; 12-06-2026 kept as the first-touch date; 2 open tasks carried; both note chains kept readable under the live record.	Merged. The older record is retired and left addressable, so the merge can be read back and explained if the customer disputes a balance.	Sample Accounts Owner (example), 04-10-2026
Pair B	C-0930 “Sample Kalyan Traders”, created 04-03-2026, against C-1211 “Sample Kalyan Trading Co”, created 29-09-2026	Tax registration number — different on the two records, and present on only one of them. Billing address. The trading name suffix.	The phone number is identical on both records. Nothing else agrees, and the two records carry different tax registration numbers.	No decision taken. Neither record has been changed.	Nothing has moved. The pair sits on the worksheet as an exception.	Held. A shared phone number alongside two different tax registration numbers is not something to merge from a screen, and a held pair costs minutes while a wrong merge costs months.	Not yet decided — Sample Accounts Owner (example) to confirm which company the second tax registration number belongs to, and whether these are one company or two
Pair C	C-1160 “Sample Prakash Hardware”, created 11-08-2026, against C-1204 “Sample Prakash Hardware and Electricals”, created 01-10-2026	Phone, billing address, locality, and tax registration number — different on all four.	A name token and the word Hardware. This is the pair a name-based rule puts at the top of its own list, which is exactly why the field-by-field pass exists.	Both records live. No change to either.	Nothing.	Not a duplicate. Two companies that share a name and a trade, left alone. The cost of leaving it is zero; the cost of merging it is a real customer's history.	Sample Accounts Owner (example), 04-10-2026

Three outcomes, and all three are correct answers. Merging is a decision a person makes, not a button: the rules find candidates, a named human decides, and a pair the rules cannot explain is held rather than resolved. A merge that loses invoice or payment history is worse than leaving the duplicate in place, because the duplicate is findable and the lost payment is not.

Pair A, field by field

Fields that differ between the two records of pair A, illustrative example
Field	C-1041	C-1188	Why the field matters
Trading name	Sample Sunder Interiors	Sample Sunder Interioors	One transposed letter. A name rule should treat this as a weak signal, not a verdict.
Created	12-06-2026	22-09-2026	Both dates survive: the earlier one becomes the first-touch date on the merged record, so the relationship is not recorded as three months younger than it is.
Contact person	Sample Contact A (example), named in full	S. Iyer (example), initials only	Both are kept as separate contacts. Neither is overwritten, and the abbreviated one is not treated as a different person.
Phone	On file (masked: +91 98xxx xxxxx)	None	Carried to the surviving record. This is the field the survivor was missing, and the reason a phone-only match could not decide the pair.
Tax registration number	None	On file (masked: 29XXXXX1234M1Z7)	Decides the survivor. The older record has nothing to contribute on this field, so choosing it would mean losing the one identifier the invoices were raised against.
Billing address	None — a delivery address only	On file	Invoices were raised against the surviving record's address. A merge that kept the other one would change the billing history without changing the documents.
Invoices	9 invoices, 3,64,500.00 billed, all settled	6 invoices, 2,17,300.00 billed, 1,36,000.00 settled	15 invoices and 5,81,800.00 of invoiced value in total, with 81,300.00 outstanding across the pair.

The two records disagree on four fields, and the disagreement is the evidence: the surviving record holds the tax registration number and the billing address the invoices were raised against, while the older record holds the phone and the earlier first contact. Together they carry 15 invoices worth 5,81,800.00 with 81,300.00 outstanding — and that outstanding figure was already correct in total before the merge, which is exactly the trap: the totals look fine, and it is the per-customer numbers that break.

What a merge must not lose

Issued invoices: Re-point the link to the surviving customer. Never rewrite the number, the date, the tax treatment, or the billing address on a document that has already been issued — those are the facts it was issued on.
Payments: Re-point them. A payment received against the discarded name is still money from that customer, and dropping it is the single most expensive merge bug there is.
Leads and opportunities: Keep the earliest created date as the first-touch date, and keep the union of the activity history rather than the newer record's version of it.
Open tasks and follow-ups: Carry both. Two open follow-ups on one customer is a state a person can resolve; a deleted commitment is gone, and nobody will ever know it existed.
Notes, contacts, and files: Keep both provenance chains readable under the live record, and keep the retired record addressable rather than deleting it.
Terms, tax registration, billing address: Take the surviving record's values, because choosing them is a decision somebody made. Never pick one silently, and never average the two.
The merge itself: Record it as an event with a timestamp and a named person. An unexplained merge is indistinguishable from data loss six months later.

Reading the pass

Candidate pairs reviewed: 3 pairs
Merged: 1 pair — C-1041 into C-1188
Held for a person to decide: 1 pair — C-0930 against C-1211
Confirmed not the same customer: 1 pair — C-1160 against C-1204
Invoices re-pointed by the merge: 15 invoices, ₹5,81,800.00 billed
Outstanding for this customer, before the merge: ₹81,300.00 — already correct in total, and split across two rows that a report could not join
Payment kept rather than discarded: 1 payment of ₹88,000.00, received 02-10-2026 against the record that was retired
Open tasks carried across: 2 tasks, both still open
Pairs left open: 1 — and one is the right number to leave

Customer master cleanup sheet as CSV — illustrative example data

Customer master cleanup sheet (CSV — illustrative example data)
As on 2026-10-04
Field,Value
Worksheet,"Customer master cleanup, first pass"
As on,04-10-2026
Business,Sample Furniture Workshop — Pune (example)
Master reviewed,"Sample customer master, 1,148 records"
Matching rules used,Same phone; same email; normalised name plus locality; same tax registration number
Candidate pairs found,"3 pairs from 1,148 records"
Who reviews a flagged pair,A named person. The rules produce candidates; they do not produce decisions
Reviewed by,Sample Accounts Owner (example)
Pairs merged this pass,1 — pair A
Pairs still open after this pass,"1 — pair B, held"
Currency,INR

Pair,Records compared,Fields that disagree,How we matched them,Record that survives,What moves with it,Decision,Decided by and when
Pair A,"C-1041 “Sample Sunder Interiors”, created 12-06-2026, against C-1188 “Sample Sunder Interioors”, created 22-09-2026","Tax registration number — on one record only. Phone — on the other record only. Billing address — on one record only. And the name itself, by one transposed letter.","Same trading locality and the same first-line address on the two most recent invoices. The names match once normalised and sorted. The phone could not be used, because one record has no phone at all.","C-1188 — it holds the tax registration number, the billing address the invoices were raised against, and every invoice issued since 22-09-2026.",9 invoices and one payment re-pointed at C-1188; 12-06-2026 kept as the first-touch date; 2 open tasks carried; both note chains kept readable under the live record.,"Merged. The older record is retired and left addressable, so the merge can be read back and explained if the customer disputes a balance.","Sample Accounts Owner (example), 04-10-2026"
Pair B,"C-0930 “Sample Kalyan Traders”, created 04-03-2026, against C-1211 “Sample Kalyan Trading Co”, created 29-09-2026","Tax registration number — different on the two records, and present on only one of them. Billing address. The trading name suffix.","The phone number is identical on both records. Nothing else agrees, and the two records carry different tax registration numbers.",No decision taken. Neither record has been changed.,Nothing has moved. The pair sits on the worksheet as an exception.,"Held. A shared phone number alongside two different tax registration numbers is not something to merge from a screen, and a held pair costs minutes while a wrong merge costs months.","Not yet decided — Sample Accounts Owner (example) to confirm which company the second tax registration number belongs to, and whether these are one company or two"
Pair C,"C-1160 “Sample Prakash Hardware”, created 11-08-2026, against C-1204 “Sample Prakash Hardware and Electricals”, created 01-10-2026","Phone, billing address, locality, and tax registration number — different on all four.","A name token and the word Hardware. This is the pair a name-based rule puts at the top of its own list, which is exactly why the field-by-field pass exists.",Both records live. No change to either.,Nothing.,"Not a duplicate. Two companies that share a name and a trade, left alone. The cost of leaving it is zero; the cost of merging it is a real customer's history.","Sample Accounts Owner (example), 04-10-2026"

Pair A field by field,C-1041,C-1188,Why the field matters
Trading name,Sample Sunder Interiors,Sample Sunder Interioors,"One transposed letter. A name rule should treat this as a weak signal, not a verdict."
Created,12-06-2026,22-09-2026,"Both dates survive: the earlier one becomes the first-touch date on the merged record, so the relationship is not recorded as three months younger than it is."
Contact person,"Sample Contact A (example), named in full","S. Iyer (example), initials only","Both are kept as separate contacts. Neither is overwritten, and the abbreviated one is not treated as a different person."
Phone,On file (masked: +91 98xxx xxxxx),None,"Carried to the surviving record. This is the field the survivor was missing, and the reason a phone-only match could not decide the pair."
Tax registration number,None,On file (masked: 29XXXXX1234M1Z7),"Decides the survivor. The older record has nothing to contribute on this field, so choosing it would mean losing the one identifier the invoices were raised against."
Billing address,None — a delivery address only,On file,Invoices were raised against the surviving record's address. A merge that kept the other one would change the billing history without changing the documents.
Invoices,"9 invoices, 3,64,500.00 billed, all settled","6 invoices, 2,17,300.00 billed, 1,36,000.00 settled","15 invoices and 5,81,800.00 of invoiced value in total, with 81,300.00 outstanding across the pair."

What a merge must not lose,Rule
Issued invoices,"Re-point the link to the surviving customer. Never rewrite the number, the date, the tax treatment, or the billing address on a document that has already been issued — those are the facts it was issued on."
Payments,"Re-point them. A payment received against the discarded name is still money from that customer, and dropping it is the single most expensive merge bug there is."
Leads and opportunities,"Keep the earliest created date as the first-touch date, and keep the union of the activity history rather than the newer record's version of it."
Open tasks and follow-ups,"Carry both. Two open follow-ups on one customer is a state a person can resolve; a deleted commitment is gone, and nobody will ever know it existed."
"Notes, contacts, and files","Keep both provenance chains readable under the live record, and keep the retired record addressable rather than deleting it."
"Terms, tax registration, billing address","Take the surviving record's values, because choosing them is a decision somebody made. Never pick one silently, and never average the two."
The merge itself,Record it as an event with a timestamp and a named person. An unexplained merge is indistinguishable from data loss six months later.

Reading,Value
Candidate pairs reviewed,3 pairs
Merged,1 pair — C-1041 into C-1188
Held for a person to decide,1 pair — C-0930 against C-1211
Confirmed not the same customer,1 pair — C-1160 against C-1204
Invoices re-pointed by the merge,"15 invoices, ₹5,81,800.00 billed"
"Outstanding for this customer, before the merge","₹81,300.00 — already correct in total, and split across two rows that a report could not join"
Payment kept rather than discarded,"1 payment of ₹88,000.00, received 02-10-2026 against the record that was retired"
Open tasks carried across,"2 tasks, both still open"
Pairs left open,1 — and one is the right number to leave

The reason the sheet is built around pairs rather than around a clean-up count is that a count is not a decision. Three pairs found, one merged, one held, one dismissed — the only figure worth reporting afterwards is the one still open, because that is the work that survived the pass. And the honest limit is worth restating: a cleanup pass reduces the number of duplicate records, it does not remove the condition, because “search before you create” leaves a race between two people and a residual gap for records created months apart.

How to fill it in

Four steps, and the third is the one most cleanups skip.

Fix the matching rules before the cleanup, not after

Write down what counts as a candidate: same phone, same email, normalised name plus locality, same tax registration number. These rules are a setup decision, because deciding in advance how a company, a contact, and a lead relate to each other determines most of what duplicate handling will do for you later.

Read each pair field by field, never name by name

The fields that disagree are the evidence, and they are the only thing that separates one customer from two. A pair that differs on a tax registration number or a billing address is not a pair to resolve quickly — it is a pair to hold. A pair that differs only by a spelling of the same name in the same locality is the one that is usually safe to act on.

Choose the survivor for a stated reason, and carry the rest across

Keep the record holding the current terms, then move deliberately: the earliest created date as the first-touch date, the missing phone, both note chains, and every open task. Write the reason in the row. A survivor picked because it was the newer record, or because it was the one already open on screen, is a decision nobody can defend later.

Re-point, never rewrite — and keep the retired record addressable

A merge is not a deletion. Issued documents stay as they were issued, payments are re-pointed rather than dropped, and the retired record is kept so the merge can be read back when a customer disputes a balance. Record the merge as an event with a timestamp and a named person, because an unexplained merge is indistinguishable from data loss six months afterwards.

When to use this, and when to stop

A first pass is the right size of job for a customer master that grew by being typed in twice. It stops being the right size when finding candidates has to happen continuously rather than once.

When this template is the right tool

The same real customer exists two or three times and the reports you rely on are quietly wrong in a way you cannot point at.
You are about to import a second source — an old ledger, a contact export, a bookkeeper's list — and want the overlaps resolved before anything enters the system.
You want a first pass that names who decides, so a cleanup does not depend on whoever opened the spreadsheet that morning.
You need to know which of your per-customer figures to trust: balance, ageing, credit position, and margin are the ones duplicates break.

When you have outgrown it

The customer master is being edited in a spreadsheet, and two people are working in it at the same time.
A collection list built from the most active row shows a customer as clear while an older row holds the genuinely overdue invoices.
Nobody can say which record is live, so a credit check reads whichever one the person happened to have open.
You need a merge to be safe enough to run unattended, which is a different and much larger requirement than finding the pairs.

The same process in NoxOrigin

Duplicate detection lives with the customer record rather than in a spreadsheet somebody remembers to open: the matching rules find candidate pairs and show the differences field by field before anything is changed. What it does not do is decide. A flagged pair is a claim for a named person to review, and where two records disagree in a way the rules cannot resolve — different tax registration numbers, materially different billing addresses, large open balances on both — the correct behaviour is to hold the pair as an exception rather than pick a winner, because the rules themselves are a setup decision and the asymmetry decides the design: a held pair costs minutes, a wrong merge costs months. One shared customer identity is also not a substitute for your own standard of what counts as the same customer, and a cleanup pass lowers the count without removing the condition.

Customer master cleanup questions

Why can the software not just merge them on its own?

Because matching rules can produce a shortlist and cannot produce a verdict. The rules can tell you two records share a phone, or a normalised name and a locality, or a tax registration number. They cannot tell you whether one company is the same company as another, because that is a business definition you own and no piece of software can supply it. A pair the rules flag is a claim to be reviewed, and a tool that resolved every pair it found would not have made the problem disappear — it would have moved it somewhere with no visible owner.

Which record should survive a merge?

The one that holds the current terms: the tax registration number, the billing address the invoices were actually raised against, and the contacts people still use. Then carry the rest across explicitly rather than assuming it follows — the earliest created date survives as the first-touch date, so the relationship is not recorded as younger than it is, and the other record's phone, notes, and open tasks come with it. Choosing a survivor is a judgement about the business, which is why the worksheet asks for the reason and not just the record ID.

Is “search before you create” enough to stop duplicates?

It is necessary and it is not sufficient, for three structural reasons rather than behavioural ones. Two people can search at the same instant and both find nothing, which is a race no procedure removes. Search is only as good as the fields being matched, and records are built from different artefacts — a call gives a name and a number, an invoice gives a name, an address, and a tax registration number but usually no phone, so the name is often the only field both share. And most duplicates are not created simultaneously at all: they appear weeks or months apart from a different artefact by a different person, and no rule prevents a decision made in September from disagreeing with one made in June.

What must a merge never do?

Three things, in order of how much they cost. Never discard a payment because it was allocated against the record that did not survive — that is deleted evidence that money arrived. Never rewrite an issued invoice to point at the surviving customer, numbers and all, because the number, the date, and the tax treatment are the facts it was issued on. And never delete the losing record's open follow-ups along with everything else, because two live follow-ups on one customer is a problem a person can solve and a deleted commitment is simply gone.

What should I do with a pair I am not sure about?

Leave it. The example holds pair B rather than merging it, because two records carrying different tax registration numbers is exactly the disagreement that a rule cannot resolve and a person might. A held pair costs a few minutes and leaves the business in the state it was already in; a wrong merge costs months and is usually discovered by a customer disputing a balance. The honest resting state for an unresolved pair is an exception with a name against it, not a decision made to clear the list.

Does finding no duplicates this month mean the problem is solved?

No, and it is worth being clear about why. A cleanup is a pass, not a repair: every way in that creates a record is also an opportunity to create a second one, so the count will not stay at zero on its own. The durable change is to make duplicate detection a standing query with a named owner, and to treat the matching rules as a setup decision you revisit rather than a setting you chose once. The worksheet is the first pass; the second one is the review that says the pass is still being run.

Find the candidates on the record. Decide the pair like a person.

If two records are quietly splitting one customer's balance, the totals will still look right for years. It is the per-customer figures that give it away.

Book a walkthrough Talk to NoxOrigin