AI vendor master data review: a controlled change workflow

A supplier asks to change its bank account. The request arrives from a familiar-looking email address, the invoice is real, and the payment run is tomorrow. An AP analyst has to determine whether the request is legitimate, what evidence supports it, and who is authorized to approve the update.

That is not a document-extraction problem. It is a master-data change decision with a payment consequence.

An AI vendor master data review workflow can help assemble the current record, compare the proposed values, find related evidence, and prepare questions for a reviewer. It should not decide that a bank account is safe, write the new value into the ERP, or replace independent verification. The useful design is a review packet with explicit holds and human approval at the control boundary.

The Office of the Auditor General of Western Australia’s supplier master file guide describes the supplier master as the authoritative source for supplier information and recommends independent validation and approval before amendments. Microsoft’s Dynamics 365 documentation shows the same control pattern for protected bank-account fields: proposed values remain unavailable for use until the approval workflow is complete. These are control principles, not reasons to hand master-data authority to a model.

Start with the change decision, not the AI capability

The first question is not “Can a model read this supplier email?” It is “What must be true before this particular field changes?”

Write the decision in one sentence:

Approve, reject, hold, or escalate a requested supplier-record change after the request, proposed value, supporting evidence, and authority have been independently reviewed.

That sentence establishes a boundary between preparation and approval. The workflow may prepare a clear case. A named finance owner makes the decision and the system records the outcome.

This also prevents an overly broad project. Vendor master data includes fields with different consequences. A contact-name correction is not equivalent to a bank-account, remit-to, tax-identity, payment-method, or supplier-status change. Grouping them into one “vendor update” queue hides the control that matters.

Start with one high-consequence change type, such as bank details or remit-to information. Add lower-risk maintenance only after the review path is working and the ownership model is clear.

Build a complete change packet

An analyst should not have to reconstruct the case from an inbox, ERP screen, invoice attachment, and approval thread. Create one packet for each request with enough context to review the exact proposed change.

The packet should preserve original values and evidence. An AI-generated summary can be edited; the underlying request and source records should remain available. If the model misreads a document, the reviewer needs a way to see the discrepancy rather than only a polished conclusion.

Separate deterministic controls from AI assistance

Use rules for boundaries that should not depend on a model’s interpretation. Use AI where the work is primarily retrieval, comparison, explanation, or drafting.

Keep these checks deterministic

• Is the supplier active, unique, and linked to the expected legal entity?
• Is the requested field protected by policy?
• Are required fields and documents present?
• Does the proposed value meet the field’s format and validation rules?
• Is the requester allowed to submit the change?
• Is the approver different from the requester and authorized for this supplier or field?
• Has the request been held when evidence is missing or an approval is pending?
• Is the new value blocked from payment use until the workflow completes?

These checks can still route work to a human. “Pass” means the request satisfied a defined condition; it does not mean the supplier’s claim is true.

Use AI around the exception work

AI is useful when the reviewer must make sense of several records and documents:

• summarize the request and identify exactly which fields changed;
• compare the proposed value with the current record and recent history;
• find likely duplicate suppliers or related bank, address, tax, and contact values;
• point out contradictions between the request and approved records;
• identify missing evidence and draft a focused follow-up question;
• assemble a chronological view of prior changes, invoices, holds, and approvals;
• draft a reviewer packet that links each claim to its source.

The output should use labels such as “observed,” “conflicting,” “not found,” and “requires verification.” A fluent explanation is not evidence. Do not convert a model confidence score into an approval threshold for a payment-impacting change.

Treat bank and remit-to changes as a separate lane

A bank-detail request deserves more than the ordinary vendor-maintenance path because a legitimate invoice can still direct payment to the wrong account. The Western Australia guide specifically recommends confirming a change through a previously established communication channel, not a contact detail supplied in the amendment request or a recent invoice. It also recommends independent validation and approval by a separate employee before updating supplier bank details.

Design the high-risk lane with an explicit hold:

1. Capture the request and freeze the current value.
2. Mark the field as payment-impacting.
3. Compare the proposed value with the current record and recent change history.
4. Check duplicate and identity signals across the supplier master.
5. Ask the supplier owner or AP reviewer to perform independent verification using a known channel.
6. Route the packet to an authorized approver who did not request or make the change.
7. Keep the proposed value inactive until approval and required follow-up are recorded.
8. Confirm the effective value and preserve the complete change history.

The model can help with steps 3 and 4 and prepare the questions in step 5. It should not perform the independent verification by choosing a phone number or email address from the untrusted request. Nor should it release a payment because the evidence “looks consistent.”

Design the review queue around consequence

Not every exception needs the same route. A useful queue makes the reason for escalation visible.

The queue should show what is blocking the decision, not just an opaque “high risk” label. A reviewer needs to know whether the next action is to call a known supplier contact, resolve a duplicate, obtain a tax document, or ask a controller to approve.

This is where a permission-aware AI-agent design is relevant. The person who can inspect a supplier record should not automatically be able to change it, approve the change, and release the related payment. Keep read, propose, approve, and execute permissions separate, and bind any approval to the exact field values under review.

Test the workflow before connecting it to write-back

Start in read-only or shadow mode. The objective is to test the review process, not to demonstrate that a model can produce a plausible summary.

Use a representative sample of completed requests, including:

• ordinary contact changes that should pass;
• legitimate bank changes with complete independent verification;
• requests missing required evidence;
• duplicate or near-duplicate supplier records;
• changes submitted by an unauthorized requester;
• requests where the proposed document conflicts with the current record;
• urgent requests close to a payment run;
• changes that were rejected, canceled, or resubmitted.

For every case, compare the workflow with the recorded human disposition. Evaluate whether it:

• found the complete request and current record;
• identified the exact changed fields;
• preserved old and proposed values;
• surfaced the relevant conflict or missing evidence;
• routed the case to the right owner;
• refused to treat a missing check as a pass;
• kept proposed values out of the payment path before approval;
• produced a packet a reviewer could challenge and reuse.

Keep a production evaluation scorecard for these cases. Add failure examples to the test set rather than silently correcting the output and moving on. For an additional control perspective, the data-quality control plan explains when a workflow should block, warn, degrade, or quarantine instead of proceeding.

Measure control quality, not just review speed

A faster queue is not necessarily a safer queue. Track measures that reveal whether the process is becoming more reliable:

• percentage of requests with complete provenance and required evidence;
• percentage of payment-impacting changes independently verified before approval;
• duplicate candidates found and resolved;
• requests held for missing, conflicting, or stale evidence;
• separation-of-duties conflicts detected;
• reviewer corrections to the AI-prepared packet;
• changes approved, rejected, canceled, or resubmitted;
• post-change corrections and unauthorized-change investigations;
• time from request to a clear disposition, segmented by risk lane.

Do not claim that the workflow prevented fraud based only on clean historical cases. A better test is whether it reliably exposes the conditions that require a qualified reviewer to slow down, verify, or escalate.

A practical first implementation

For a controller or AP leader, the first version can be deliberately small:

1. Choose bank-account changes for one legal entity or supplier segment.
2. Document protected fields, evidence requirements, owners, and segregation-of-duties rules.
3. Export a closed sample of requests, current and proposed values, approvals, and outcomes.
4. Run deterministic checks and AI-assisted packet preparation without ERP write-back.
5. Have AP and the controller independently compare packets with the original cases.
6. Fix missing source context, routing gaps, and ambiguous policy before live use.
7. Introduce a human-approved queue with the proposed value inactive until approval.
8. Review corrections and exceptions after each payment cycle before expanding scope.

The right outcome is not an autonomous vendor editor. It is a repeatable review path that makes payment-impacting changes visible, verifiable, and accountable.

Jovis can be evaluated on one such workflow when the needed business context is approved and the decision boundary is explicit. Use it to assemble and investigate the records behind a vendor-change packet; keep verification, approval, ERP authority, and payment release with the accountable finance team.

Evaluate Jovis on one vendor-change review: test a governed investigation workflow.