Feasibility depends on your actual ERP installation, the data required and the operations permitted. APIs, exports and other authorised methods are options to investigate, not guaranteed Digital Employee connectors. Finance and IT need to agree sources, permissions, testing and error handling before connecting the process.
Assess a process, not just the ERP's name
“We use this ERP” is not enough to define an integration. You need its version, deployment type, customisations, entities involved and the operation required. Reading a receivables schedule and changing an accounting entry are different assignments, even within the same system.
Start with the result you need: which information should reach which person, and how often? Then work back to the required sources. For the service scope, our Digital Employee for finance teams page presents processes to assess against your actual systems. The technical routes below are general options to investigate, not a catalogue of available connectors.
Which access options can be assessed?
APIs and documented interfaces
An API is an interface through which software can request data or operations provided by a system. Its existence does not establish that it exposes every field you need or permits the intended action. For example, Microsoft documents REST APIs for Business Central and distinguishes enablement online from on-premises installations. This is a documented product feature, not a claim of compatibility with our service. Source: Microsoft's API v2.0 documentation.
Agreed exports
A file produced by the ERP may be a suitable source if its update frequency fits the task. Agree the format, fields, identifiers, period and delivery owner. A list exported yesterday cannot be presented as today's current position. If an export lacks a required column, the process must flag the omission or be redesigned.
Working through the application interface
Access through the application interface is another general possibility where authorised and technically sustainable. Before considering it, check the terms of use, authentication, screens and interruption handling. A changed screen or expired session should be included in the assessment. One successful run is not a basis for promising continuity.
The shared Finance and IT checklist
This practical feasibility checklist should be completed with the system owner and process owner. “To be checked” identifies outstanding work; it is not technical approval.
Scroll the table horizontally to read every column.
| Area | Information to gather | Useful evidence |
|---|---|---|
| System and version | Product, version, deployment and relevant customisations. | An inventory confirmed by the IT owner. |
| Sources and entities | Required records, tables or documents and entity boundaries. | A source map with a named owner for each data set. |
| APIs or exports | Fields, operations, formats and frequencies actually available. | Applicable documentation and an authorised sample. |
| Permissions | Identity used, accessible data, permitted operations and revocation. | An approved access matrix and tests of prohibited actions. |
| Test environment | Where to test ordinary cases, exceptions and interruptions. | An isolated environment or test data appropriate to the scope. |
| Reads or writes | Which actions retrieve information and which change the system. | An explicit list of permitted operations. |
| Data quality | Identifiers, duplicates, missing fields, currencies and dates. | Samples of valid, incomplete and ambiguous records. |
| Error handling | How to stop, assign, resume and verify a case. | Observable results from tests of failure conditions. |
| Maintenance | Who manages versions, credentials and format changes. | An owner and a procedure for checking changes. |
| Acceptance | When Finance and IT consider the result valid. | Agreed criteria, evidence and decision owners. |
Permissions: test what must be prohibited too
Showing that a connection can read a document is not enough. Check that it cannot access entities or information outside its assignment. Define how the integration identifies itself, who authorises its access and who can revoke it. Do not assume shared personal credentials are an acceptable shortcut.
The options depend on the product. For Business Central, Microsoft describes service-to-service authentication using an application's identity, with registration and permissions to configure; it recommends assigning only the permissions required. Source: Business Central service-to-service authentication. The practical requirement to verify in your ERP is that technical access matches the assignment. Our guide to permissions and approvals explains the handover of responsibility.
Test failures and volumes, not just the easiest case
An incomplete response, revoked access or temporarily unavailable source must produce a recognisable outcome. Include peak workloads in testing. Business Central online documentation, for example, specifies request limits and error responses when certain limits are exceeded. Source: Microsoft's operational limits. Your own system's conditions need to be checked separately.
If a write request is interrupted without a certain outcome, repeating it blindly could repeat an action that has already happened. The agreed procedure needs to explain how to check the previous outcome, when to retry and when to involve a person. These are project requirements to demonstrate in the proposed configuration, not capabilities certified by this article.
Start with reading; assess writes separately
Consider an illustrative task: prepare a list of invoices without purchase order references for one entity. A possible workflow reads an authorised source, applies an agreed rule and prepares a list with references and the extraction date. The owner reviews the cases. Producing that output does not require an assumed right to change invoices or master data.
Any subsequent write needs a distinct scope: editable fields, approval, outcome checks and recovery arrangements agreed with the ERP owner. Actions cannot all be reversed in the same way. Payments, changes to bank details and sensitive accounting decisions remain with authorised people.
Agree who maintains the connection
Establish who identifies an ERP update, checks a changed format and manages expiring access. Agree how failures are reported, what work stays pending and how it resumes after an intervention. Include these responsibilities when assessing scope and cost: making the initial connection does not complete the ongoing work.
The provider selection checklist helps you request evidence about support, responsibilities and exit arrangements. The first useful result is a documented assessment of what is feasible in your systems and which conditions still need to be resolved.