Two branches ask to onboard what appears to be a new supplier. One uses the trading name from a quotation; the other uses the legal name on an invoice. Meanwhile, a different company in the same group has nearly identical branding.
The first two requests may belong to one supplier record. The third may need to remain separate. A useful purchasing process resolves that identity question before creating another record, while keeping an explicit route for cases the available evidence cannot yet settle.
Duplicate records often begin as a practical response to a blocked purchase. The branch cannot find the existing supplier, needs a different ordering address or does not recognise the name finance uses. Creating another record appears faster than resolving the mismatch.
A clean-up exercise after payment can remove some duplicates, but it leaves that incentive intact. Examine the purchase request first. Can staff search by trading name, former name or approved alias? Can one supplier have several ordering locations without becoming several legal entities? Is there an owner who answers an ambiguous match promptly?
The process should make reuse easier when the identity is established. It should also allow a genuinely different entity to proceed without a long argument about similar branding. “We already have that supplier” is not a sufficient response if the existing record belongs to another company.
In a hypothetical case, two branches submit the same supplier on the same morning. Neither can see an approved record yet, so both requests appear to require a new one. Include pending requests in the intake check, using a shared identity reference and visible procurement owner. Link the second request to the first while the evidence is reviewed.
Immediately before creating the approved record, the owner checks again for another completed or pending match. This final check closes the gap between the initial search and approval. If the requests concern distinct entities, separate them with the evidence recorded. If the owner is absent or slow to respond, escalate to a named delegate rather than opening a parallel request. This is a recommended workflow that can be run with a simple controlled register; it does not depend on a particular application feature.
For Singapore entities, a UEN is a useful identity reference where applicable. ACRA's entity search supports checks of basic registration information, including status and registered address. That evidence helps establish which entity a quotation or invoice refers to.
GST registration is a separate attribute to verify. Some entities use their UEN as their GST registration number, but having a UEN does not itself establish GST registration. IRAS provides a GST-registered business search using identifiers including the business name, UEN or GST registration number.
Keep the tax-status evidence and its relevant dates in the supplier record. IRAS's tax-invoice requirements include the supplier's GST registration number. A number that looks plausible on an invoice is a reason to check the correct entity and status, rather than a reason to assume the record is complete.
Payment instructions require their own verification. A registry match does not prove ownership of a bank account or a contact's authority to change it. Resolving a duplicate supplier must not become an informal route to replace approved payment details.
CURIOUSRUBIK SINGAPORE / PURCHASING One entity. Distinct evidence questions. A UEN identifies the entity where relevant. GST status is checked separately; numbers may coincide. Legal entity Trading aliases Names staff search Ordering locations Operational attributes Registry evidence UEN where relevant GST status Checked and dated Payment instructions Independently verified PROPOSED IDENTITY MODEL · A REGISTRY MATCH DOES NOT CONFIRM PAYMENT AUTHORITY curiousrubik.com
A supplier-identity decision sheet should be short enough for procurement to use before approving a new record. Capture:
Allow three outcomes: reuse the verified entity record, create a distinct entity record, or hold the identity decision pending specific evidence. Forcing every request into “duplicate” or “new” encourages premature conclusions.
For a verified match, add a searchable alias or approved location where appropriate. The branch should be able to find the record using the name it actually encounters. Preserve the legal identity as the anchor so the alias does not replace it on contractual or accounting records.
For a distinct entity, record the relationship if useful, but keep its obligations, tax facts and payment instructions separate. Common ownership or branding is not a reason to combine legal counterparties.
In the hypothetical branch example, Request One uses a trading name and Request Two uses the legal name. The reviewer obtains consistent documentary support that both refer to the same registered entity. The purchase can use the existing approved record, with the trading name added as an alias.
Request Three comes from a related company with a different registration identity. Even though the logo, contact domain and group name resemble the first supplier, the contracting entity is different. It needs its own record and the relevant onboarding checks.
Now introduce a fourth request with an abbreviated name and an old invoice. The requester believes it is the same supplier but cannot explain a changed address. The reviewer should ask for current evidence rather than merge records based on familiarity. A move, reorganisation or simple data-entry mistake could explain the difference; the existing facts do not yet determine which.
Give this pending case an owner and response date. Procurement coordinates the information request, while the finance data steward controls the final record decision. The purchase owner should see the precise blocker and the escalation route. Otherwise, urgent work may drive them to create another record outside the controlled process.
CURIOUSRUBIK SINGAPORE / PURCHASING Catch the duplicate before creation Hypothetical workflow · Procurement owns the case; the finance data steward approves the decision. Branch A purchase request Branch B purchase request One pending identity case Stable reference + named owner Owner absent or overdue? Named delegate. Link Branch B to the same pending case. Evidence review, then final recheck: Check approved AND pending records immediately before the record decision. Same entity Reuse or make one authorised creation Distinct entities Separate records with evidence Uncertain Hold; request specific evidence HYPOTHETICAL PRE-CREATION CONTROL · UNCERTAIN MATCHES DO NOT AUTO-MERGE curiousrubik.com
Once the entity is verified, avoid repeatedly asking different branches for the same unchanged documents. Retain the check date, source and owner so the evidence can be reused intelligently.
Define events that require a fresh look: a legal-name change, a new contracting entity, a GST-status change, an inconsistent invoice or a request involving a different jurisdiction. A new delivery location may need an operational update without requiring a new legal supplier. The reviewer should distinguish the event rather than restarting all onboarding by default.
Overseas suppliers need an appropriate identity route for their jurisdiction and circumstances. A missing Singapore UEN should not automatically make a legitimate overseas entity invalid. Record the alternative registration or other reliable evidence used and route uncertain cases for review.
Some supplier relationships also involve individuals or personal information. Collect only what is necessary for the onboarding purpose and use the applicable privacy requirements and company controls. Do not request personal identity documents merely because the form contains an upload box. Where sensitive evidence is genuinely required, restrict access and obtain the appropriate review of its handling.
Finding an existing duplicate does not mean it is safe to merge immediately. Review open orders, invoices, credits, payments and reporting references associated with each record. Check whether the records truly represent the same legal entity and whether either contains an unresolved instruction change.
The data steward should decide the surviving record and how historical references will be preserved. In some cases, marking the duplicate inactive and redirecting future use may be safer than combining history. The appropriate method depends on the records and the system's capabilities.
Preserve an audit trail showing the decision, reviewer and mapping from the old record to the approved one. Test what happens to pending transactions before applying the change broadly. An apparently tidy supplier list is a poor outcome if it breaks the link between an old invoice and the entity that issued it.
Communicate the practical result to the branches. Tell staff which record to use and which aliases will find it. Without that feedback, the next employee may recreate the duplicate because the underlying search problem remains.
Automated matching can compare names, registration identifiers, addresses and established aliases. It can show a likely existing record at the moment someone requests a new supplier. That is more useful than sending finance a large duplicate list at the end of the quarter.
Show the reasons for the suggestion: exact identifier match, similar name, shared address or prior alias. Do not let a similarity score conceal conflicting evidence. A shared address may represent several legitimate entities, and a common contact may work across a group.
Keep ambiguous matches out of automatic merging. The reviewer needs access to the evidence and a way to record why apparently similar records remain separate. Those decisions can improve future suggestions without turning every prior decision into an unconditional rule.
Pilot the intake with two branches and a manageable supplier category. Track new records later found to be duplicates, verified records reused, ambiguous cases awaiting evidence and purchases delayed by identity questions.
Also sample records that the process kept separate. A low duplicate count is not a success if genuine entities were incorrectly combined. Review repeat causes: poor search aliases, slow ownership, incomplete requests or unclear rules for multiple locations.
Take five recent supplier-creation requests and ask whether staff could have found the right existing entity before submitting them. Improve that search and decision path first. Preventing the next duplicate is usually more useful than celebrating another clean-up of yesterday's list.
