Duplicate Customer Codes in ERP: Merge Without Losing the Trail
Similar names are not enough
When one customer has two codes and receivables are split, deleting the apparently redundant code is not the starting point. Establish that both records represent the same counterparty, then use a supported merge process with verification. Different legal entities or branches deliberately separated for tax documents may need to remain distinct despite similar names.
Compare registered name, tax identifier, branch, billing and delivery addresses, and contact against reliable documents. A matching tax identifier helps but does not automatically remove a reason for separate branch records. The accounting data owner should decide whether to merge or simply correct names and link a customer group.
Define the surviving record and affected processes
Record both old codes, the surviving code, the reason for selecting it and the approved value of each field. Do not automatically prefer the newest address or payment terms without evidence. Inspect open orders, unapplied receipts, receivables reports and external systems that send customer codes: an online store still sending the old code may recreate the duplicate.
Microsoft states that Business Central merges cannot be undone and require MERGE DUPLICATES permission. These details are product-specific; check the documentation for other ERP versions. Backups support recovery, but restoring an entire system can affect other users’ later transactions. Agree a recovery plan with the administrator rather than treating backup availability as permission to proceed.
Test related records, not just the customer card
Test with a permission-controlled copy of the data. Record balances and references before the merge and compare the same reports afterwards. Suppose code A has THB 40,000 outstanding and code B has THB 10,000, with no new transactions during the test. The combined balance should be THB 50,000, but matching totals are insufficient: open invoices and receipt histories to confirm the original links are intact.
Business Central exposes differing fields and related-table record counts during the merge. Key conflicts require documented resolution before confirmation. Do not choose Remove Duplicate merely to dismiss a warning: it can delete a conflicting related record. A knowledgeable data owner must decide whether to retain, change a key or escalate, and test business-specific extensions and reports as well.
Set acceptance checks and prevent recurrence
Before production, obtain accounting and system-owner acceptance of the test and set a pause on affected customer changes. Afterwards check outstanding balances, open items, historical document retrieval and a new document using the master code. If history is missing or totals differ, stop dependent work, preserve the error evidence and follow the agreed correction or recovery plan. Do not post balancing entries to hide a merge failure.
Retain the old-to-master code map and change rationale under the data policy. Require a tax-identifier-and-branch search before customer creation and assign approval for ambiguous matches. For an accounting or ERP discussion with Chawinnix, bring appropriately minimised sample data, connected-system details and test findings so that the solution addresses the actual workflow, not merely a shorter customer list.
