# AI for ERPNext, Built on the Frappe Framework You Already Run

> Source: https://netray.co/erp-ai/erpnext-ai-integration
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: AI for ERP

## Short answer

AI for ERPNext connects a private LLM directly to Frappe's REST API and DocType model, so manufacturing, purchasing, and finance staff can ask plain-English questions about Work Orders, BOMs, and Job Cards and get answers grounded in live Frappe data. It runs beside your self-hosted bench or Frappe Cloud instance, keeping business data inside infrastructure you control.

## Kind

platform

## Erp Family

other

## Erp Products

- ERPNext
- Frappe Framework

## Industries

- Manufacturing
- Distribution

## Region

Global

## Persona

IT Director

## Eyebrow

ERPNext + Frappe + private AI

## Intro

ERPNext is unusual among ERPs in that its data model is genuinely transparent: everything is a DocType, every DocType has a REST endpoint, and the Frappe framework was built from day one to be queried and extended by developers. That openness is exactly why ERPNext has spread so widely among cost-conscious manufacturers and distributors, especially in India and other price-sensitive markets, and why so many companies run it self-hosted rather than on Frappe Cloud.

The same openness creates a different problem: because customization is so easy (a Server Script here, a Client Script there, a new DocType added in an afternoon), instances diverge quickly, and the people who understand the resulting structure are usually one or two developers who built it, not the operations or finance staff who need answers from it. Query Reports and the Frappe Insights module help, but both still require someone who can write SQL or configure a report definition.

ERPNext ships its own AI assistant features in recent versions, but like most vendor AI additions, they are tuned for general assistance rather than deep, auditable grounding in your specific Work Order, BOM, and Job Card data, and they are not built with an air-gapped or fully self-hosted deployment in mind. Manufacturers who chose ERPNext partly to avoid vendor lock-in and cloud dependency want the same independence from their AI layer.

This page covers how a private AI layer sits on top of ERPNext's Frappe REST API, what DocTypes and manufacturing objects it typically touches first, and the questions worth asking before connecting any AI tool, ours or anyone else's, to a production Frappe site.

## Pain Points

### Every customization is a DocType, and DocTypes multiply fast

**Detail:** Because adding a new DocType or field takes minutes in the Frappe Desk, instances accumulate custom fields and child tables quickly, and there is rarely documentation describing what each one is for six months later.

### Query Reports require someone who can write SQL

**Detail:** ERPNext's built-in reporting is powerful for anyone comfortable writing a SQL query or a Frappe Query Report, but that excludes most operations and finance staff who just want an answer to a specific question.

### Self-hosted bench upgrades carry real customization risk

**Detail:** Running your own bench (rather than Frappe Cloud) gives control over hosting cost and data residency, but every version upgrade risks breaking a Server Script or Client Script nobody has looked at since it was written.

### REST API integration needs careful key management

**Detail:** The Frappe REST API is straightforward to call, but a poorly scoped API key and secret can expose far more than intended; most instances have at least one integration with broader access than it actually needs.

### Talent familiar with both manufacturing operations and Frappe is uneven

**Detail:** ERPNext's community is strong for developers, but functional consultants who understand discrete manufacturing (routings, BOM explosion, capacity) as well as the Frappe framework are harder to find outside a handful of specialist partners.

## Use Cases

### Natural-language Work Order and BOM queries

**Description:** Production planners ask questions like "which Work Orders are behind schedule because of a missing raw material" and get an answer built from a live query against the relevant DocTypes.

**Erp Objects:** Work Order, BOM, Stock Entry, Item

**Outcome:** Replaces a daily manual scan of the Work Order list with a direct answer in seconds.

### Job Card shop-floor assistant

**Description:** Operators ask a floor terminal for the next operation, time logged so far, or linked Quality Inspection status without navigating the full Frappe Desk interface.

**Erp Objects:** Job Card, Workstation, Quality Inspection

**Outcome:** Cuts the number of supervisor interruptions for routine status questions on the floor.

### Purchase Order follow-up agent

**Description:** The agent reviews open Purchase Order items against promised delivery dates and drafts a follow-up communication to the supplier for a buyer to review before sending.

**Erp Objects:** Purchase Order, Purchase Order Item, Supplier

**Outcome:** Turns a manual morning review of overdue POs into a queue of drafted follow-ups ready for approval.

### Stock reconciliation exception review

**Description:** When a Stock Reconciliation shows a variance, the assistant summarizes recent Stock Entries and Job Card consumption against the affected Item to suggest a likely cause.

**Erp Objects:** Stock Reconciliation, Stock Entry, Job Card

**Outcome:** Shortens investigation time on recurring inventory variances that otherwise get written off without a real cause.

### Quality Inspection drafting

**Description:** When a Quality Inspection fails, the assistant drafts the non-conformance narrative with the relevant Job Card, Item, and prior similar failures already referenced.

**Erp Objects:** Quality Inspection, Job Card, Item

**Outcome:** Cuts the time to produce a usable non-conformance record and keeps the wording consistent across shifts.

### Multi-company consolidated reporting

**Description:** A single natural-language question resolves across every company in a Frappe multi-company setup that the requesting user has access to, instead of a separate Query Report per entity.

**Erp Objects:** Company, Work Order, Sales Order

**Outcome:** Gives group-level visibility without maintaining a custom consolidated Query Report by hand.

### DocType and Server Script documentation

**Description:** The assistant reads DocType definitions, Server Scripts, and Client Scripts to answer "what does this custom field actually do," turning undocumented customization into a searchable answer.

**Erp Objects:** DocType, Server Script, Client Script, Custom Field

**Outcome:** Reduces onboarding time for a new developer or administrator inheriting an under-documented instance.

## Architecture

**Overview:** The AI layer connects through Frappe's own REST API and respects Frappe's role-based permission system, so an answer only ever includes data the requesting user's role already permits inside ERPNext.

**Layers:**

#### Frappe connector

**Detail:** Connects via the /api/resource REST endpoints or the Frappe Client Python library using a scoped API key and secret tied to a dedicated read-focused user.

#### Semantic layer

**Detail:** Maps Work Order, BOM, Job Card, Stock Entry, and finance DocTypes, including custom fields and child tables, to the business terms planners and buyers actually use.

#### Model serving

**Detail:** An open-weight model served with vLLM or Ollama on customer-owned or customer-controlled GPUs, sized to typical ERPNext transaction volumes for small and mid-sized manufacturers.

#### Retrieval and agents

**Detail:** Retrieval-augmented generation grounds answers in live Frappe API queries; agents that draft purchase follow-ups or non-conformance records require human approval before any write.

#### Governance and audit

**Detail:** Queries and answers are logged against the requesting Frappe user and role, giving an audit trail consistent with what Frappe's own activity log would show.

## Deployment Options

### Air-gapped on-prem

**Fit:** Manufacturers running their own bench behind a firewall, especially those with export-controlled or customer-restricted data that cannot reach a public API.

**Detail:** The model and connector run on customer-owned hardware with no outbound path; MariaDB access stays entirely on the local network.

### Private or sovereign cloud

**Fit:** Companies on Frappe Cloud, or a self-managed VPS, who want AI capability without operating GPU infrastructure themselves.

**Detail:** Deployed in a dedicated tenant or VPC under the customer's own cloud account, separate from Frappe Cloud's own infrastructure and from any shared AI service.

### Hybrid

**Fit:** Groups running one bench per subsidiary or region after growth or acquisition.

**Detail:** A central retrieval and governance layer connects to each Frappe site through its own scoped API key, preserving per-site data residency rather than merging into a single database.

## Compliance

### Because the model runs inside customer-controlled infrastructure, personal data in HR or CRM DocTypes never transits a third-party AI API, simplifying data-transfer and lawful-basis questions.

**Framework:** GDPR / regional data protection

### For the large share of ERPNext deployments in India and other markets with emerging data-protection law, on-prem or in-country private cloud deployment keeps data residency straightforward to demonstrate.

**Framework:** India DPDP Act and similar regional regimes

### Manufacturers supplying OEMs with contractual restrictions on cloud AI use can point to an architecture where the model never leaves infrastructure they control.

**Framework:** Customer flow-down and NDA terms

### Role-based access logging tied to existing Frappe permissions and no external data egress give concrete answers for a customer vendor-security review.

**Framework:** SOC 2 expectations from downstream customers

## Integration Notes

- Connects through Frappe's REST API (/api/resource/<doctype>) or the Frappe Client Python library using a scoped API key and secret, not the Administrator account.
- Generated queries respect Frappe's role-based permission system and user permissions, so results match what the requesting user could already see in the Desk.
- Custom DocTypes, custom fields, and child tables are indexed automatically so the semantic layer stays current as developers extend the schema.
- Optional direct read-replica MariaDB connection for heavier analytical questions that would be slow through the REST API alone.
- Write-back actions (draft POs, non-conformance records, follow-up emails) route through a queued Frappe document a human reviews and submits, never a direct database write.
- Server Scripts and Client Scripts are read (not executed) by the documentation use case, avoiding any risk of triggering unintended automation.
- Compatible with self-hosted bench, Docker-based, and Frappe Cloud deployments; version differences across recent ERPNext releases are handled in the connector, not assumed away.

## Product Fit

### ERPray

**Why:** ERPNext's transparent DocType model, once mapped to a semantic layer, fits ERPray's grounded natural-language question answering well, particularly for planners and buyers who do not write SQL.

### Custom build

**Why:** Instances with significant custom DocTypes or unusual Server Script logic often need a bespoke connector and agent set built around the specific customization rather than a generic template.

## Engagement

### Discovery

**Duration:** 2-3 weeks

**Deliverables:**

- Inventory of custom DocTypes, fields, and relevant manufacturing/finance objects
- Review of existing roles and user permissions
- Priority use cases ranked by planner, buyer, and finance pain
- Deployment recommendation (self-hosted on-prem, private cloud, hybrid)

### Pilot

**Duration:** 6-8 weeks

**Deliverables:**

- Working connector against a non-production Frappe site
- 3-5 use cases live for a pilot group
- Accuracy review against known correct answers
- Governance and logging validated against existing Frappe roles

### Production

**Duration:** 4-6 weeks

**Deliverables:**

- Cutover to the production bench or Frappe Cloud site with a scoped API user
- Full audit logging in place
- Runbook for adding new use cases without a full redeploy
- Handoff documentation for your internal Frappe developer

### Scale

**Duration:** Ongoing

**Deliverables:**

- Expansion to additional companies in a multi-company setup
- Additional agent use cases with approval workflows
- Model refresh as open-weight options improve
- Quarterly review of usage and accuracy against real questions asked

## Buyer Questions

- Does the AI layer respect Frappe's role-based permissions, or does it use a broader credential than a normal user would have?
- Where does the model run, and can the network path be confirmed to show no data leaving our environment?
- How are custom DocTypes and fields kept current in the semantic layer as our developers add more of them?
- What happens when a bench upgrade changes a DocType schema the AI relies on?
- Is every generated query and answer logged against the requesting Frappe user?
- What GPU hardware is actually required, and can it run on infrastructure we already have?
- Can we start with read-only question answering before considering agents that draft or submit documents?
- If we stop the engagement, do we retain the connector code, prompts, and logs?

## Faq

### Does this work with a fully self-hosted ERPNext bench?

**Answer:** Yes. Self-hosted bench deployments are the most common setup for manufacturers who want AI on-prem, since the model, connector, and Frappe site can all run inside the same network boundary with no outbound dependency on a third-party API.

### How is this different from ERPNext's own built-in AI features?

**Answer:** ERPNext's native AI assistant is tuned for general help across the Desk interface and typically depends on an external API. A private AI layer is built specifically to ground answers in your DocTypes and to run entirely on infrastructure you control, with a full audit trail.

### Can it handle heavily customized DocTypes?

**Answer:** Yes, but the semantic layer needs to be mapped to your actual custom fields and child tables during discovery. Because Frappe makes customization so easy, this mapping step matters more for ERPNext than for less customizable ERPs.

### Does it require changes to our Frappe permission model?

**Answer:** No. The connector uses a scoped API key tied to a dedicated user and generates queries that respect the role-based permissions already configured. It works within your existing permission model rather than requiring changes to it.

### What happens if a bench upgrade breaks a Server Script the AI depends on?

**Answer:** Upgrades are treated as a planned, tested step, the same way any other integration or customization is retested. The connector and semantic layer are validated against the new version before cutover.

### Can the AI create or submit ERPNext documents directly?

**Answer:** It can draft a document, such as a follow-up email or a Quality Inspection note, but submission requires a human to review and approve through a queued workflow. Nothing writes directly to the database without that step.

### Is this affordable for a smaller ERPNext deployment?

**Answer:** ERPNext's cost-conscious user base is exactly why a right-sized deployment matters: a smaller model on modest GPU hardware, focused on two or three high-value use cases, keeps both the software and infrastructure cost proportionate to a smaller manufacturer's budget.

## Search terms

ERPNext AI, ERPNext AI integration, AI for ERPNext, on-prem AI for ERPNext, Frappe AI, ERPNext copilot, ERPNext generative AI, private LLM ERPNext, ERPNext natural language query, Frappe REST API AI, ERPNext self-hosted AI, ERPNext manufacturing AI

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json