Bringing AI into ERP and legacy systems without replacing them

When a company starts thinking about AI in its operations, the ERP question comes up quickly. Our ERP was customised years ago; our transport system is older still. Does AI mean replacing them?

Usually not. The ERP holds the accounts, the master data and years of rules that auditors rely on. Replacing it in order to add AI would put all of that at risk, for a benefit that does not require it. The better pattern is to leave the ERP in charge and build a layer beside it. The same holds for CRM, warehouse and transport management systems.

The ERP stays the system of record

A system of record is where the company's official version of a fact lives: this invoice was booked, this order exists, this supplier has these payment terms. AI should not become a second system of record, and it should never write into the ERP's database directly, around the rules the ERP applies.

In practice, AI works on documents and messages before they enter the ERP — reading, classifying, extracting, matching — and delivers a proposal. What enters the ERP is decided by rules and, where needed, by a person.

AI proposes, rules decide

The division of labour is simple to state. The model does what rules cannot: read an invoice in a layout it has never seen, understand an email that mixes two orders and a correction, find the right column in a spreadsheet designed by a customer. The rules do what the model should not: decide whether a VAT number is valid, whether a total adds up, whether a supplier exists, whether a posting is allowed.

The separation has a practical benefit. When something goes wrong, you can see whether the model misread the document or a rule was missing. Both can be fixed; mixed together, neither can.

The integration layer

Between the AI and the ERP sits an integration layer. It is ordinary engineering, and it decides whether the whole system can be trusted.

APIs and middleware

Where the ERP offers services, the integration layer calls them with the same checks a user interface would apply. Where it doesn't, the layer uses what the ERP already reads: import tables, files, scheduled jobs. Either way, the ERP's own validation stays in play.

Queues

A message queue such as RabbitMQ or Azure Service Bus separates the AI step from the ERP. If the ERP is down for maintenance, work waits in the queue instead of failing. If a thousand documents arrive at once, they are processed at the pace the ERP can accept. Retries happen from the queue, with a limit; a message that keeps failing is set aside for a person instead of blocking the rest.

Staging tables

Many ERPs, and most legacy systems, can import from staging tables: an area where data is written, checked, and then picked up by the system's own import routine. Staging gives a clear point where a record can be inspected before it becomes official, and keeps the ERP's rules in charge of the final step.

Idempotent imports

Every import must be safe to repeat. Each document gets a stable identifier, and the integration checks it before writing, so that a retry after a timeout does not book the same invoice twice. Idempotency is what makes automatic retries possible, and automatic retries are what let a flow run at night without anyone watching it.

Observability

Every message should be traceable from the email or the file to the record in the ERP: when it arrived, what the model extracted, which rules ran, what was written and what the ERP replied. With distributed tracing, for example OpenTelemetry, a failed case can be found directly instead of being reconstructed from scattered logs.

Master data mapping

The least glamorous part of the work is often the largest. A supplier invoice says “Acme Logistics S.p.A.”; the ERP knows that supplier by a code. An email says “the Milan warehouse”; the transport system needs a location identifier. The mapping from what documents say to what systems know is what turns extracted text into something the ERP can book.

AI helps here too, because it can suggest the likely match. But the mapping itself should be stored, reviewed and reused, not guessed again every time. Over time, a well-kept mapping table becomes an asset that outlasts the project. Building it also cleans up master data: every mismatch it reveals is a record that was inconsistent somewhere.

Speaking the legacy system's language

Legacy systems often have a single door: an import format they have accepted for years. The right move is to generate exactly that format — every field, every code, every quirk — and validate it before delivery, rather than asking the old system to change.

In a pilot for a European transport and logistics group, AI turns customer emails into transport orders. The orders are validated all-or-nothing and converted into the XML that the group's transport management system imports. The transport system receives the format it has always received. Read the case study.

Two examples from our work

For a luxury cruise line, booking financials are pushed automatically into Microsoft Dynamics NAV, so they are no longer re-keyed by hand. NAV remains the system of record; the platform prepares, checks and delivers. That flow does not use AI, but it is the pattern AI needs: a proposal prepared outside the ERP, delivered through an interface the ERP controls. Read the case study.

For an international freight forwarder, an AI agent reads supplier PDF invoices. The invoices are then mapped, approved and imported into the management system, and matched to shipment files through the API of the forwarder's operational system. The model proposes; mapping, approval and import follow rules and people. Read the case study.

Three mistakes to avoid

• Writing straight into the ERP's database. It looks faster, and it bypasses every rule the ERP applies. The errors it lets through tend to surface later, in the accounts.
• Letting the model decide what is valid. A model asked whether an invoice is correct will answer; that does not make the answer a check. Validation belongs to rules that give the same result every time.
• Leaving the integration for last. When the AI works before anything is connected, the project looks nearly finished. It is not: integration, mapping and exceptions are usually the larger part of the work.

A sequence that works

1. Choose one document flow with a clear owner and a clear cost.
2. For each field, identify the system of record and the interface it offers.
3. Build the integration layer first, with idempotent imports and tracing, and test it with data entered by hand.
4. Add the AI step in front of it, with validation rules and a review screen for exceptions.
5. Run it alongside the current process, compare the results, then switch over.

Building the integration first may feel backwards. It is the part that makes the AI step useful, and it is also the part that will still be there when the model changes.

This is the work we do in systems integration and enterprise AI.