Your ERP connection can work while a supplier change goes through the wrong approval path.
An AI agent working in a customised ERP needs to understand the operation as your business has configured it: which record it affects, what the fields mean, and which rules run when it is submitted. Access to a supplier record is only the beginning of that work.
Take a supplier bank-detail change. An agent could gather the request, check it for missing information, and prepare a proposal for authorised review. The useful result is a complete case submitted through the approved process, with evidence of exactly what the ERP recorded.
That scope gives the team something valuable to automate while keeping the decision to approve a consequential change with the people and system controls responsible for it.
Start with the operation your team actually performs
“Update supplier” is too broad to test. It could mean changing a contact, proposing new bank details, attaching a document, or changing which account is selected for use.
For this illustration, define the job as preparing and submitting a bank-detail change request for one identified supplier relationship. The agent records the resulting request reference on the original intake case. The ERP's configured approval process owns the subsequent decision.
Ask the application owner to demonstrate that operation under the account the workflow will use. Follow it from the intake case through the related supplier records and into the approval queue.
Look closely at what Save does. Does it retain a draft, write active fields, create proposed values, or trigger another process? Then establish what Submit does and how the team knows the request reached the intended review stage.
Oracle's supplier bank-account change documentation makes this distinction concrete: saving bank-account changes and submitting them for approval are separate steps. It also describes bank changes at supplier, address, and site levels, including configured descriptive flexfields.
A label on a screen can hide several different behaviours. Map the one this workflow needs.
Establish which supplier relationship is changing
The incoming request might use a trading name while the ERP stores a legal name. Several supplier records might be associated with the same group, and different sites may have different payment arrangements.
The agent needs an established link from the intake case to the intended ERP record. Use the organisation's authoritative identifiers and matching process. If that process leaves two plausible records, put the discrepancy in front of a reviewer.
Do the same for the level of the proposed change. A request for one supplier site should not silently become a change to every relationship with that supplier.
The implementation should make these relationships explicit:
| Part of the case | What the workflow must establish |
|---|---|
| Intake request | Which submitted request and supporting evidence are being reviewed |
| Supplier identity | Which authoritative supplier record the request concerns |
| Organisational scope | Which business unit, entity, or site is affected in this ERP |
| Bank-detail proposal | Which existing record or proposed new record the change concerns |
| Approval process | Which configured review path applies to this particular change |
These are questions to resolve against your configuration. They are not a universal ERP object model.
Preserve the record identifiers and the source of each relationship in the case. That lets a reviewer see how the proposed change was connected to the supplier, rather than trusting a generated summary of the match.
Learn what the custom fields mean
A mandatory field might record the reason for the change. Another might identify the team that completed supplier verification. A third might route the request to a regional approver.
Those fields need different treatment. The agent may be able to suggest a reason from the submitted request. A field asserting that verification is complete needs evidence from the business's approved verification process.
Document each field's allowed values, source, and authority. Identify which fields the agent may propose, which must be copied from an authoritative record, and which require an authorised person or service to set them.
If the field requires a verification reference and none exists, return the missing requirement. Filling it with plausible text would make the form look complete while losing the control the field was meant to provide.
Reading a bank document can help assemble the case. A document's presence, or an account number passing a format check, does not establish ownership or permission to change supplier details.
Your people define those verification requirements. The agent's job is to preserve the evidence and expose gaps so the reviewer can make the decision.
Test the approval path through the chosen interface
Don't assume an integration route behaves exactly like the screen a person uses.
Dynamics 365 Finance's vendor bank-account workflow documents separate configuration for web-client updates and data-entity imports. Depending on that configuration, imports can bypass approval, reject protected-field changes, or create proposals; creating proposals does not itself start the workflow.
That changes what you need to test. A successful import could be the wrong result for a job whose purpose is to prepare an approval request.
Choose an authorised route that preserves the required controls. Prove that protected active details remain unchanged during preparation and submission, and that the request enters the expected review process. Check for unrelated fields or side effects that the same operation could also save.
If the route cannot provide the required separation, let the agent prepare the case and keep submission with an authorised person. Resolve the operation's behaviour before granting broader write access.
The review path needs configuration too. Oracle's internal supplier profile approvals documentation describes feature opt-in and approval rules that the organisation must create. The presence of an approval feature does not establish the route a particular request will take.
Keep authority clear across the surrounding systems
The intake platform, document store, and ERP may grant different access to the same person or service account. Permission to read the request does not establish permission to read every supporting document or submit a supplier change.
Define the permitted operations in each system. For this job, the agent might read an assigned intake case, access its approved evidence, create a proposal in a limited ERP scope, and write the request reference back to the case.
Keep approval authority separate from that preparation role in the system configuration. The workflow should not gain approval rights simply because a general integration account happens to hold them.
Carry evidence references between systems where appropriate, with access checked for the reviewer. Avoid copying sensitive bank details into broad-access ticket comments or model context when a controlled reference is sufficient.
The application-map guide explains how operations and their prerequisites fit together. For an ERP change, permissions and record relationships determine whether those operations can be combined for this particular case.
Read back the proposal and the active record
After saving and submitting, inspect the resulting ERP state. An accepted request from the interface is not enough to show that the intended proposal was created.
Confirm the supplier and affected site or entity, the proposed fields, the evidence references, and the submission status. Compare the stored proposed values with the reviewed case through an authorised view. If masking prevents a necessary comparison, assign that check to someone or something with the required access.
Also confirm that the protected active details were not changed by this job. Read the proposed state and the active state separately so one cannot be mistaken for the other.
Finally, check that the intake case points to the correct ERP request and reports it as awaiting review. The agent should not tell the requester that their payment details are now active.
If submission times out, look for the existing proposal and its workflow state before trying again. If the ERP request exists but the intake update failed, retain that reference and finish the case update without creating another proposal.
The terminal result is specific: the correct change request is submitted for authorised review, the evidence is accessible, and the case identifies what remains pending.
Retest when the configuration changes
An ERP upgrade is one reason to revisit the operation. A new required field, revised approval group, or changed import setting can matter just as much.
Keep a small set of acceptance cases tied to the workflow. Include a valid proposal, a supplier-site mismatch, missing verification evidence, an account outside its allowed scope, and a submission that stops halfway.
Test an attempted change to protected active details from the preparation role too. The system should reject it or route it into the approved proposal process, according to the intended configuration.
Give configuration and policy changes named owners. The ERP owner confirms field and interface behaviour; the business owner confirms verification requirements and approval authority. They may be different people.
The test result should show what was saved, what was submitted, and what stayed unchanged. A report that the agent successfully called the ERP leaves those questions open.
Where Monarch fits
Monarch is the orchestration layer between agents and enterprise applications. Its Product Graph discovers accessible operations and their requirements, capturing verified behaviour within the connected account's scope. That can include public APIs, private web operations, and UI paths where available.
For a customised ERP, evaluate whether that application understanding helps establish the required proposal operation and coordinate the intake, evidence, and ERP records. Repeatable steps can be captured in deterministic code, with business verification and approval rules supplied by your people.
An existing service or integration may already preserve the right controls. Keep useful application logic and test the remaining work, especially custom fields, related records, and the exact result of submission.
Bring one supplier-change process, its field definitions, and the accounts it can use to a Monarch pilot discussion. The first proof should be a complete, correctly routed review case that your ERP and business owners can inspect.