One supplier, many names: clean master data before integration

Begin with verifiable identity, not the typed display name

Define attributes that establish the supplier: legal name, tax identifier, country, primary address, verified bank account and confirmed contacts. Keep trading or short names as aliases rather than replacing the canonical identity.

ERPNext Supplier Master stores Supplier Name, Alias, Type, Group, Country, Company Bank Account, Payment Terms and linked contacts/addresses. The useful design idea is to separate how people refer to a supplier from the data used to transact with it.

References: [1]

Check several signals before creating a new supplier

Search name, tax ID, telephone, email, address and bank details before adding a record. Similar matches should enter a review queue rather than automatically creating another supplier, especially across Thai/English names or formatting differences.

Do not merge just because names match. Related companies or branches can use similar names while having different tax identities and bank accounts. A merge decision needs evidence and an accountable reviewer.

Decide which company or organisation may use the supplier

Within a group, one supplier can have different terms or payable settings by legal entity. Decide whether the system supports a shared supplier with company-specific settings or whether policy requires distinct records.

Supported ERPNext versions include Company Restrictions for Items, Customers and Suppliers so a master record can be limited to selected companies. This illustrates that “one supplier” does not mean every company should use every part of its data without boundaries.

References: [2]

Treat sensitive supplier fields as controlled changes

Bank details, payment terms, tax identity and active status deserve restricted amendment rights and a record of who changed what, when, why and using which evidence. A bank-detail change should not rely on an unverified chat message.

Define which changes after a Purchase Order or approval require renewed review. Supplier identity, bank details or terms may make the earlier approval no longer applicable to the transaction now being paid.

Preserve mapping from old IDs before migration or API integration

Create an old supplier ID → canonical supplier ID table with the merge reason and evidence. Do not erase old identifiers from source extracts because later reconciliation may need to establish which historical record a transaction referenced.

After migration, test spend, payable balances, invoice counts and price history by canonical supplier. A correct grand total can still conceal transactions assigned to the wrong supplier and therefore distort analysis or payment review.

Apply it to your business

Master data is not cosmetic reporting work. It gives purchasing, payment, price analysis and integrations a consistent and traceable counterparty identity.