Strategic guide · Architecture · 2026

AI in procurement on top of your ERP, without replacing the core

How to add analytics and AI agents to the procurement cycle while the ERP remains the system of record: a layered architecture, the exact split of responsibilities and the answers to what a CIO asks before approving the connection.

By Oscar Gamboa, CEO of EGIXIA · Updated August 11, 2026

Read the guide Talk to an architect

Full guide on this page · no form, no download

Cover of the Egixia guide on integrating AI into procurement on top of the ERP

Executive summary

Adopting artificial intelligence in the sourcing and procurement functions of large Latin American enterprises usually runs into an architecture dilemma: replace the ERP with a suite that already ships AI, or stall in the face of integration complexity. Neither is an architecture decision; both are ways of avoiding one. This guide describes the third path: a layered architecture where analytics and AI agents operate on top of the existing ERP while the transactional core keeps its role as the system of record, accounting control and compliance.

The organizing principle is simple and shapes the whole design: AI proposes, the ERP disposes. Anything that commits budget, creates a contractual obligation or affects the books runs inside the ERP's authorized flows. Anything that analyzes, normalizes, compares, verifies or drafts can live in a decoupled upper layer that connects through the ERP's own standard APIs and can be switched off without leaving the business unable to operate.

Who this guide is for

It is written for whoever has to approve —or reject— connecting an AI layer to the system where the company's money is recorded.

CIOs, CTOs and enterprise architecture

They need to know what gets connected, with which protocol, what happens during an ERP upgrade and how the decision is reversed if the project does not work out.

CPOs and procurement directors

They want results in the procurement cycle without opening an ERP replacement program that consumes the budget and the attention of the function for two years.

CFOs, internal control and audit

They ask what gets logged, who authorized each movement and how you prove to an auditor that an algorithmic recommendation did not execute anything on its own.

Context: why the core is not the place for AI

The transactional core of an ERP is optimized for stability, accounting integrity and strict regulatory compliance. That rigidity is not a defect: it is exactly what is demanded of it. Artificial intelligence, by contrast, needs to iterate fast, process unstructured data, be wrong inside a controlled environment and switch models without opening a months-long project. Pushing that dynamic into the core asks a single system to be two incompatible things at once.

The ERP core remains the system of record for operations and accounting; AI capabilities operate in an upper layer of analytical orchestration and decision support, with governance and traceability built into the design rather than bolted on afterwards.
— Synthesis of the layered architecture principle described in references [1] and [2]

In Latin America the argument weighs even more, because technology landscapes are fragmented: several ERP instances inherited through acquisitions, entities with different tax rules per country and local e-invoicing layers that no global ERP ships out of the box. Replacing the core just to be able to use AI turns a twelve-week project into a two-year program, and concentrates the risk exactly where the company cannot afford it.

Two market data points worth having in front of you before approving the first pilot:

Over 40%

of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls.

Gartner, June 2025

30%

faster financial close by 2028, driven by embedded AI in cloud ERP applications.

Gartner, February 2026

The layered architecture

Four layers with separated responsibilities. The proof that the design is sound is that each layer can also be described by what it does NOT do: that is where failing architectures break.

ERP core layer

What it owns: Accounting execution, final issuance of purchase orders, goods receipt, invoice posting, payments and regulatory compliance. It is the single transactional source of truth.

What it does not do: It does not host models, does not run algorithmic logic and does not change its configuration to accommodate an AI pilot.

Integration and data layer

What it owns: Connects the ERP with the rest of the ecosystem using the ERP's own standard APIs, syncs master data and documents, and keeps identifiers matched across systems.

What it does not do: It does not duplicate the transactional database nor become a second ledger: it moves and reconciles, it does not replace.

Orchestration and AI layer

What it owns: Normalizes and classifies spend, verifies documents, extracts invoice data, compares offers, detects anomalies and leaves the decision prepared with its supporting evidence.

What it does not do: It does not issue final documents, does not commit budget and does not write to the ERP unless an authorized person approves the result.

Governance and human oversight layer

What it owns: Autonomy thresholds by amount and category, role-based access control, mandatory human review before a result is applied, and an auditable record of every step.

What it does not do: It is not documentation: if it is not implemented as a technical control, it does not exist on audit day.

How it is implemented: four phases

Order matters more than speed. The first three phases require no changes to the ERP; the fourth only writes to it once everything before it has been proven.

Phase 1

Landscape and data diagnosis

Before connecting anything, audit what already exists.

Inventory of live interfaces with the ERP: what connects today, with which protocol and who maintains it.
Real state of the supplier master: duplicates, invalid tax identifiers and inconsistent categories.
Map of current approvals by amount, category and legal entity.
Explicit definition of which data will not leave the ERP.

Phase 2

Designing the architecture and its limits

Write down the split of responsibilities before writing code.

Assign every business object to the layer that governs it and to its owning system.
Define direction and frequency of each synchronization, and what happens when it fails.
Set autonomy thresholds by amount and category, naming the role that approves.
Specify what goes into the audit log and how long it is retained.

Phase 3

High-volume, low-risk use cases

The first use case is chosen by its volume-to-risk ratio, not by how impressive it looks in a demo.

Document verification and supplier qualification.
Invoice extraction and validation, reconciled against the order and the receipt.
Normalization and classification of spend scattered across entities.
Duplicate and anomaly detection before documents reach the ERP.

Phase 4

Bounded pilot, measurement and scale-up

A pilot that cannot be compared against a baseline is not a pilot: it is a long demo.

Measure the baseline before switching anything on: current hours, volume and error rate.
Bound the pilot to one entity or one category, with a written success criterion.
Monitor ERP stability as a first-class metric, not as an anecdote.
Scale by business object, not by taking on a whole function at once.

The split of responsibilities, object by object

The table summarizes where each thing lives. If in a design discussion you cannot place an object in a single column, the boundary is not defined yet.

Business object	Role of the ERP core	Role of the AI layer	Interaction mechanism
Supplier master	Source of truth for the supplier record: tax, accounting and banking data.	Normalization, deduplication, category enrichment and document verification before the record is created or updated.	The supplier self-serves and validates documents in the procurement layer; once the flow is approved, the record is created or updated in the ERP.
Requisitions and purchase orders	Formal issuance, budget validation and accounting commitment.	Requisition drafts, selection of qualified suppliers by category, quote requests and a consolidated comparison sheet.	The AI layer serves up the decision; the final order is created in the ERP after an authorized user approves it.
Invoices and payments	Accounting posting, withholdings, payment scheduling and execution.	Capture, tax validation, duplicate and anomaly detection, and reconciliation against the order and the receipt.	The invoice reaches the ERP already validated; payment status flows back from the ERP to the portal so the supplier can check it without calling accounts payable.
Control and audit	Historical record of financial and payment transactions.	Continuous monitoring of exceptions, compliance risks and deviations from what was negotiated.	Exception reports and a record of every action with date, time and user, verifiable against the ERP documents.

The six questions a CIO asks before approving

None of these questions is about AI models. All of them are about what happens the day something goes wrong, and they are the ones that really decide whether the project moves forward.

Where does the data live and who can see it?

Transactional data stays in the ERP. What lives in the procurement layer is what the collaborative process needs: supplier documents, quotes, evaluations and traces. In EGIXIA's case that layer is a 100% SaaS platform on Amazon Web Services (AWS), in the United States (Northern Virginia region), with redundancy across multiple availability zones. Isolation is per client: dedicated instance and database with logical segregation; each client operates on its own storage bucket, with access policies that prevent cross-client access.

What happens when we upgrade the ERP?

Nothing, provided the integration uses only the ERP's standard APIs and installs no custom developments inside it. That is the criterion worth demanding in writing from any vendor. In the SAP integration, EGIXIA works with OData, BAPI, RFC and IDoc: no Z developments or add-ons are installed and no EGIXIA code is transported into the client's landscape, which is why Support Pack or release upgrades do not break the connection. That is the practical difference against a custom development inside the core.

Who owns the supplier master?

The ERP, always. The procurement layer manages the cycle with the supplier —onboarding, document validation, banking data updates and certificate renewals— and syncs the outcome with the ERP record; it does not create a second parallel master. That is the difference between integrating and duplicating, and it is what prevents two functions from arguing over which of the two databases is right.

What is recorded for an audit?

Every synced movement is traced with date, time and user, and every transaction between systems leaves its own record. For an AI-generated recommendation you should demand more: which data was used, under which criteria and who approved it. Without that, the recommendation is not auditable even if it was correct. Audit log retention is enabled per project, according to the client's policies.

How do we reverse the decision if we want to stop?

Because the ERP is the system of record, everything accounting and transactional is already inside it: reversing means disconnecting the layer, not migrating back. And since no developments were installed in the ERP, there is nothing to uninstall either. What is worth agreeing contractually from the start is the return of the documents and data that live in the procurement layer; their retention is enabled per project, according to the client's policies.

What happens if the AI layer becomes unavailable?

The procurement cycle has to be able to keep running in the ERP, even if with more manual work. That contingency plan is written before go-live, not after the first incident, and it is tested at least once. On the service side, EGIXIA operates with a 99.6% availability SLA, with Multi-AZ deployment on AWS.

Checklist for the IT and procurement committee

Six checks before signing. Answer them with evidence: if you cannot show the document, count it as a no.

1
Interfaces
Is every live connection to the ERP inventoried, with its protocol, its owner and its frequency?
2
Master data
Is there a written protocol to deduplicate, validate tax identifiers and unify categories before feeding any model?
3
Autonomy thresholds
Are the limits at which a recommendation requires human approval set by amount and category, with the approving role named?
4
Traceability
Does every AI-generated result carry a record of the data it used, the criteria applied and who approved it?
5
Continuity
Is there a written and tested contingency plan to run the procurement cycle if the AI layer is unavailable?
6
Exit
Is it contractually agreed what is returned, in which format and within what timeframe if the service ends?

All six are answered in the design phase. None of them requires having chosen a vendor yet, which is why they also work for comparing proposals.

Risks, limits and what this guide does not cover

The three risks that most often stop an AI project in procurement. None of them is the model.

Model errors taken as facts

An engine can misread a contractual condition or a pricing clause and present the error with the same confidence as a correct answer. AI is decision support: human review before a result is applied is a design requirement, not a temporary limitation of the technology.

The integration surface

Every connection point to the core is a door. Demand standard authentication, encryption of data in transit, least privilege per service and a technical user with narrow authorizations, defined with your security team before the first call.

Dirty master data

A master with duplicates and inconsistent categories produces useless results that look precise. Cleansing precedes algorithmic deployment: it is the boring work that decides the outcome of the pilot.

Disclaimer: this guide offers general methodological guidance and does not constitute legal, tax, financial or formal cybersecurity or regulatory compliance advice. Each organization must validate its architecture with its internal committees and the regulations that apply to it.

How to measure that the architecture works

Four indicators. The fourth is the one usually missing and precisely the one the CIO cares about.

Procurement cycle time

Days from requisition to approved purchase order, compared against the baseline measured before the pilot.

Recommendation acceptance rate

Percentage of AI-layer suggestions the buyer accepts unmodified. A very low rate points to badly calibrated criteria; a perfect rate points to nobody reviewing.

Spend classification accuracy

Percentage of transactions correctly categorized by the engines, with no later manual correction.

ERP core stability

Incidents and degradations of the transactional system attributable to the integration layer. The target is zero and it is measured from day one.

How EGIXIA does it

EGIXIA helps large Latin American enterprises simplify their entire procurement cycle, combining enterprise software, specialized services and AI-assisted operations on top of the ERP they already have. The platform operates as a procurement layer on top of the ERP: suppliers self-serve, quoting and document validation happen in the layer, and the ERP remains the system of record for accounting, inventory and payments.

The connection uses each ERP's standard APIs —OData, BAPI, RFC, IDoc and SAP CPI on SAP S/4HANA and ECC; REST API, SuiteScript and SuiteTalk on Oracle NetSuite; Service Layer and DI API on SAP Business One— with scheduled or event-driven synchronization, depending on the case. No ABAP development and no EGIXIA code transported into the client's landscape. Implementation is measured in weeks, not months.

On the AI layer the commitment is explicit: agents prepare the decision and none of their outputs is applied without prior human review. Data processed by the AI agents is not used to train models: it is a contractual guarantee that EGIXIA holds with its subprocessors, and they with their model providers. Each task runs in an isolated environment with no access to other clients' data, and EGIXIA performs proactive deletion within 72 hours of delivery. Reversible pseudonymization before AI processing is enabled per project, according to the client's policies.

In the business cases we build, the highest-value lever is taking more spend to competition: the range we use to size it is 2-4% price improvement on spend taken to tender.

A market reference range that EGIXIA uses in its business cases.

The technical detail, on its own page

SAP integration

Connectors, supported objects, implementation methodology and exactly what happens during an upgrade.

See the SAP integration

SRM integrated with SAP and Oracle

Which objects are synced in each ERP, in which direction and with which protocol.

See the synchronization detail

The 8 types of AI agent

What each type does, its real maturity in 2026 and the seven criteria to evaluate any vendor's version.

Read the evaluation guide

Security and compliance

The integration layer is the surface the IT security team reviews. These are the answers we publish, with the same wording we use on the integration pages.

Every connection runs on Amazon Web Services (AWS) infrastructure certified under ISO 27001, SOC 1/2/3 and PCI DSS; Egixia's own controls are aligned to ISO 27001 and validated by external penetration testing, whose executive report is available under a confidentiality agreement.

TLS 1.3

Encryption for data in transit across all communications.

OAuth 2.0

Secure token-based authentication.

AES-256

Encryption for stored documents; database and volume encryption is enabled per project, according to the client's policies.

SSO SAML

Enterprise Single Sign-On for user access: enabled per project, according to the client's policies.

See the detail in the Trust Center →

Frequently asked questions

Do I need to replace my ERP to use AI in procurement?

No. A layered architecture lets you attach analytics and AI agents through the ERP's own standard APIs, leaving the transactional core as the system of record. Replacing the core is a different decision, with a different horizon, budget and risk: it is not a prerequisite for having AI in the procurement cycle.

How do you guarantee that AI will not execute a financial transaction without authorization?

With written autonomy thresholds and mandatory human review before any result is applied. Agents generate drafts, comparisons and analysis; formal order issuance, budget commitment and payment happen inside the ERP's approval flows. Technically an agent could award on its own; it should not, because an award commits budget and is only defensible in an audit if someone signed it.

What happens to the integration when the ERP is upgraded?

If the integration uses only standard APIs and installs no developments inside the ERP, upgrades do not break it. In EGIXIA's SAP integration no Z developments or add-ons are installed and no code is transported into the client's landscape, so Support Pack or release upgrades do not affect the connection.

Who owns the supplier master in this architecture?

The ERP. The procurement layer manages the collaborative cycle with the supplier —onboarding, document validation and data updates— and syncs the outcome with the ERP record, without creating a second parallel master. In SAP, that record is the system's own supplier master.

Which data challenges are the most common in Latin America when integrating AI?

Fragmentation of the supplier master across subsidiaries and systems inherited through acquisitions, plus inconsistent categories between entities. Before feeding any model you have to deduplicate, validate tax identifiers and unify the taxonomy: that is the work that decides whether the pilot produces a result or a list of exceptions.

How long does it take to stand up the integration layer without touching the core?

It depends on the technology landscape, but a modular, phased scope lets you run the first use case without waiting for the whole project: you start with supplier registration and validation and scale by business object. At EGIXIA, implementation is measured in weeks, not months.

How do you ensure integration security?

TLS 1.3 for data in transit. Documents uploaded by your suppliers are stored encrypted with AES-256; database and volume encryption is enabled per project, according to the client's policies. The ERP connection uses OAuth 2.0 authentication and respects each ERP's roles and profiles; enterprise Single Sign-On (SAML) for user access is enabled per project, according to the client's policies. Connections are monitored continuously with automated detection. On certifications: Amazon Web Services (AWS) infrastructure is certified under ISO 27001, SOC 1/2/3 and PCI DSS; Egixia's own controls are aligned to ISO 27001 and validated by external penetration testing, whose executive report is available under a confidentiality agreement. Egixia is not ISO 27001 certified and does not hold an issued SOC 2 Type II report: the detail is in our Trust Center.

References

Sources consulted for this guide. The two market figures cited come from [3] and [4].

[1]DAX Software Solutions, Agentic ERP Architecture: Designing AI-Driven Enterprise Systems, abril de 2026. https://erpsoftwareblog.com/2026/04/agentic-erp-architecture-designing-ai-framework/
[2]Simfoni (Ryan Monte), How to Integrate AI Procurement Platforms with ERP Systems: Architecture, Challenges, and Best Practices, junio de 2026. https://simfoni.com/procurement-technology/how-to-integrate-ai-procurement-platforms-with-erp-systems-architecture-challenges-and-best-practices/
[3]Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, junio de 2025. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[4]Gartner, Gartner Predicts Embedded AI in Cloud ERP Applications will Drive a 30% Faster Financial Close by 2028, febrero de 2026. https://www.gartner.com/en/newsroom/press-releases/2026-02-24-gartner-predicts-embedded-ai-in-cloud-erp-applications-will-drive-a-30-percent-faster-financial-close-by-2028

Want to review this architecture against your own ERP?

Schedule a 30-minute conversation: we review your technology landscape, which objects you would need to sync and where to start without touching the core.

Schedule a conversation