Adding Intelligence Around a System of Record

The core stays deterministic

An ERP is a system of record. Its transactions must be exact, auditable and repeatable, and none of those are properties of a model.

AI belongs at the edges of an ERP: getting good data in, and making what is in there understandable. Not in the middle, deciding transactions.

Four safe and valuable places

1. Document intake — orders, invoices and confirmations into draft records
2. Master data quality — duplicate detection, classification, missing attributes
3. Exception explanation — why this order is on hold, in plain English
4. Reporting questions answered against curated views, read-only

Master data is the underrated one

Duplicate customers, inconsistent product classification, missing attributes and stale supplier records cost more than most businesses realise, and nobody has time to fix them.

Matching things that are the same but written differently is exactly what models are good at, and it is a batch job with a review queue rather than anything risky.

Write-back rules

• Draft or staged records only, never posted transactions
• Through the ERP's own API, never straight into its database
• Idempotent, with a reference derived from the source
• Every record traceable to its source document
• Daily reconciliation of sent against arrived

Working with the vendor

Check what your licence permits, what the API costs and whether your support arrangement is affected. Some ERP vendors are restrictive about integration.

Get those answers in writing before scoping. They occasionally change the recommendation entirely.

Frequently asked questions