Vendor Master Change Request Workflow

The problem this kills

Right now a change to a vendor record - a new remit-to address, different payment terms, a contact swap, putting a supplier on hold - probably happens through an email to "whoever has ERP access." There's no record of who asked, who approved, what the field looked like before, or why it changed. When AP pays the wrong account or an auditor asks "who moved this remit-to and when," you have a Slack-and-inbox archaeology project on your hands.

The dangerous part is that the riskiest changes (remit-to, payment terms, status) look identical to the harmless ones (a phone number) when they're just a line in an email. Nothing forces the high-risk changes to a higher level of scrutiny.

This tool kills that. Every change becomes a structured request with a visible field-level diff, the right approver for that field's sensitivity, and a permanent log entry. The same change can't be opened twice, and banking changes are deliberately pushed to your dedicated bank-verification process instead of being rubber-stamped here.

What you'll build

A small internal web app where:

• A requester picks a vendor, proposes a change to one or more fields, sees the old value to new value diff on screen, writes a reason, and attaches support (an email from the vendor, a signed form).
• The request routes automatically by field sensitivity - routine fields to a master-data approver, sensitive fields (remit-to, terms, status) to a higher approver.
• An approver reviews the diff and either approves or rejects. Only on approval is the change committed and versioned on the vendor record.
• Everyone gets the right email confirmation, and you get a CSV export of approved diffs in the exact column shape your ERP expects, plus an immutable change log you can hand to an auditor.

What's inside the Implementation Plan

• A discovery interview that runs first. Before it builds anything, the plan has the AI agent interview you about your real vendor process - your actual field names, your sensitivity rules, who approves what, your volumes, and your edge cases. It reflects a short spec back to you for a thumbs-up, so you get a tool tailored to your business, not a generic template.
• A copy-paste prompt for every build step - you never have to write code, you paste prompts.
• The full data model for vendors, change requests, field-level diffs, and the versioned history.
• Sensitivity-based routing, effective dates, duplicate guards, and the banking-change carve-out.
• The login, row-level security, audit log, and human approval gate wired in from the start.
• A no-integration fallback: load vendors from a Sheet/CSV and export approved changes as CSV.

The governance it includes (this is the point)

• Login so only your team can open or approve changes.
• Row-level security so each organization only ever sees its own vendors and requests.
• A complete audit trail - who requested, who approved, old value, new value, reason, timestamp - written to an append-only log.
• A hard human-in-the-loop approval gate: the requester drafts, the right approver reviews the diff, and only then is the change committed. Sensitive fields require a higher approver.
• Duplicate guards so the same vendor + field + requested value can't have two open requests at once.

Who it's for

Procurement and AP master-data owners who are accountable for supplier records and need to prove who changed which field and why. If you've ever had to explain a remit-to change to an auditor - or wished you could - this is for you.

You've got this. Open the plan, paste the first prompt, and let the agent interview you.