Key Takeaways
- Transformance connects to custom and legacy ERPs through its integrations hub: if a system has an API, a database, a file drop or a mailbox, it can be connected.
- Transformance tries the routes in order: a documented API, a file drop, a read-only database view, an outbound-only on-premise agent, and RPA last.
- A custom system has to give stable keys, open items, customer master data and payment history, and accept postings through one validated write path.
- Every connection is tested on your own transactions before it posts; for a custom system, the route and the effort are agreed after the feasibility check.
- IT approves the route, the technical user, the network path and the action list; finance approves the postings, and the ERP stays the system of record.
In This Article
- Key Takeaways
- Can AR automation connect to a custom or legacy ERP?
- What does a custom system have to give and take?
- Which route should you try first?
- How do file drops and database reads work as routes?
- How does an on-premise agent reach a system behind your firewall?
- When is an RPA step the right answer?
- How is the connection tested before it posts anything?
- What does your IT team approve, and who owns what?
- Which systems does Transformance run in production today?
Can AR automation connect to a custom or legacy ERP?
Yes. Transformance connects to custom and legacy ERPs through its integrations hub; the route depends on what the system offers, what IT approves and how postings get back in.
Six ways to connect a custom or legacy ERP: when each fits, what IT approves, where each breaks
“Custom” and “legacy” describe the interface here, not the quality of the system; the only question is which door it offers. The ERP stays the system of record, and Transformance writes back only what a person approved. If your ERP already runs in production with our customers, start with which ERP systems Transformance integrates with; this page is for the system that is not on that list.
A file is a normal route, not a workaround. Microsoft documents a recurring-integration feature in Dynamics 365 Finance and Operations that “enables the exchange of documents or files between finance and operations and any third-party application or service” (Microsoft Learn, 2026).
The route decides how data arrives; the AR work on top is the same on every ERP. Across customers, ClearMatch auto-matches 95% of payments and runs end to end in under 8 minutes, and nothing posts without human sign-off (Transformance customer data, 2026). When a payment does not match, Vero, Transformance’s AI agent, investigates from Customer 360, proposes a match with the evidence, and a person approves.
Takeaway: the question is not whether your system can be connected, but which door IT wants to open.
What does a custom system have to give and take?
It has to give open items, customer master data and payment history with stable keys, and take back clearing postings and journal entries through an interface the system itself validates.
The minimum data contract:
- Stable keys: a customer ID and an invoice number that do not change once issued.
- Open items: amount, currency, due date and legal entity for every unpaid invoice.
- Customer master data: bank details and payment terms.
- Payment history: what each customer paid, when, and against which invoices.
- One validated write path: an API, an import job or a staging table that checks clearing postings and journal entries on the way in.
Add a test environment, a named technical contact and sample records. Postings go back through the system’s own interfaces; Transformance writes directly to a database only where you explicitly agree.
Bank statements (ISO 20022 camt.053, BAI2, lockbox files) and remittances do not come from the ERP (bank statement formats, remittance sources); the field-by-field version is in what AR automation reads from and writes to the ERP.
Takeaway: give these five things and accept one validated write, and the AR process on top does not care how custom the system is.
Which route should you try first?
Try this order: documented API, file drop, read-only database view, on-premise agent where the cloud cannot reach, and RPA only when nothing else exists.
Prefer the interface the system’s owner supports and validates: it stops bad data at the door. SAP’s released remote APIs are OData and SOAP services, and SAP “guarantees the stability of these interfaces from release to release” (SAP Learning, 2026).
Each “no” to “is there a documented interface, can it exchange files, does IT allow a read-only view” moves you down the list; if the cloud cannot reach the system, the on-premise agent is the path.
For SAP, see the SAP integration route for AR automation (S/4HANA) and AR automation on SAP R/3 and ECC.
Takeaway: start with the door the system’s owner maintains; every step down the order adds work for someone.
How do file drops and database reads work as routes?
A file drop moves scheduled exports and imports through a shared folder; a database route reads a documented view and posts through the system’s own import interface.
The file route. File exchange is long established, as EDI shows. Four common practices keep it safe, usually over SFTP:
- write each file under a temporary name and rename it when complete, so a half-written file is never picked up;
- archive every file that was picked up;
- make the import idempotent: the same file sent twice posts once;
- agree what happens when a file is late, and who is told.
The database route. Read from a documented reporting view or an approved replica, not the physical tables, because a view stays stable when the schema changes. Write through an import interface or staging table the system validates; a write that bypasses its checks can damage the ledger, which is why direct database writes happen only where you explicitly agree.
On the Transformance side, database and file steps are parts of a workflow in the integrations hub. Large loads run in paced batches, and a run lists exactly which records failed, so only those are re-run.
Timing: file and batch routes run on the schedule you agree, for example several times a day or overnight.
Takeaway: a well-run file or view is a sound route; the discipline around it is what makes it safe.
How does an on-premise agent reach a system behind your firewall?
A small Transformance agent inside your network opens an outbound connection, so the system is reached without an inbound firewall change or a VPN, and credentials stay on site.
The on-premise agent runs end to end today. It is a network path, not a sixth kind of data: it carries an API call, a file or a database query to what the cloud cannot see. Credentials for on-premise systems are entered and stored inside your network and never sent to the cloud. Every action the agent can take is labeled read, write or execute, so IT approves exactly what a workflow may do.
The pattern is established: Microsoft’s on-premises data gateway “requires no inbound ports to your network” (Microsoft Learn, 2026), and SAP’s Cloud Connector acts as a “reverse invoke proxy, eliminating the need to open inbound ports in the on-premise firewall” (SAP Learning, 2026). For SAP systems, the Cloud Connector is an option alongside Transformance’s own agent; the method follows your environment.
IT still installs the agent on a host it manages, allows its one outbound destination, approves the action list and owns patching; the task list is in what IT needs to do when you roll out AR automation, and the view per ERP in how AR automation works with an on-premise ERP.
Takeaway: the agent turns “the cloud cannot reach it” into one outbound rule and an action list IT signs.
When is an RPA step the right answer?
When the system offers no interface at all, only a screen or a desktop tool, and the task is bounded, repeatable and checkable afterwards.
Robotic process automation operates a screen the way a person would, as one step of a workflow. Transformance runs the RPA scripts you already have, and builds new bots where a screen has no other route.
RPA is the slowest route and breaks when a screen changes, so a step gets its own service account and a person approving whatever it posts; when a run fails, it re-runs from where it stopped.
Takeaway: use RPA for the one screen nothing else can reach, not for the whole integration.
How is the connection tested before it posts anything?
In four steps: a feasibility check on sample records, a test on your own transactions in staging, a parallel run beside your process, and an acceptance report a person signs.
- Feasibility check on sample records. You export sample open items, customer records and a payment file; Transformance checks what the system can give and accept and agrees the route with IT.
- Staging test on your own transactions. The workflow points at your test system and runs the test plan on real examples, including awkward ones.
- Parallel run. Transformance runs beside your current process, and both results are compared before anything switches.
- Acceptance report and go-live sign-off. A person on your side signs. The same workflow then points at production by a setting, not a rebuild.
Transformance’s integration agents do the work between those sign-offs: they read the system documentation and your setup answers, propose the field mappings, draft the workflows, run the test plan and report, and draft plain-language explanations when something fails. A person approves every change that reaches your system or production (the agent-run integration platform, how agents build and test an integration). Transformance builds the connection and, after go-live, runs, monitors and fixes it; failures arrive in a plain-language queue with an owner and a retry, and your team approves access and production changes.
Timing. For the ERPs that run in production with our customers, the connection typically takes 2-3 days, 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). For a custom system, the route and the effort are agreed after the feasibility check (how long AR automation implementation takes).
Takeaway: the proof of a custom connection is a signed test on your own transactions.
What does your IT team approve, and who owns what?
IT approves the route, the technical user and its rights, the network path and the action list; finance approves the postings, by amount, entity and customer.
IT creates one technical user per environment with least privilege (how AI agents access ERP data safely). Finance owns the postings: Transformance runs a 4-level approval model (read, recommend, execute, post) with a human in the loop for every ERP posting; thresholds are set by amount, entity and customer, administrators configure the rules and finance users approve (approval thresholds for AI agents). Every action lands in the audit trail with who approved it (audit trails and reversals).
Credentials sit in a secure vault, never in workflows, logs or exports. Data stays in your region (keeping your data in your region), and no customer data is used to train models.
Takeaway: IT decides what may connect and how; finance decides what may post.
Which systems does Transformance run in production today?
SAP S/4HANA, SAP ECC, NetSuite, Microsoft Dynamics 365 Finance & Operations, Business Central and Odoo run in production with customers; Oracle and Infor are supported.
Beyond that list, Transformance connects to the ERP a company runs through its integrations hub. Several long-running systems have a guide of their own:
- SAP R/3 and ECC, and what happens to AR on each S/4HANA path if a move is planned;
- JD Edwards;
- Oracle E-Business Suite;
- Dynamics NAV, GP and AX.
If your group runs several ERPs, entities on different systems run in one Transformance environment with one worklist and one forecast across all modules (automating finance when every entity runs a different ERP).
For a system on no list at all, tell us which interface it offers; Transformance checks it on sample records and comes back with the route.
Takeaway: a named ERP has a guide, an unnamed one has a feasibility check, and both end in the same environment.
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 supported; custom and in-house systems through our integrations hub.
- 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: pick the supported door, test on your own data
A custom or legacy ERP does not stand in the way of AR automation. Choose the most supported route, agree what IT approves, and prove the connection on your own transactions before anything posts; Transformance builds and runs it, and your ERP stays the system of record. Book a Call and bring a description of the interface your system offers.
Key terms
- Robotic process automation: a script or bot that operates a screen the way a person would.
- EDI: structured electronic exchange of business documents between systems.
- ISO 20022: the XML standard behind camt.053 bank statements.
- Lockbox: a bank service that collects customer payments and reports them in a file.
- Audit trail: the record of who or what did what, and when.
- SAP S/4HANA: SAP’s current ERP suite.
Related guides
- Which ERP systems does Transformance integrate with?
- What is an agent-run integration platform for finance?
- How do AI agents build and test an ERP integration?
- What does IT need to do when you roll out AR automation?
- How do you automate finance when every entity runs a different ERP?
- How does AR automation work with an on-premise ERP?
Frequently Asked Questions
Can AR automation connect to a custom or legacy ERP?
Yes. If a system has an API, a database, a file drop or a mailbox, it can be connected. Transformance picks the most supported route with your IT team and tests it before anything posts.
What if our ERP has no API?
Use a file drop over SFTP or a read-only database view for data coming out, and the system’s own import interface for postings going in. For a system with only screens, Transformance runs your existing RPA scripts or builds a new bot.
Which ERPs does Transformance run in production, and is ours on the list?
SAP S/4HANA, SAP ECC, NetSuite, Dynamics 365 Finance & Operations, Business Central and Odoo run in production with customers; Oracle and Infor are supported. If yours is not on the list, Book a Call and tell us which interface it offers.
Does the connection need changes to our ERP?
The route is chosen so that your system stays the ledger: it needs a technical user and an interface the system already offers, such as an API, a file job or a validated import. Transformance posts only what a person approved, and for SAP there is no custom ABAP and no modification.
Is Transformance built for our size and payment volume?
Yes, for companies with 250 to 2,000+ employees and from under 1,000 to over 100,000 payments a month, including groups with several entities.
How long does it take, and what does it cost?
For ERPs in production with our customers, the connection typically takes 2-3 days (Transformance customer data, 2026) and your IT team may be involved. For a custom system, the route and the effort are agreed after the feasibility check. Cost depends on scope and the number of entities; Book a Call for a figure.
Does an on-premise agent need an open inbound port or a VPN?
No. The agent only connects outward, so there is no inbound firewall change and no VPN, and the credentials for your on-premise systems stay inside your network.
SAP, SAP S/4HANA, SAP ECC, SAP R/3, SAP Cloud Connector, Microsoft, Dynamics 365, Business Central, Dynamics NAV, Dynamics GP, Dynamics AX, Oracle, NetSuite, JD Edwards, Oracle E-Business Suite, Odoo and Infor are trademarks of their respective owners. Transformance is not affiliated with or endorsed by them.
