# Four ways to connect AI to your ERP, and the trade-offs of each.

> In this field note, veridive compares four ways to connect AI to an ERP: the ERP’s own APIs, read-only database views, scheduled exports, and middleware or screen automation as a last resort. It explains how to choose per workflow by freshness, safety and upkeep, how writes stay safe, and what IT should agree first.

There are four practical ways in: the ERP’s own APIs, read-only database views, scheduled exports, and middleware or screen automation as a last resort. Choose per workflow by freshness, safety and upkeep, and start read-only.

## Key takeaways

- There are four practical ways in: the ERP’s APIs, read-only views, scheduled exports, and middleware or screen automation as a last resort.
- Choose per workflow by how fresh the data must be, whether it will ever write, and who maintains the connection.
- Write only approved drafts, through the ERP’s own interfaces, tested in a sandbox and run under a dedicated service account.
- Agree scope, identity, network route, data residency and upgrade handling with IT before the first connection.

The first technical meeting of an ERP-related AI project tends to circle one question: how will the system get the data? Someone proposes the API. The ERP consultant suggests a database view. The data team already runs a nightly export. And someone from operations asks why the software can’t just use the screens the way people do.

All four are real options, and each is right somewhere. Choose per workflow, by how fresh the data must be, how safe the route is and who will maintain it. And start read-only, whichever route you pick.

## What does an AI workflow need from the ERP?

Less than a full copy, and more precisely defined than “access to the ERP”. For one workflow, write down:

- **Reference data:** suppliers, items, customers, cost centers. It changes slowly, so yesterday’s copy is usually fine.
- **Transactional data:** open orders, goods receipts, invoices, stock. Matching an invoice needs this morning’s receipts; a weekly report can live with last night’s.
- **Documents:** attachments and scans, whether they sit in the ERP or a document system.
- **Writes, if any, later:** draft entries, status changes, notes.

That list becomes a contract: these fields, this fresh, at this volume, excluding personal data the workflow doesn’t need. With it in hand, the four patterns compare like this:

| Pattern | Freshness and writes | Effort and upkeep | Main risk |
|---|---|---|---|
| **ERP APIs** | Current; writes run through the ERP’s own validations | Medium; stable when the interface is documented | Gaps in what is exposed; licensing and limits to check |
| **Read-only views** | Close to real time; read only | Low to medium; views can break when the ERP is upgraded | Load on the production database; permissions rebuilt by hand |
| **Scheduled exports** | As of the last run; read only | Low; simple jobs to monitor | Decisions made on stale data |
| **Middleware or screen automation** | Varies; screen automation writes like a user | Medium to high; screens change without warning | Brittle, slow and harder to audit |

## When are the ERP’s APIs the right route?

When the workflow needs current data about individual records, and when it will one day write back. An API call asks the ERP itself, so the answer is live and the ERP’s business rules apply.

The same patterns hold whether the ERP is SAP, Oracle, Microsoft Dynamics, Logo or Netsis. These are examples of systems AI connects to, not partnerships, and which interfaces exist depends on the product, version, modules and license. Confirm with whoever maintains yours before designing around an interface. Then test it the practical way: fetch the real records your evaluation set needs, and time the calls at the volume you expect.

## When do read-only views or exports work better?

**Read-only views** suit lookups and matching when the API is thin or slow. IT defines views that expose exactly the agreed fields to a read-only account, ideally on a reporting copy rather than the production database. Two cautions: a view bypasses the ERP’s own permission model, so restrictions must be rebuilt in the view itself, and views need retesting after ERP upgrades. They are also the natural base for plain-language questions over business data, which our note on [text-to-SQL](https://veridive.com/insights/text-to-sql-for-business-data/) covers.

**Scheduled exports** are the simplest and safest route: a job copies the agreed data to a staging area on a schedule, and the ERP is never touched by the AI at all. They suit reporting, search, analysis and building evaluation sets. The price is freshness, so every answer built on an export should show when the data was taken.

Most workflows mix them: exports for reference data, a view or an API for the few lookups that must be current.

## When is middleware or screen automation justified?

If your company already routes ERP integrations through an integration layer, use it. Monitoring, retries and mappings exist, and IT knows how to run them. Adding a new middleware product for one AI workflow is a different matter: it is one more system to operate.

Screen automation, software that operates the ERP’s screens like a user, is the last resort. It is justified when there is no API, no import and no database access, the volume is low and the screens rarely change. Keep it read-only where possible, give it its own user, and log a screenshot of every step.

## How do writes back to the ERP stay safe?

> Write through the ERP’s front door, never through its database.

- **Approved drafts only.** The AI prepares an entry; a person approves it; only then does the integration post it. Where the ERP supports parked or held documents, a person can release them inside the ERP itself.
- **Through the ERP’s own interfaces.** An API or standard import runs the ERP’s validations, numbering and audit log. Writing into tables skips all three.
- **A sandbox first.** Evaluation cases are posted to a test environment and compared with what an accountant would have posted.
- **A dedicated service account** with only the rights the task needs, so every change is traceable to the system.
- **Repeat-safe posting.** Each write carries the source document’s ID, so a retry can’t post twice.

Our note on [designing the tools an AI agent may use](https://veridive.com/insights/ai-agent-tool-design/) covers the same limits from the software side.

In an illustrative case, a mid-size manufacturer runs its ERP on servers in its own building. In the first phase, IT publishes three read-only views on a reporting copy, for open orders, goods receipts and suppliers, plus a nightly export of items and price lists to a staging database reached over the company’s VPN. The system drafts invoice entries on a review screen, and accountants key the approved ones by hand. Once drafts meet the agreed threshold in the sandbox, the second phase posts approved drafts through the ERP’s import interface, under a service account that can create entries and nothing else.

## What should IT agree before the first connection?

- **Scope:** the fields per workflow, and what is excluded, such as salaries and personal data the workflow doesn’t need.
- **Identity:** a dedicated service account per system, with credentials in a vault and rotated.
- **Network route:** on-premises ERPs are common in mid-size companies, so agree the VPN or private connection instead of exposing the ERP to the internet.
- **Data residency:** where data is processed and stored, and which fields may leave the building; take the legal questions to your data protection officer.
- **Load windows:** when heavy queries and exports may run.
- **Change handling:** who warns whom before ERP upgrades or customizations, and how the integration is retested.

## Fields, freshness, pattern

List the fields one workflow needs, decide how fresh they must be, and pick the lightest pattern that meets both. The [ERP and enterprise workflows](https://veridive.com/solutions/erp-enterprise-workflows/) page shows how a first project moves from read-only to approved writes, and [data and AI foundations](https://veridive.com/services/data-ai-foundations/) covers deployment in your cloud or on-premises.

## Frequently asked questions

### How do you connect an AI system to an ERP?

Usually through one of four routes: the ERP’s own APIs, read-only database views, scheduled exports to a staging area, or, as a last resort, middleware or screen automation. The right choice depends on how fresh the data must be, whether the workflow will write back, and who will maintain the connection. Most projects should start read-only.

### Is it safe to let AI write to an ERP?

Only through approved drafts. The AI prepares an entry, a person approves it, and the integration posts it through the ERP’s own interfaces so its validations run, never by writing into database tables. Writes are tested in a sandbox first and run under a dedicated service account with only the rights the task needs, with every step logged.

### Can AI work with an on-premises ERP?

Yes. Many mid-size companies run their ERP on their own servers, and AI components can reach it through a VPN or private connection, or run on-premises themselves. The questions to settle with IT and the data protection officer are which data may leave the building, where it is processed and stored, and when heavy queries may run.