Investigate a supplier legal-name mismatch on an invoice

Treat the name difference as an identity question

An invoice can display a brand, shortened name, branch, former legal name, or an entirely different entity from the vendor account selected in the ERP. Preserve the invoice and record the displayed supplier name, address, registration or tax identifier when present, remit name, bank beneficiary name if visible under approved access, purchase order, buyer entity, and internal vendor account. Do not "correct" the source image or assume a familiar logo proves identity. Define the mismatch exactly, including spelling, suffix, address, and identifier differences, so the vendor owner can assess a concrete record.

Compare the invoice with the vendor master history, onboarding file, current tax documents, contract, purchase order, and earlier verified correspondence. Keep effective dates and entity scope visible. A trading name may legitimately appear on invoices while the legal entity remains unchanged. A merger or conversion may require a new vendor record rather than a name edit. A branch may share branding but use another registration. Similar addresses and contacts are supporting context, not enough to merge obligations. Record which controlled source supports each identity field and who owns that source.

Compare controlled records without collapsing entities

Search for duplicate or related vendor accounts using permitted fields. Look for exact identifiers, verified addresses, contract references, purchase orders, and documented parent relationships. Avoid broad searches that expose unrelated supplier data. If two accounts may represent the same entity, preserve both histories and route the comparison to vendor-master ownership. AP should not merge records, move open invoices, or reuse bank instructions simply because names resemble each other. Those actions can shift an obligation across legal entities and weaken payment controls.

Use an established supplier channel to clarify the invoice identity. A reply from the address that sent the mismatched invoice is not independent verification. Follow the company’s approved portal, known phone record, contract contact, or buyer relationship. Ask for the legal invoicing entity and supporting corrected document when needed. Keep the time, channel, person contacted, question, and response. If the request also changes bank, tax, or remit details, split those changes into their dedicated controls rather than treating the name clarification as authority for every field.

Verify changes through established channels

Check whether the mismatch originated inside the company. A purchase order may carry an outdated supplier name, the wrong vendor account may have been selected at intake, or an OCR process may have read the remit name as the legal name. Trace the captured field back to its source and retain the erroneous value with the correction. Do not silently edit extracted data until it agrees with master data. That would hide whether the invoice was wrong, capture failed, or the master needs approved maintenance. Each cause has a different owner and preventive action.

Build a decision packet that states the supported supplier identity, conflicting fields, affected buyer entity, open invoice amount, records checked, verification result, and action requested. Vendor-master or procurement owners decide whether to update an account, create a new one, reject the invoice, or request a corrected document. Tax or legal review may be needed under company policy. AP can hold and monitor the invoice while those decisions remain open. It should not bypass the mismatch with a one-time vendor or miscellaneous account merely to meet a due date.

Resolve the invoice and preserve the identity trail

After the owner decides, compare the approved identity with the final invoice and ERP document. Confirm vendor ID, legal name, buyer entity, order, currency, tax treatment, remit record, and approval path. If the supplier issues a corrected invoice, link it to the rejected version and check for duplicate entry. If master data changes, retain the prior value, effective date, approval, and system log. Verify that unrelated accounts under the same brand did not change. The final posting should point to the entity that actually made the supported demand.

Close the case with source documents, verification evidence, identity decision, correction, posting reference, and any open follow-up. Review mismatch cases by cause: trading name, company change, branch, capture error, buyer setup, or suspicious request. A useful outsourced process reports recurring sources without declaring fraud or corporate relationships from appearance. The reader outcome is a traceable answer to three questions: who invoiced the company, which internal account represents that entity, and who authorized any change needed to process the obligation.

Test identity controls with close variants

Use several realistic variants when reviewing the procedure: a trading name over the correct identifier, a missing corporate suffix, a branch with a different registration, a recent merger, and an invoice addressed to the wrong buyer entity. The expected action should differ for each case. The trading name may need documented acceptance, the branch may require another vendor record, and the wrong buyer may require a corrected invoice. If the workflow sends every variant to a simple master-name edit, it is not protecting entity identity.

Measure completion by evidence quality rather than the number of names standardized. A reviewer should see the invoice fields, verified supplier response, controlled identity sources, vendor-owner decision, effective date, and final posting account. Compare the new record with open invoices and payment data so a name correction does not strand prior obligations or redirect them. Recheck any account that shares branding with the changed supplier. This final review helps ensure that a legitimate clarification does not become an undocumented merge or payment-data change.

If payment timing becomes urgent, keep the hold reason and escalation visible. A rush request does not establish supplier identity. Send the authorized owner the complete comparison and due date, and record any approved exception with its limits. Never let an exception become a permanent vendor-master relationship without the normal onboarding and verification evidence.