Key Takeaways
- Transformance’s AI agents read the ERP’s documentation and your setup answers, propose the field mapping, draft the workflow and the tests, run them in a test environment and report; a person signs every test.
- Every integration Transformance builds passes the same seven tests, in order: connection, single step, field mapping, full workflow on test data, volume, failure and retry, and re-run from the failed step.
- Each test has a pass criterion a finance owner can check, such as record counts, control totals and no second posting on a retry, and a named person who signs it off.
- Production is switched on only after all seven tests have passed and a person approves the switch; the ERP connection typically takes 2-3 days (Transformance customer data, 2026), and your IT team may be involved.
- After go-live, the Integration Monitor shows each job’s health and every failure in plain language with an owner and a retry; an ERP update re-runs the test plan first.
In This Article
- Key Takeaways
- How do AI agents build and test an ERP integration?
- What do the agents do, and what stays with people?
- Which tests does an ERP integration need, in which order?
- How do you test failure, duplicates and retries?
- What does the Integration Monitor show after go-live?
- What do you do when the ERP is upgraded?
How do AI agents build and test an ERP integration?
Transformance’s AI agents draft the workflow and the test cases from the confirmed field mapping and run them in a test environment; a person signs each test before production.
Integration test plan: seven tests, what each checks, the pass criterion, who signs
The seven tests are the integrations hub’s standard process. Transformance builds, runs, monitors and fixes the connection; your team approves access and every production change. Pass criteria are agreed with you before the first test runs; they are rules, not a benchmark.
Microsoft’s implementation guide for Dynamics 365 lists unit, functional, process, end-to-end, user acceptance, regression, performance and mock cutover tests, and names interface tests, “confirming that your interfaces work as intended”, as a type of their own (Microsoft Learn, 2026). The seven tests above break that interface test into steps a finance team can read and sign.
This plan tests the integration itself; your acceptance test of the whole AR process (user acceptance testing, parallel run, cutover) follows once it has passed.
Takeaway: an integration test without a pass criterion written first is a demo.
What do the agents do, and what stays with people?
Transformance’s agents do the repeatable work: reading documentation, proposing the mapping, drafting the workflow, running the tests and reporting; people confirm, sign and approve every change that reaches your systems.
The control design follows neutral guidance. OWASP’s guidance on excessive agency in AI systems recommends human-in-the-loop control “to require a human to approve high-impact actions before they are taken”, and limiting what an agent’s extensions can reach “to the minimum necessary” (OWASP Gen AI Security Project, LLM06:2025, 2025).
In the integrations hub, that looks like this:
- Least access. Every on-premise action is labeled read, write or execute, so IT approves exactly what a workflow may do.
- Test before production. The agents run the tests against a test environment, and a person activates the production run.
- Sign-off. Nothing posts to your ERP without human sign-off; administrators configure rules, finance approves, within thresholds by amount, entity and customer (approval thresholds for AI agents).
- Evidence. The audit log stores the timestamp, what the system did, what the user did, who approved, the input and the confidence.
The same process runs for every connection the hub builds (what an agent-run integration platform is).
Takeaway: the agents prepare and run; a person signs, and production waits for that signature.
Which tests does an ERP integration need, in which order?
Seven tests, in order: connection, single step, field mapping, full workflow on test data, volume, failure and retry, re-run from the failed step; each passes before the next starts.
The order follows the incremental logic of Microsoft’s test types, narrowed to the integration: the line, each step, the data, the whole run, the load, then the bad days.
1. Connection. The hub authenticates with the credentials held in its vault, reads one record and confirms it reached the test system, not production. Where the ERP uses OAuth 2.0, the connection uses a token your IT team has issued for it. For an on-premise ERP, the test runs through Transformance’s on-premise agent, which runs end to end today, connects outward only (no inbound firewall change, no VPN) and keeps credentials on site (routes for custom and legacy systems). A failing result: an authentication error, or a record from the wrong environment.
2. Single step. Each step runs alone on the workflow canvas with example input, and its response is compared with the documented example. A failing result: a missing field or an error code from the ERP.
3. Field mapping. Sample records are compared field by field: customer number, document number, amount, currency, due date, decimal separators and text length. A failing result: a truncated customer name, or a decimal comma read as a thousands separator, so 12,50 arrives as 1,250.
4. Full workflow on test data. Read, transform, write and confirm run end to end, and the ERP shows the expected open items or clearing postings (what is read and written, what a correct clearing looks like). Postings go through the ERP’s own interfaces (API, OData, BAPI or the ERP’s MCP server); direct database writes happen only where you explicitly agree. A failing result: an open item that stays open, or a posting on the wrong account.
5. Volume. A realistic load, such as a month-end bank file, runs in paced batches with live progress and counts of what changed. A failing result: a batch that times out, or counts that differ from the source.
6. Failure and retry. See the next section.
7. Re-run from the failed step. After a fix, only the remaining steps and records run. A failing result: records that were already written appear again in the ERP.
Three rules hold across all seven:
- Test data. Use realistic records from your own ERP, not only demo records. Microsoft notes that end-to-end testing needs migrated data, “which might have different data patterns than demo or test data” (Microsoft Learn, 2026). Where test records hold personal data, GDPR’s data-minimization principle applies: use only what the test needs and pseudonymize the rest.
- Environments. The same workflow points at a test system or a production system through its settings. Credentials and constants are kept per environment and per customer.
- Control totals. For every full-workflow test, the record count and the amount sum are compared between source and target. Illustrative: the source extract holds 1,240 open items worth $3,418,250.40; after the test the ERP shows 1,240 items and the same sum. One item or one cent off fails the test.
The route varies by system (API, OData, RFC / BAPI, the ERP’s own MCP server, files, a database, a mailbox, the on-premise agent or RPA); the seven tests stay the same.
Takeaway: each test answers one question, and the next test starts only when the answer is yes.
How do you test failure, duplicates and retries?
Break the integration on purpose, from a missing bank file to a duplicate document; the test passes when each case stops safely, names the failed records and posts nothing twice.
Microsoft’s guide says process testing “also includes negative testing, which looks for unexpected outcomes or errors in the process” (Microsoft Learn, 2026). For an AR integration, these are the eight cases to run:
The pass criterion, in words a finance owner can verify:
- Every failure lands in the exception queue with a plain-language reason and an owner.
- The retry processes only the failed records.
- Control totals still reconcile after the retry.
“No second posting on a retry” is a criterion this test proves for your integration, with your data, before go-live. The agents draft and run the eight cases; the controller and IT security sign the result. If a posting is reversed later, the audit log records what the system did and who approved it (audit trail for reversals).
Takeaway: test the day it goes wrong, not only the day it works.
What does the Integration Monitor show after go-live?
One place for every job: when each job last ran and last succeeded, failures in plain language with an owner, the failed records one by one, and a one-click retry.
Integration Monitor after go-live: what finance sees and does
It covers customer syncs, invoice postings, payment updates, email delivery and reminder runs. A generic API monitor tracks uptime; finance needs to know whether yesterday’s payments arrived and which records failed.
- Ownership. Each job has an owner and an escalation path; an interface inventory (source, target, direction, schedule, owner) is part of the go-live hand-over.
- The agent’s part. The agents draft the plain-language explanation of a failure; the owner decides what happens next. Transformance monitors the connections and fixes what breaks on its side.
- Hypercare. In the first weeks after go-live, review the exception queue daily (how long an AR automation rollout takes).
Takeaway: finance should learn about a failed sync from the monitor, not from missing payments.
What do you do when the ERP is upgraded?
Re-run the integration test plan in the test environment before the update reaches production, compare control totals, and approve the production switch only when every test passes again.
ERP update routine in 7 steps, with an owner for each
- Read the ERP vendor’s release notes for changes to the objects you use (owner: ERP owner).
- Refresh the test environment on the new release (owner: IT).
- Re-run the seven tests with the saved test data; the agents re-run the saved plan and report (owner: integration owner).
- Compare control totals and record counts with the last passing run (owner: finance owner).
- Fix and re-test what failed (owner: integration owner).
- Approve the production switch (owner: controller).
- Watch the first runs in the Integration Monitor (owner: finance owner).
For Dynamics 365 Finance & Operations, Microsoft publishes the calendar: four service updates a year (February, April, July and October), the designated user acceptance testing sandbox receives each update first, and customers have “seven calendar days to do testing and validation before the production environment is updated”. Breaking changes are announced 12 months in advance (Microsoft Learn, One Version service updates FAQ, 2026). Other ERPs publish their own release calendars, so check your vendor’s.
Microsoft also advises regression testing “before you introduce any change to your production environment”, and calls automation “key for regression testing” (Microsoft Learn, 2026). Keeping the test cases and test data from the first run makes that re-run repeatable.
A move from SAP ECC to SAP S/4HANA follows the same logic with a fuller plan (automate AR before or after an S/4HANA migration).
Takeaway: an ERP update is a change like any other: the test plan runs first.
Who Transformance is for
- ERPs: in production with customers on SAP S/4HANA (on-premises, private or public cloud) and SAP ECC, NetSuite (including OneWorld subsidiaries), Microsoft Dynamics 365 Finance & Operations and Business Central, and Odoo; Oracle and Infor supported; other ERPs through our integrations hub, each tested against your own data in a test environment.
- Size: mid-market to large enterprise, 250 to 2,000+ employees, including groups with several entities and shared service centers.
- Payment volume: from under 1,000 to over 100,000 payments a month.
- Industries: manufacturing, consumer goods and food and beverage, logistics, e-commerce, agriculture, energy and professional services.
- Scope: cash application alone, or the full order-to-cash (cash application, deductions, AR collections, cash forecasting).
Conclusion: the test plan is the gate to production
An ERP integration is ready when seven tests have passed against criteria written down first and signed. Transformance’s agents do the repeatable building and testing; people confirm the mapping, sign each test and approve production. After go-live, the monitor and the upgrade routine keep the plan working. Book a Call to walk through the test plan for your ERP.
Key terms
- Audit trail: who did what, when and on which input, for every run and approval.
- Journal entry: a general ledger posting, one of the records an integration writes back after approval.
- Payment reconciliation: matching incoming payments to the invoices they pay.
- Bank reconciliation: agreeing the bank statement with the bank account in the ledger, line by line.
- Straight-through processing: a transaction that runs start to finish without manual handling.
Related guides
- Which ERP systems does Transformance integrate with?
- What is an agent-run integration platform for finance?
- Can AR automation connect to a custom or legacy ERP?
- What does IT need to do when you roll out AR automation?
- How do you automate finance when every entity runs a different ERP?
- What AR automation reads from and writes to your ERP
- How external systems post payments and clear open items
Frequently Asked Questions
How do AI agents build and test an ERP integration?
Transformance’s AI agents draft the workflow and the tests from the confirmed field mapping and run the tests in a test environment; a person signs every test and approves the move to production.
Do tests run against our production ERP?
No. Tests run against a test environment, the same workflow points at production only through its settings, and a person activates the production run.
How long does it take?
The ERP connection typically takes 2-3 days for production ERPs (Transformance customer data, 2026), and your IT team may be involved; custom systems are agreed after a feasibility check. The full rollout takes up to 4-8 weeks (Transformance customer data, 2026), and the integration test plan is one part of it.
Which ERPs can you test against?
Your own ERP. Transformance runs in production with customers on SAP S/4HANA, SAP ECC, NetSuite, Dynamics 365 Finance & Operations and Business Central and Odoo, and supports Oracle and Infor. If a system has an API, a database, a file drop or a mailbox, it can be connected and tested the same way.
What happens when our ERP is upgraded?
You re-run the integration test plan in the test environment first, compare control totals with the last passing run, and approve the production switch only when every test passes again.
Does it work at 100,000 payments a month and across many entities?
Yes. Large loads run in paced batches with record-level error reporting, from under 1,000 to over 100,000 payments a month. Entities on different ERPs run in one Transformance environment with one worklist and one forecast (multi-ERP finance automation).
What does it cost?
It depends on scope and the number of entities and systems. Book a Call and we size it with you.
SAP, SAP S/4HANA, Microsoft, Dynamics 365, Business Central, Oracle, NetSuite, Odoo and Infor are trademarks of their respective owners (SAP SE, Microsoft Corporation, Oracle Corporation, Odoo S.A., Infor). Transformance is not affiliated with or endorsed by them.
