ERP and CRM Integration

An AI agent that runs your business systems.

Ask for stock, issue an invoice, move a deal forward. In plain language, on your own data.

Field

Agentic AI · ERP and CRM integration

Proven in production

Moloni · TOConline · CRM sync · Built on Ardaven

The problem

Your ERP knows everything, and nobody can talk to it

Stock levels, price lists, open orders, every invoice, every customer. It is all in the ERP, behind forms, tabs, and a permissions matrix. Getting anything out, or in, is a job in itself.

So the work leaks out of the system built to hold it. Someone checks stock by walking to the warehouse. Someone keeps the real order book in a spreadsheet. A quote is agreed over WhatsApp and typed into the ERP two days later, if at all.

The result is a back office held together by workarounds:

None of this is a data problem. The data is fine. What is missing is a way to ask the systems for things and tell them to do things, in plain language, without opening a form.

How we approach it

Read and operate the systems you already have

We do not replace the ERP, and we do not copy it into a database of our own. The ERP stays the system of record. We put an agent in front of it that can read it and operate it.

The agent runs on Ardaven, LayerX's agent and knowledge platform, and connects to each system through a dedicated MCP server. Ardaven handles the conversation, the knowledge, and the policy. The MCP servers connect it to the ERP, the CRM, and everything else the company runs on.

1

A typed tool layer around each system

Every system gets its own MCP server: one for Moloni, one for TOConline, one for the CRM. Each exposes typed tools with a clear schema for what goes in and what comes back, built for that system rather than generated from a spec.

Pagination, rate limits, retries, authentication, and each vendor's version of the word "invoice" stay inside its server. Adding another ERP means writing another server, not rewriting the agent.

Credentials are scoped per tenant, so a customer's agent reaches that customer's data and nothing else.

2

Reads run freely, writes are bounded

Checking stock is safe. Issuing an invoice is not, because an invoice is a legal document.

So every operation carries a policy: run it, or prepare it and wait for a named approver. Checking stock and drafting a quote can run on their own. Issuing a fiscal document or writing off inventory can require a person. The boundary is configuration, so a customer starts strict and loosens it as trust builds.

Writes carry idempotency keys, so a timeout or a repeated request never issues the same invoice twice.

3

Set up against the customer's real process

A generic ERP agent is useless to a specific company. Ours is configured against the real thing: document series, warehouses, pipeline stages, VAT rules, product catalogue, naming.

Before anything is written, the customer named in a sentence is matched to a customer in the ERP, the product to a SKU, the order to an order. If a name is ambiguous, the agent asks instead of guessing.

The approach

Typed tools per system · reads free, writes bounded · the customer's own process, not a generic ERP.

What we build

One conversation, every system behind it

The team sees a chat box. Behind it are the ERP, the CRM, and whatever else the company runs on, reachable in one sentence instead of four applications.

01

One agent across every system

Nobody has to know which system holds the answer or which one needs updating. The agent picks the tools, calls them in order, and reports what the systems returned.

01How much of SKU 4471 is left in the Porto warehouse?
02Issue the invoice for this order.
03Move 20 units to the Lisbon warehouse.
04The client accepted the quote. Close the deal and bill it.

That last request is four systems' work in one sentence: mark the deal won in the CRM, turn the quote into an order, check the stock, issue the invoice in the ERP.

02

Stock and logistics that answer back

Stock is the question people ask most and the ERP answers worst, because the answer lives across warehouses, pending orders, and goods already committed. The agent covers:

  • Levels per warehouse and in total, including what is physically there versus what is already promised.
  • Movements and transfers between warehouses, entered as a sentence and recorded in the ERP as a proper document.
  • Reorder points and supplier orders, so "do we need to buy more of this?" has an answer before the shelf is empty.
  • Shipping and tracking, tied back to the order and the customer waiting for it.
03

Invoicing that is fiscally correct in Portugal

A fiscal document is regulated, sequential, and reported to the tax authority, so this is exactly where the policy layer earns its place.

The agent uses the company's real document series, applies the right VAT rate or exemption reason, and produces documents that carry ATCUD and the printed QR code, feed SAF-T (PT), and reach AT correctly.

The ERP stays in charge of what must not be improvised: Moloni or TOConline assigns the number, signs the document, and communicates it. The agent prepares the document, shows it in full, and issues it only when the policy allows.

04

Sales and CRM in step with the ERP

A deal in the CRM and a customer in the ERP are the same company. The agent gives them one identity across systems, matched on tax number rather than on how someone typed the name that day. From there the chain runs without re-typing: deal, quote, order, invoice.

What is agreed in the CRM becomes the document in the ERP, and what happens in the ERP is written back to the CRM, so the pipeline reflects invoices issued rather than optimism.

Proven in production

This is running, not a slide.

The tool layer is in production against real accounting and sales systems:

It builds on work we have already shipped.

The grounding from Company Brain handles the document side, so contracts, price lists, and internal policy inform an answer alongside live ERP records. Cadence applies the same idea to a factory: an agent operating on live operational data, not a dashboard about it.

How it works

Turning an API nobody enjoys into something you can just ask.

Underneath, it is the same machinery for any system with an API.

The askThe gateThe systemsRequestIssue the invoicefor this order.Resolved against real recordscustomerSKUorderPreviewwhat would be written, totals, tax treatmentRuns nowWaits for anamed approverExecute with an idempotency keyMCP · Moloniinvoices · documents · stockMCP · TOConlinefiscal documents · ATCUD · SAF-TMCP · CRMcustomers · deals · quotesConfirmed with the ERP's owndocument referenceAudit log · who asked · what was proposed · who approved · what returned
One operation, end to end. The agent resolves what you meant against real records, shows what it would write, and only then asks the policy whether it may. Every step lands in the audit log, with an actor attached.

Giving a system a tool surface

When we add a new ERP or CRM, we:

  • Read the vendor API once: its objects, its constraints, its failure modes, its idea of what a customer is.
  • Model it as typed tools, with explicit schemas for arguments and results, so an invalid call fails before it reaches the vendor.
  • Absorb the mess inside the server: scoped OAuth per tenant, token refresh, pagination, rate limits, retries with backoff, and error dialects translated into something the agent can reason about.

The same tool name then means the same thing whether it lands on Moloni or TOConline, which is what makes adding a system cheap. Ardaven discovers the tools each server offers, so a new capability appears without the agent being rewritten.

Running an operation

  • The request is read as an intent, and the entities it mentions are pulled out.
  • Those entities are resolved against real records, so a name becomes a customer ID and a product becomes a SKU. Ambiguity gets a question, not a guess.
  • A preview is built: exactly what would be written, to which system, with what totals and tax treatment.
  • The policy check decides whether it runs now or waits for a named approver.
  • It executes with an idempotency key, and the confirmation quotes the ERP's own document reference.
  • The whole thing lands in an append-only audit log: who asked, what was proposed, who approved, what the system returned.

Security and privacy

An agent with keys needs guardrails.

Credentials are least-privilege and scoped per tenant, so an agent reaches one company's systems with the permissions that company granted, and cross-tenant reads are impossible by design. Every read and write goes into an append-only audit log with the actor attached. Rate limiting absorbs spikes and abuse. GDPR and EU AI Act requirements are handled at the platform level, with EU hosting available.

When the data cannot leave the building, the whole stack runs inside the company's own perimeter: the models run on your infrastructure, next to the ERP, and nothing is sent to a third party.

What it delivers

The back office, operated in sentences instead of forms.

1place to ask
stock, invoices, and deals in one conversation
0double entry
what is agreed is what gets recorded
100%writes audited
each operation logged, with an actor attached
LayerChoice
PlatformArdaven, LayerX's agent and knowledge platform: conversation, knowledge, policy, and surfaces
SystemsMoloni · TOConline · other ERPs · CRM, each kept as the system of record
Tool layerOne MCP server per system · typed tools with explicit schemas · credentials scoped per tenant · vendor quirks absorbed inside the server
ReadsLive queries against the system of record · entities resolved to real records · ambiguity raised as a question
WritesPer-operation policy, autonomous or approval · previews before execution · idempotency keys · named approvers
FiscalDocument series · VAT rates and exemption reasons · ATCUD · QR code · SAF-T (PT) · AT communication, all issued by the ERP
SafetyLeast-privilege scoped credentials · no cross-tenant reads · append-only audit log · rate limiting · GDPR and EU AI Act handling · EU hosting · on-premise deployment with local inference

The result is a back office where asking and doing are the same action. Stock questions get answered where they are asked, documents get issued the moment they are agreed, the CRM and the ERP tell the same story, and nobody spends the afternoon re-typing a spreadsheet into a form.

Beyond ERP and CRM

Any system with an API becomes something you operate.

ERP and CRM are the showcase, not the limit.

Billing, ticketing, HR, e-commerce, banking, logistics, internal back offices: anything with an API can be given a tool surface and put behind the same agent, with the same policy deciding what runs on its own and what waits for a person.

Wherever people spend the day moving information between systems that were never introduced to each other, that work can become a conversation.

Let's wire an agent into your systems.

We build the AI and integration layers that let a company operate its own software in plain language, pairing real depth in agents and systems integration with modern software practice, and built to be safe, secure, and compliant for the EU.

If that sounds like your situation, let's talk.

Let's Talk