Supplier Master-Data Change Control: Request, Approve and Audit Every Update

Do not edit an approved supplier record directly from an email, invoice or chat message. Open a change record first. Capture the current value, proposed value, reason, requester and supporting evidence; authenticate the request through an established channel; apply the right approval; let an authorised user implement it; then have another person read back the result before releasing it for purchasing, production, logistics or payment.

The minimum workflow is:

capture -> authenticate -> assess consequence -> approve or hold -> implement -> read back -> release -> monitor

A spelling correction and a new bank beneficiary are not equivalent changes. Nor are a renewed certificate and a new factory address. One change-control process should classify them, then route each to the evidence and authority its consequence requires.

Use one controlled change record before editing the supplier master

The supplier record is reused across purchase orders, invoices, payments, quality files, shipping documents and performance reports. A wrong field can therefore travel farther than the original request.

The Office of the Auditor General Western Australia's Supplier Master Files Better Practice Guide says a supplier master file should be an authoritative source for supplier information and subject to controls over creation, amendment and use. Its recommendations are written for WA public-sector entities. They are useful control design for an importer, but they are not presented here as legal duties imposed on every private business.

Start every proposed amendment with a unique change ID. Do not overwrite the current value while the request is being assessed. The record should show what is proposed, why, by whom, when it should take effect and which transactions or documents could be affected.

If the request cannot be authenticated, hold it. If it changes a field outside the requester's authority, hold it. If it would make an unapproved site, product or account usable, hold it at the relevant specialist gate.

Define the authoritative supplier record and its dependants

An authoritative supplier record is the approved reference for a defined field. It may live in an ERP, finance system, supplier portal or controlled register. The important point is not one software brand. It is that staff know which record controls each value and how approved changes propagate.

Map the dependants before changing anything:

Name an owner for each field family and an owner for the overall record. A duplicate spreadsheet owned by no one is not a dependable backup. It is another version that can drift.

The supplier onboarding checklist creates the initial controlled baseline. This article governs what happens after that baseline changes.

Classify the change by consequence

Classify before selecting evidence or approval. A practical model uses four levels; the labels and thresholds are OPL analysis and should be adapted to the business.

The class is based on consequence, not how small the text change looks. Changing one digit in a bank account can move cash. Changing one line in an address can point inspections at the wrong factory. Replacing a PDF can remove the scope page that made the old document relevant.

Capture the request without overwriting the current state

The WA OAG guide recommends documenting the requester, date, exact data fields, reason, authentication activity, supporting evidence and correspondence. Convert that into one record with these fields:

• change ID and request date;
• supplier ID, legal name and affected site;
• requester's name, position and channel;
• current value or document version;
• proposed value or version;
• reason and requested effective date;
• affected systems, open purchase orders, products and documents;
• evidence received and evidence still missing;
• verifier, approver, implementer and reviewer;
• decision, conditions and expiry or review trigger; and
• implementation timestamp and read-back result.

Preserve the before state. For a field, retain the old value in the audit record. For a document, retain the superseded version according to the business's approved retention policy and mark it so staff cannot mistake it for the current release.

Do not prescribe a universal retention period. Contracts, product rules, tax records, quality systems and privacy obligations can require different treatment. Assign the decision to the appropriate records, legal, finance or compliance owner.

Verify through an established independent channel

The person asking for the change is one evidence source, not the verification channel. Contact the supplier through details already validated in the approved record. Do not use a new phone number, email address or contact printed inside the request as the sole confirmation route.

The WA OAG guide applies that principle to supplier-master amendments. Cyber.gov.au's business email compromise guidance specifically recommends an approval process for payment-detail changes and a call to a known, verified number rather than one in the email.

For bank or beneficiary changes, stop this general workflow and use the dedicated supplier bank-change verification process. A successful callback does not by itself approve a payment; the full account, authority, documentation and payment-release gates still apply.

For a legal name or registration change, reopen the relevant identity evidence rather than editing a label to match the latest invoice. The Chinese business-licence verification guide explains how to confirm the registered counterparty without treating the licence as evidence of capacity or performance.

Record who performed verification, the established channel used, when it occurred and the result. Avoid copying unnecessary personal data into the change log; apply the organisation's access, privacy and retention controls.

Separate request, approval, implementation and review

One person should not be able to request, approve, implement and conceal a material supplier change without detection. The WA OAG guide recommends authorised access, independent approval, a second-person check and monitoring that is independent of master-data management.

NIST SP 800-171 Rev. 3 provides broader security-control principles: separation of duties, least privilege and audit records that identify the event, time, source, outcome and actor. This is transferable design guidance, not a claim that every Australian importer must comply with that US publication.

Assign these roles:

• Requester: states the change and supplies evidence.
• Verifier: authenticates source and evidence independently.
• Approver: accepts the commercial, financial, quality or compliance consequence within delegated authority.
• Implementer: has system permission to make the approved change only.
• Reviewer: compares the approved request with the saved result and affected outputs.

A small business may not have five people. It should still avoid one unobserved end-to-end path. A compensating control might use an owner-manager approval before implementation, a separate payment approver, a next-day change report review and system logs that the implementer cannot alter. Record the limitation and chosen control. Do not describe it as full segregation if it is not.

Review access periodically and when roles change. Remove unused administrator rights. Shared credentials destroy attribution and should not be used to solve a staffing problem.

Control supplier documents as versions, not attachments

A document folder can look complete while containing three certificates called final.pdf. Control the information needed to decide which document is current and what it applies to.

For each supplier document, record:

• document type and unique identifier;
• supplier, legal entity and site;
• product, process or service scope;
• issuer or source;
• issue, effective and expiry dates where applicable;
• revision or version;
• review and approval owner;
• status: proposed, under review, approved, expired, superseded, rejected or held;
• document superseded and reason for change; and
• linked purchase orders, products, controls or decisions.

ISO guidance on documented information for ISO 9001:2015 distinguishes maintained documents such as procedures and specifications from retained evidence such as external-provider evaluation and monitoring records. ISO 9001 is voluntary unless the organisation adopts it or a contract requires it. Possessing a document does not prove the supplier, site, process or product conforms.

Check the new document against the old one. Did the legal entity, site, scope, product family, standard edition, issuer, dates or exclusions change? If yes, route the consequence. A renewed certificate with a narrower scope is not merely a later expiry date.

Never delete the old version in a way that erases the decision trail. Mark it superseded and prevent operational use while preserving access for authorised review under the retention policy.

Release the change across systems without losing traceability

Approval is not completion. The saved supplier master, document register and dependent outputs must match the approved request.

Use a controlled release sequence:

1. freeze or flag affected transactions if the risk requires it;
2. implement only the approved fields or document version;
3. read back the saved value from the authoritative system;
4. generate a test output where useful, such as a draft purchase order or supplier statement;
5. update approved dependent systems through controlled interfaces;
6. tell procurement, finance, quality and logistics owners what changed and when;
7. obtain supplier acknowledgement where appropriate; and
8. close the request only after the read-back and dependency checks pass.

Do not re-key the same value into several systems without reconciliation. If integration is unavailable, maintain a dependency checklist with owner, completion time and evidence for each manual update.

The next purchase-order release should reference the approved supplier and commercial baseline. It must not inherit an unapproved term or site because one system updated earlier than another.

Worked example: one request, three different decisions

This example is fictional. The company, people, certificate and changes do not describe OPL or a client.

Pearl River Homewares Co., Ltd. sends one email asking an Australian importer to update a sales contact, replace an expired quality-management certificate and change the production address in the supplier record.

The address request is not rejected merely because it is risky. It is held because the general master-data workflow lacks the evidence and authority to approve a production-site change. Use the product change-control and supplier subcontracting gates to investigate before production release.

After those decisions, the supplier master should record the approved outcome. It should not lead it.

Monitor changes, duplicates and inactive suppliers

The WA OAG guide recommends monitoring amendments, approvals, accuracy, completeness, anomalies, access and user activity. It also recommends defined active/inactive criteria and records of why status changed.

Choose a review rhythm based on transaction volume and risk rather than copying a universal calendar. Useful checks include:

• changes with no request or approval ID;
• one user requesting, approving and implementing a sensitive change;
• bank, legal-name or site changes close to a payment or order;
• multiple suppliers sharing bank, contact or address data without an explained relationship;
• documents expired while the supplier remains approved for the affected scope;
• inactive suppliers still available for purchase orders or payment; and
• changes implemented in one system but missing from another.

A duplicate match is an investigation trigger, not proof of fraud. A shared address may be legitimate; an international supplier may not have an ABN. Preserve classifications and explanations so monitoring produces useful exceptions instead of noise.

When a supplier becomes inactive, block new operational use according to the approved policy while preserving the required transaction and decision history. Reactivation should be a controlled decision, not a switch flipped to process an urgent invoice.

Use a minimum viable change log

A spreadsheet can support a small operation if it is access-controlled, backed up, versioned and reviewed. It becomes weak when anyone can overwrite a row, approvals live only in email and there is no before-and-after evidence.

At minimum, report:

If the system cannot produce an immutable audit trail, export or preserve a controlled change report and have an independent owner review it. System sophistication does not replace control ownership; a workflow is only useful when exceptions stop release.

Finish with a reproducible release decision

Before closing a supplier change, another reviewer should be able to answer:

1. What exactly changed from which approved value or document?
2. How was the requester authenticated independently?
3. Which commercial, financial, product, site or compliance consequences were assessed?
4. Who approved and who implemented the change?
5. Does the authoritative record match the approval?
6. Were every dependent system and open transaction reconciled?

If the evidence answers all six, release the approved change and retain the trail. If any answer is missing, keep the request open or held. The objective is not a tidy supplier database. It is to prevent an unverified update from becoming an operational fact.