ERPNext Natural-Language Reporting: Ask Your ERP in Plain English (2026)

I am Manoj, an ERPNext implementation consultant at Mith Tech in Bengaluru, and I set up plain-English reporting for Indian SMBs who are tired of waiting on someone to build a report every time a question comes up. This post is the "how it works and where it fits" companion to my step-by-step MCP connection runbook.

The honest take: natural-language reporting is genuinely useful for exploration and quick answers, but it is an assistant, not an auditor — you still verify anything that goes into a board pack or a filing.

What is natural-language reporting in ERPNext?

Natural-language reporting means asking your ERP a question in ordinary English and getting a data-backed answer, instead of building a report by hand. Rather than choosing DocTypes, filters, and columns, you type "show me this quarter's top ten items by sales value" and receive the result. ERPNext gains this ability when an LLM sits in front of it and translates your question into structured queries.

There is no magic engine hidden inside ERPNext doing this. The workflow is: an LLM interprets your intent, decides which ERPNext data it needs, calls the right tools over MCP, and phrases the result back to you. ERPNext supplies the live data and enforces permissions; the model supplies the language understanding. That split is why the feature is model-agnostic — swap the LLM, keep the same ERPNext setup.

Skimmable summary: Natural-language reporting is asking ERPNext a plain-English question and getting a data-backed answer — an LLM interprets intent and queries ERPNext over MCP, while ERPNext supplies the data and enforces permissions.

How does asking ERPNext in plain English actually work?

Plain-English reporting works through three layers: your question, a translation layer, and your data. You type a question into an LLM; the model maps it to one or more tool calls exposed by an MCP server running on ERPNext; the server executes those calls under your permissions and returns structured results; the model then summarises them in words, a table, or a chart. Nothing leaves your database except the specific answer.

The translation layer is the key idea. Frappe Assistant Core publishes ERPNext's data and actions as named tools — search records, generate a report, run an analysis, draw a chart — using the open Model Context Protocol standard. The LLM does not see your whole database; it picks a tool, sends a scoped request, and gets back only that result.

Here is what happens when you ask "which five customers owe the most right now?":

Skimmable summary: Your question goes to an LLM, which calls scoped ERPNext tools over MCP; ERPNext runs them under your permissions and returns only the answer, which the model phrases as text, a table, or a chart.

What do you need to set up plain-English reporting?

Setting up natural-language reporting needs three things: an ERPNext site you can install apps on, the Frappe Assistant Core app installed and its MCP endpoint enabled, and an MCP-capable LLM connected to that endpoint. For reporting specifically, you also want a read-scoped ERPNext user — reporting never requires write access, so scoping the user to read-only removes most of the risk in one step.

The essentials, in order:

1. A Frappe/ERPNext site you can add apps to — self-hosted with bench access, or a managed Frappe Cloud site where you add the app from the marketplace.
2. Frappe Assistant Core installed and its MCP endpoint switched on. It is open source under AGPL-3.0, so there is no licence fee for the bridge itself.
3. An MCP-capable LLM — Claude or ChatGPT both act as MCP clients. You pay only for the model you use; pricing varies by provider and plan, so check the vendor's official page.
4. A read-only ERPNext user for reporting, scoped to just the DocTypes you want to query.

For the full install-and-connect walkthrough — bench commands, the OAuth flow, plan tiers — follow my connect ERPNext to ChatGPT and Claude guide, which is the runbook I actually use on client sites.

Skimmable summary: You need an install-capable ERPNext site, Frappe Assistant Core with its MCP endpoint enabled, and an MCP-capable LLM — plus a read-only user, since reporting never needs write access.

What questions can you ask ERPNext in plain English?

Reporting questions that map to data ERPNext already holds work best — receivables, sales trends, stock levels, purchase patterns, and cross-DocType lookups. Good questions are specific about the metric and the time window: "total sales by territory last quarter" beats "how are we doing?" The model handles the filtering and grouping you would otherwise build by hand in Report Builder.

A sense of the range that works well on a typical ERPNext site:

The pattern is that anything you could express as a filtered, grouped report, you can now ask as a sentence. Where it gets weaker is fuzzy, judgement-heavy questions and anything needing data ERPNext does not store — the model will try, and that is exactly where you must verify.

Skimmable summary: Ask specific, metric-and-timeframe questions that map to data ERPNext holds — receivables, sales, stock, purchasing, trends, lookups. Anything expressible as a filtered report works; fuzzy or out-of-system questions are where accuracy drops.

Natural-language reporting vs Report Builder vs Query Report

Each tool suits a different job. Report Builder and Query Report are ERPNext's built-in, repeatable, exact reporting tools; natural-language reporting is the fast, exploratory layer on top. The strongest setup uses plain English to discover what you want to know, then saves the recurring questions as proper Report Builder or Query Reports so they run the same way every time.

Skimmable summary: Report Builder and Query Report are exact and repeatable; natural-language reporting is fast and exploratory. Explore in plain English, then save the queries that matter as real reports.

How does this compare to AI reporting in proprietary ERP suites?

The core difference is the model and the money. Proprietary suites increasingly bundle an AI reporting assistant, but it is tied to that vendor's platform, that vendor's chosen model, and typically a per-seat subscription — pricing varies by edition, so check the vendor's official page. ERPNext's approach is open: the ERP is free and open source under GPLv3, the MCP bridge is open source, and you bring your own LLM.

That openness has practical consequences. You are not locked to one model — if a better or cheaper LLM appears, you point the same MCP endpoint at it. Your data stays in your ERPNext database rather than being processed through a suite's proprietary AI layer. And because the connector is community-maintained open source, you can read exactly what it does and disable tools you do not want.

The honest trade-off: a bundled suite feature is turnkey, while the ERPNext route asks you to install an app, connect a model, and scope permissions yourself. That setup is modest, but it is real work — which is where an implementation partner earns their keep.

Skimmable summary: Proprietary suites bundle a turnkey AI assistant tied to their platform, model, and per-seat subscription. ERPNext keeps it open — free GPLv3 ERP, open-source bridge, your own LLM, your own data — at the cost of setting it up yourself.

Where does Raven fit for natural-language reporting?

Raven is ERPNext's open-source team-chat app, and its v2 AI agents can answer questions and run tasks inside ERPNext, which overlaps with reporting. The distinction is location and purpose: the MCP bridge brings ERPNext into an external LLM for open-ended analysis, while Raven puts a scoped assistant inside ERPNext for repeatable, in-context jobs. Many teams run both.

For pure ad-hoc reporting — "let me poke at the numbers" — the MCP bridge into Claude or ChatGPT is usually the more flexible route, because you get the full model in a general chat interface. Raven shines when you want a defined assistant living where your team already works, or you are pairing reporting with actions like logging an expense. One caution worth knowing: Raven's agents were built on OpenAI's Assistants API, which OpenAI has deprecated with a sunset date of 26 August 2026, so if you adopt Raven agents, confirm your version has a migration path. The MCP reporting bridge does not depend on that API.

For the full picture of what ships and what does not, see my honest look at ERPNext's AI features and my guide to what Raven is and how to set it up.

Skimmable summary: Raven puts a scoped AI assistant inside ERPNext; the MCP bridge puts ERPNext inside an external LLM. Use the bridge for open-ended reporting and Raven for in-context jobs — but note Raven's Assistants-API dependency sunsets 26 August 2026.

Frequently asked questions

Does ERPNext have built-in natural-language reporting?

Not as a single native engine. ERPNext ships Report Builder and Query Reports natively, but plain-English querying comes from adding the open-source Frappe Assistant Core app (which exposes ERPNext over MCP) and connecting an LLM like Claude or ChatGPT. The capability is real and free to assemble, but it is a combination of open-source parts plus your chosen model, not a button inside stock ERPNext.

Is natural-language reporting in ERPNext accurate enough to trust?

It is accurate for exploration and quick answers, but you should verify anything that matters. The LLM infers which query to run, and on clear, well-scoped questions it is reliable; on ambiguous ones it can pick the wrong cut of data. My rule: cross-check the first answers against a known ERPNext report, and rebuild any recurring or official report as a saved Report Builder or Query Report so the logic is deterministic.

Does the AI see all my ERPNext data?

No. Every query runs under the ERPNext permissions of the user who authorised the connection, so the model can only report on data that user is allowed to see. Frappe Assistant Core enforces this at the ERPNext layer — it does not hand over the database. For reporting, scope that user to read-only on just the DocTypes you want queried, and the model physically cannot reach anything else.

Do I need to write SQL for plain-English reporting?

No — that is the point. You ask in ordinary English and the LLM handles the translation into ERPNext queries. SQL and Query Reports remain the right tools when you need exact, repeatable, complex logic, but for everyday exploration you no longer need to author them. A useful pattern is to explore in plain English, then have a developer formalise the valuable queries as saved reports.

Which LLM should I use for ERPNext reporting?

Any MCP-capable model works — Claude and ChatGPT both act as MCP clients against the same ERPNext endpoint, so you are not locked in. Choose based on your team's existing subscriptions, data-handling preferences, and read/write plan requirements; pricing varies by provider and plan, so check the vendor's official page. Because the endpoint is model-agnostic, you can switch later without touching the ERPNext side.

Can I schedule or save a natural-language report?

Not directly — a plain-English question is asked fresh each time and is not, by itself, a saved artifact. If you want a report to run on a schedule or appear the same way every time, rebuild it as a Report Builder or Query Report inside ERPNext, which supports saving, scheduling, and sharing. Treat natural-language reporting as the design tool and the native report as the durable output.