Wiring an LLM agent to Acumatica means giving a model access to a real ERP through its contract-based REST API — the same OData-style endpoints Acumatica exposes for any external integration. The interesting design decisions are less about the LLM and more about what the agent is allowed to touch, how its actions are validated, and what happens when it gets something wrong.
The Acumatica REST API as the tool surface
Acumatica's contract-based REST API (exposed per endpoint, e.g. /entity/Default/23.200.001/) is the natural integration point for an agent, since it already models entities like SalesOrder, Bill, and Invoice with structured fields the model can reason about. Rather than exposing the raw API directly to the LLM, wrap each operation the agent needs — "look up a vendor bill," "check a customer's AR balance," "create a draft credit memo" — as a discrete function-calling tool with a narrow, well-typed schema. The model should never see a generic "call any endpoint" tool; that turns prompt injection or a bad inference into an unbounded blast radius.
tools = [{
"name": "get_vendor_bill",
"description": "Fetch a single AP bill by reference number. Read-only.",
"input_schema": {
"type": "object",
"properties": {
"bill_nbr": {"type": "string", "description": "e.g. 000123"}
},
"required": ["bill_nbr"]
}
}]
def get_vendor_bill(bill_nbr: str) -> dict:
resp = session.get(
f"{BASE_URL}/entity/Default/23.200.001/Bill/{bill_nbr}",
auth=acumatica_auth
)
resp.raise_for_status()
return resp.json()Read tools first, write tools behind approval
The safest architecture separates read-only tools (freely callable by the agent) from write tools (create/update/release) that always produce a draft or pending action requiring a human to approve before it commits. An AP automation agent, for example, can freely query open bills, vendor terms, and PO matches — but posting a bill or releasing a payment should land in a queue a controller reviews, not execute unattended on the agent's say-so.
If the agent needs to propose an amount — a credit memo total, a payment amount — have it reference the number from the source document rather than asking it to calculate or transcribe the figure freeform. LLMs are unreliable at exact arithmetic and can silently transpose digits. Pull amounts programmatically from the API response and pass them through untouched.
Grounding with RAG over ERP data
For questions like "what's our exposure to this vendor" that need synthesis across many records rather than a single lookup, a retrieval layer (embeddings over recent transaction summaries, indexed in a vector store) lets the agent pull relevant context before answering, instead of trying to reason over a dump of raw API responses. Keep the retrieval scoped to read-only reporting data — RAG is for answering questions, not for driving write actions.
Observability and guardrails
Log every tool call the agent makes with its full arguments and the model's stated reasoning, independent of whether the call succeeded. When an agent is wrong, the traceable failure mode is almost always in tool selection or argument construction, not the underlying LLM's language ability — and you only catch that with logs, not by re-reading the final answer.
Wrapping up
The pattern that holds up in production is a narrow, typed tool surface over Acumatica's REST API, a hard read/write split with human approval on anything that touches money, and grounding real numbers in API responses rather than model output. The LLM's job is intent and language; Acumatica's API and your validation layer are still the source of truth. If you are stuck on something specific, reach out or keep reading through the rest of the Acumatica blog.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.