Auditing Vendor Master Change Evidence

Research question and scope

This brief asks whether a vendor master change record contains enough evidence for an independent reviewer to understand what changed, who requested it, who approved it, and how the change was verified. The unit of analysis is a change event, not a vendor. A vendor may have several changes during the period, and each event should be reviewed on its own.

The scope includes changes to legal name, address, contact details, tax identifier, bank account, payment terms, and status. It excludes invoice-level exceptions and payment approvals, although the two areas interact. A bank change that is properly approved can still be part of a fraudulent payment attempt, so the audit should look for evidence of independent verification rather than treating approval as sufficient.

Define the population and sampling frame

Export the vendor master change log for a declared period. Record the query date, system, filters, and count. Decide whether the population includes all changes or only a subset, such as bank and tax identifier changes. If a subset is used, explain why and do not describe the result as covering the full population.

Stratify the sample by change type, risk tier, request channel, and approver. Include changes that were later reversed, because a reversal may reveal a control failure or a corrected error. Include changes with missing evidence rather than excluding them. The sample should be large enough to test the evidence dimensions and small enough to review against source documents.

Test evidence dimensions

For each change, test six dimensions: request identity, business rationale, supporting document, independent verification, approval authority, and post-change confirmation. Request identity asks who asked for the change and through which channel. Business rationale asks why the change is needed. Supporting document asks for the source that proves the new detail.

Independent verification is the dimension most often missing. A call to the vendor using a known number, a confirmation through an established portal, or a second approver can provide it. Record the method, the person, the date, and the result. Approval authority asks whether the approver was allowed to approve that change type and value. Post-change confirmation asks whether the new detail was actually applied and communicated.

Evaluate missing and conflicting evidence

A missing document is a finding, not a reason to drop the record. Report the missing dimension, the owner who should have provided it, and whether the change remained active. A conflicting record, such as an approval dated before the request, is also a finding. It may indicate a backdated approval, a system timestamp issue, or a mislabeled event.

Use a consistent rating for each dimension: present and sufficient, present but incomplete, missing, or conflicting. Do not collapse these into a single pass or fail without explaining the basis. The ratings should be reproducible by another reviewer using the same source records.

Protect independence

The reviewer should not audit changes they requested or approved. If independence is not possible, disclose the conflict and have a second reviewer examine the sample. The audit record should name the reviewer and any conflict. This is especially important for bank changes, where the person who requests the change may also have operational access.

Separate the audit from the remediation. The auditor can identify the gap and recommend a control, but the process owner decides how to fix it. Combining the two roles can pressure the reviewer to minimize findings or accept an incomplete fix.

Analyze patterns and limitations

Report findings by change type, channel, approver group, and evidence dimension. Look for patterns such as a channel with no independent verification or an approver group with incomplete documentation. Do not infer fraud from a pattern. The pattern identifies where to inspect further.

The audit cannot prove that all changes are valid. It can show whether the sampled changes have the required evidence and whether the control is operating as designed. State the sampling method, the confidence limits if used, the exclusions, and the records that could not be reviewed. A completeness audit is a structured look at evidence, not a guarantee.

Practical use

Use the findings to improve the change request form, the verification script, and the approver matrix. If the same dimension is missing repeatedly, the form or the workflow is probably the cause. A training reminder will not fix a process that does not capture the evidence in the first place.

Retain the sample, the ratings, and the remediation plan. Re-test the same dimensions after the fix. The second review should show whether the evidence improved, not only whether the form changed. That comparison is the useful output of the audit.

Method note

This brief presents an original audit design for local use. It does not report an audited population or a compliance conclusion. Public internal control, identity, and recordkeeping guidance informs the evidence dimensions. The design should be adapted to the organization's vendor master system, delegation policy, and risk assessment.

Common questions answered

Apply the research to your workflow

Bring one defined queue, its source records, current owners, approval boundary, and recurring exceptions. We can help turn that evidence into a focused support role.