What does IT need to do when you roll out AR automation?

With Transformance, your IT team names a contact, creates a technical user, allows one outbound connection and approves access and production changes. Transformance builds and runs the ERP connection, which typically takes 2-3 days for production ERPs.
Single glowing fiber path through sequential glass gates, representing IT approval steps in AR automation deployment

Key Takeaways

  • Transformance builds, runs, monitors and fixes the ERP connection; your IT team approves access and every production change.
  • The ERP connection typically takes 2-3 days for production ERPs and a full rollout takes up to 4-8 weeks (Transformance customer data, 2026); approvals and change windows set the calendar more than the technical work.
  • With Transformance’s on-premise agent, IT makes no inbound firewall change and sets up no VPN: the agent connects outbound only, and credentials stay on site.
  • The technical user gets read rights for the entities in scope and write rights only for postings behind approval; nothing posts to the ERP without a person’s sign-off.
  • After go-live, IT sees every run, a plain-language failure queue with a retry, and a full audit trail.

In This Article

What does IT need to do when you roll out AR automation?

With Transformance, IT names a contact, creates a technical user, allows one outbound connection, approves the action list and access, and tests in a non-production system first.

The IT task list for an AR automation rollout: eleven tasks, why each is needed, what it involves, and who approves

TaskWhy it is neededWhat the task involvesWho approves
Name a technical contact and an approverSomeone answers network and access questions and can say yesOne person from IT and one from finance, named at kickoffIT lead and finance sponsor
Agree the connection routeThe method follows your environmentPick one: API, OData, RFC/BAPI and IDoc, the ERP’s MCP server, files or SFTP, database, middleware, SAP Cloud Connector, Azure app registration, on-premise agent or RPAERP owner and architecture
Create a technical user per environmentAgent actions stay apart from people’s actions in the ERP logOne non-personal user for test and one for production, each with a narrow roleERP security
Provide a host for the on-premise agent (or the Cloud Connector)It reaches systems the cloud cannot seeA server inside your network, installed with Transformance’s team and patched under your rulesInfrastructure and network
Allow one outbound connectionThe agent connects outward onlyOne outbound destination on the firewall; no inbound firewall change, no VPNNetwork and security
Keep credentials on site or in the secure vaultPasswords never travel by emailOn-premise passwords are entered and stored inside your network; others go into secure slotsSecurity
Approve the action listIT decides exactly what a workflow may doEvery on-premise action is labeled read, write or execute; IT signs off the listERP owner and security
Grant mailbox consentRemittances arrive by emailConsent for the remittance mailboxes in scope, nothing widerMail administrator
Connect the test system firstFirst tests run without touching productionA separate test connection and technical user; tests run on your own transactionsERP owner
Grant write rights for the postings in scopeClearing postings, journal entries and reversals need themWrite rights only for the postings in scope, used only behind approvalERP owner and finance
Run the security review and sign go-liveControls are checked and recorded before productionSSO/SAML, RBAC, audit trail, data region and sign-offs reviewed; the production switch is a recorded approvalSecurity, data protection and finance

The table lists tasks, not durations. Our times: the ERP connection typically takes 2-3 days for production ERPs, custom systems are agreed after the feasibility check, a proof of value runs 4-5 weeks on one entity, and a full rollout takes up to 4-8 weeks (Transformance customer data, 2026). Waiting for approvals and change windows comes on top. The connection is one step of the rollout (all ERPs Transformance connects to).

Who does what. Transformance builds, runs, monitors and fixes the connections. Its integration agents read your system documentation and setup answers, propose field mappings, draft workflows, run the test plan and report the results; a person approves every change that reaches your system or production (what an agent-run integration platform is). Your IT team owns identities, the network path, and the approval of access and production changes. Finance owns AR policy and approves postings.

Why IT is right to ask for control. Breaches involving a third party now account for 48% of all breaches, according to Verizon’s 2026 Data Breach Investigations Report (Verizon, 2026). An AI agent with an ERP user is third-party access, so IT should insist on its own technical user, narrow rights and an approval step. On the posting side, ClearMatch validates 100% of postings, and nothing posts without human sign-off (Transformance customer data, 2026).

Takeaway: IT’s list is short and concrete; Transformance does the connection work, and IT approves what it lets in.

‍

‍

In which order does IT get involved?

IT’s work comes in four phases: agree the route and owners, set up access and the network path, test in a non-production system, then approve go-live and monitoring.

‍

‍

  1. Route and owners. Name the contact and the approver, agree the connection route, and decide who owns network, ERP security and the mailbox.
  2. Access and network path. Create the technical users, provide the host, allow the one outbound connection, store credentials and approve the action list.
  3. Test. Connect the test system first and let the test plan run on your own transactions (how AI agents build and test an ERP integration).
  4. Go-live and after. Grant write rights for the postings in scope, run the security review, sign go-live, and agree who watches the failure queue.

The principle: read access on one entity first, recommendations next, postings with sign-off last (how AI agents access ERP data safely).

Most calendar time is waiting, not technical work: a change window, a security review slot, an approval round. The onboarding hub keeps it visible: requests for firewall changes, accounts or approvals go to the right IT contact with a clear deadline, credentials go into secure slots and never by email, and readiness gates and sign-offs record each approval. For timing across the project, see how long AR automation implementation takes.

Takeaway: book the change windows and the security review in week one; they decide the date more than the connection does.

What does an outbound-only agent change on your network?

Transformance’s on-premise agent sits inside your network and connects outbound only, so IT makes no inbound firewall change and sets up no VPN, and credentials stay on site.

‍

‍

The agent runs on a host inside your network, reaches systems the cloud cannot see (an on-premise ERP, a database, a file share) and runs end to end today. It opens the connection to the Transformance platform itself; nothing connects in. Passwords for your on-premise systems are stored inside your network and never sent to the cloud. Every action the agent can take is labeled read, write or execute, and IT approves that list.

What IT still does. IT provides the host, allows the one outbound destination, runs the install with Transformance’s team, keeps the host patched under its own rules and approves the action list.

The pattern is normal. Microsoft describes the same approach for its on-premises data gateway, which “requires no inbound ports to your network, only outbound ports” (Microsoft Learn, 2026). SAP describes its Cloud Connector as a reverse invoke proxy that removes the need to open inbound ports in the on-premise firewall (SAP Learning, 2026).

Other routes keep their own rules. The agent is one route, not the default. An API or OData connection, the ERP’s own MCP server, files or SFTP, a database, middleware, an Azure app registration or RFC/BAPI and IDoc each follow that system’s own network setup. Where a legacy screen has no other route, Transformance runs your existing RPA scripts or builds new bots. If a system has an API, a database, a file drop or a mailbox, it can be connected; see how AR automation connects to a custom or legacy ERP.

Takeaway: for the on-premise agent, the network ask is one outbound connection and a signed action list.

What does IT run if the route is SAP Cloud Connector?

IT installs the Cloud Connector in its own network zone, allows only the backend systems and resources needed, replaces the default certificate, and sets up monitoring and a shadow instance.

SAP Cloud Connector is SAP’s component for connecting SAP’s cloud platform to on-premise systems such as SAP S/4HANA or SAP ECC. When it is the route, these are the operator’s tasks as SAP documents them (SAP Learning, 2026):

  • Placement. It is installed in your on-premise environment, in its own network zone.
  • Access control. It uses strict allowlists, so only the backend systems and resources you release are reachable.
  • Certificate. SAP advises replacing the default certificate with your own.
  • Service user and installer. On Windows, the service should run under a user with limited privileges, and SAP strongly recommends the installer version for a productive setup.
  • Audit logging. It logs inbound traffic and configuration changes.
  • High availability. A shadow Cloud Connector takes over on failure.
  • Monitoring. It contains integrated monitoring and alerting tools.
  • Patching. It is updated with 1 to 4 new releases each year, with frequent patches.

This is work for the SAP Basis and network teams. Before go-live, name three owners: who renews the certificate, who watches the alert, and who applies the patches.

The Cloud Connector is one option, chosen when it fits your landscape; the route decision is covered in AR automation with SAP BTP and Integration Suite.

Takeaway: if the Cloud Connector is your route, give its certificate, alerts and patches a named owner each.

What access does the technical user need, and what must it not have?

It needs read rights for the entities in scope, write rights only for the postings in scope and only behind approval, and no admin, user-management or configuration rights.

One technical user per environment. Create one for test and one for production, never a person’s login or a shared admin account. In SAP S/4HANA Cloud, SAP calls this setup a communication user and a communication arrangement. For Microsoft ERPs, the connection can run through an Azure app registration in your own tenant. If your group runs entities on different ERPs, each ERP gets its own route and technical user, and the entities still run in one Transformance environment (multi-ERP finance automation).

What is read and written. Reads cover customer master data, open items, invoices, journal entries, bank statements and remittances; writes cover clearing postings, journal entries and reversals (the ERP field map). Postings go through the ERP’s interfaces (API, OData, BAPI or MCP); direct database writes happen only where you explicitly agree. SAP systems need no custom ABAP and no modifications.

People and approvals. Staff sign in through SSO/SAML, and role-based access control decides what each person may see and approve; administrators configure the rules, finance users approve. Transformance runs four approval levels (read, recommend, execute, post), and a human signs off every ERP posting, with thresholds by amount, entity and customer (approval thresholds for AI agents). This is the AI governance your auditors will ask about.

The revocation test. Disabling the technical user must end the access; ask to see it in the pilot.

Takeaway: a narrow, non-personal user per environment, writes only behind approval, and a switch that turns it off.

How do you keep test and production apart?

Use one technical user and one connection per environment, test on your own transactions in a non-production system, and let a person approve each step into production.

The same workflow can point at a test system or a production system just by changing its settings.

Testing runs on your own transactions in a staging environment, then as a parallel run beside your current process, and ends in an acceptance report. A person approves everything that reaches production.

IT has two checks to make:

  • the test connection and its technical user cannot post into production;
  • the switch to production is a recorded approval, with a readiness gate and a sign-off.

Takeaway: separate users, separate connections, and a signed switch between them.

What does IT see and monitor after go-live?

Every run is recorded with its steps and result, failures land in a plain-language queue with an owner and a retry, and the audit trail shows who approved what.

Run history and failures. Each run keeps its history and step-level logs. When only some records in a sync fail, the monitor lists each record instead of marking the whole job as failed. A failed run can be retried in one click or re-run from the failed step. Transformance fixes the connection when it breaks.

Audit trail. The audit trail stores the timestamp, what the system did, what the user did, who approved, the input and the confidence (audit trails and reversals for AI agents).

Ongoing IT work. Patch the agent host (or the Cloud Connector), rotate credentials and certificates under your policy, review the access list, and watch the failure queue.

The security review. SSO/SAML, role-based access control and a full audit trail are standard. Customer data is hosted in your own region, and VPC deployment in your cloud is available (AR automation that keeps your data in your region). No customer data is used to train models, and Transformance is GDPR compliant. What to ask any vendor is in the enterprise AI vendor checklist for finance.

Takeaway: after go-live, IT keeps four routines: patch, rotate, review access, watch the queue.

Who Transformance is for

  • ERPs: SAP S/4HANA (on-premises, private or public cloud), SAP ECC, NetSuite (including OneWorld subsidiaries), Microsoft Dynamics 365 Finance & Operations and Business Central, and Odoo, all running in production with customers; Oracle and Infor are supported.
  • 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: IT approves, Transformance builds and runs

IT’s part in an AR automation rollout is a short list: a contact, a technical user per environment, one outbound connection or another agreed route, a signed action list, a test system first and a recorded go-live. Transformance builds and runs the connection, and a person approves every change that reaches your systems. Book a Call to walk your IT lead through the list for your ERP.

Key terms

Related guides

‍

‍

Frequently Asked Questions

What does IT need to do when you roll out AR automation?

IT names a contact, creates a technical user with scoped rights, allows one outbound connection or agrees another route, approves the action list and tests in a non-production system first. Transformance builds and runs the connection.

Do we need to open inbound firewall ports or set up a VPN?

Not for the on-premise agent: it connects outbound only, so there is no inbound firewall change and no VPN, and your credentials stay on site. IT still provides a host, allows one outbound destination and approves the actions. Other routes follow their own setup.

Do we need SAP Cloud Connector?

Not necessarily. It is one of several connection options, alongside APIs, OData, RFC/BAPI and IDoc, files or SFTP, middleware, an Azure app registration and Transformance’s on-premise agent; the method follows your environment.

Which ERPs does Transformance work with, and does the IT task list differ?

Transformance runs in production with customers on SAP S/4HANA, SAP ECC, NetSuite, Microsoft Dynamics 365 and Odoo, and supports Oracle and Infor. The tasks are the same; the technical user, route and network path differ by ERP.

Is Transformance built for our size and payment volume?

Transformance is built for mid-market to large enterprises with 250 to 2,000+ employees and from under 1,000 to over 100,000 payments a month, including groups with several entities and shared service centers.

How long does the IT work take, and what does it cost?

The ERP connection typically takes 2-3 days for production ERPs, and your IT team may be involved; a proof of value runs 4-5 weeks on one entity, and a full rollout takes up to 4-8 weeks (Transformance customer data, 2026). Cost depends on scope and the number of entities. Book a Call for a figure.

What can IT see after go-live, and who approves what is posted?

IT sees every run with its steps and result, and a queue of failures with a retry. Finance approves postings within thresholds by amount, entity and customer, and nothing posts to the ERP without a person’s sign-off.

SAP, SAP S/4HANA, SAP ECC, SAP BTP, SAP Cloud Connector, Microsoft, Azure, Windows, Dynamics 365, Business Central, Oracle, NetSuite, Odoo and Infor are trademarks of their respective owners. Transformance is not affiliated with or endorsed by them.

Continue reading