Category: Cases

Last time I wrote about how an AI agent found an anomaly in sales at our client. Then the agent read data from ERPJS — statistics, invoices, GP. These are read operations: safe, with no side effects.

This week we made the next step — write operations through MCP. The same client, the same Telegram bot, but now the agent creates documents in ERPJS. At the moment I was writing this, I didn’t fully understand what would come of it. What came out was: one message → three ready documents in the system in 30 seconds.

This post is about a specific dialog that happened on May 3, 2026. Real client, real tax expenses, real documents in the ERP. And why this isn’t “automation of routine tasks” in the classic sense.

Context: a sole proprietor paying three monthly taxes

The client is the same small B2B distributor from the previous case. The owner has a separate sole proprietorship (ФОП) alongside the main company — common for many Ukrainian entrepreneurs. The ФОП pays three fixed taxes monthly:

• ВЗ — military levy
• ЄП ФОП — single tax for sole proprietors
• ЄСВ ФОП — unified social contribution for sole proprietors

In ERPJS, these are three expense documents per month. End of month — duplicate the documents for next month, adjust the sums (rates can change). Previously, done by hand: open April’s ВЗ document → “Make copy” → fix the date to May → fix the sum. Same with ЄП. Same with ЄСВ. 5-7 minutes, 90% routine clicking.

Round 1: the owner’s request

Owner, 09:56:
“Find 3 expenses: ВЗ, Single tax, ЄСВ. And make duplicates for May — with changed amounts: 900, 1730, 2000”

One message. No template, no specific function call, no document numbers. Just a description of the task in language the owner would use to explain it to a colleague.

Round 2: reconnaissance — the agent finds 3 existing documents

Agent: Found in April 2026:

• 🔍 №1432 — ВЗ ФОП · 750 UAH · April 2026
• 🔍 №1438 — Single tax ФОП · 1,580 UAH · April 2026
• 🔍 №1444 — ЄСВ ФОП · 1,800 UAH · April 2026

Create May duplicates with amounts 900, 1730, 2000 UAH?

The agent parsed the request itself: “ВЗ” → found a document of type “Military levy ФОП”, “Single tax” → found “ЄП ФОП”, “ЄСВ” → found “ЄСВ ФОП”. No mapping was programmed. The agent knows the ERPJS register schema and can search by document type + description + counterparty.

Note: the agent didn’t immediately rush to create. It showed what it found and asked for confirmation. This is the principled moment — more on it below.

Round 3: creation — 3 new documents as drafts

Owner: Yes

Agent: Done. Created 3 documents as drafts:

• ✅ №1545 — ВЗ ФОП · May 2026 · 900 UAH · Draft
• ✅ №1546 — Single tax ФОП · May 2026 · 1,730 UAH · Draft
• ✅ №1547 — ЄСВ ФОП · May 2026 · 2,000 UAH · Draft

Documents are not posted automatically — review and confirm in the system.

From “Yes” to “Done” — about 30 seconds. Three documents in the system, with updated amounts, with updated month, with correct references to counterparties and expense items. The owner opens ERPJS, sees three drafts, clicks “OK” on each — they get posted. Or wants to change one — clicks “Cancel”, the draft is deleted.

Why we chose this UX: drafts + confirmation

This is the principled part of the case. The accents matter.

Technically MCP imposes no such limit on write operations. The agent could create “posted” documents directly, with no draft status and no owner confirmation. It’s a UX choice on our part, not a protocol constraint.

Our default: the agent creates documents in “Draft” status, the owner confirms with one click. Why?

Because trust in an AI agent inside a real ERP is built by observation. The owner sees what the agent created, how it interpreted the request, what fields it filled. After a week or two — habit forms, drafts get skimmed. After a month, the owner can enable auto-posting for routine document types (e.g. monthly ФОП taxes). It’s a gradual process: human-in-the-loop first, more automation later where trust has been earned.

A draft in ERPJS is also a convenient error-catch point: it exists in the system but doesn’t affect balances or accounting postings:

• Not counted in P&L
• Doesn’t deduct money from cash balance
• Doesn’t appear in tax reports
• Deleted with one click without traces in accounting

If the agent makes a mistake (interprets “200” as “2000”, confuses ВЗ with ЄП), the owner sees it before the ERP has posted anything. But that’s a consequence of how we designed the workflow — not “MCP technical safety”.

A separate risk — and how it’s handled

What if the agent erred not in the sum, but in context? For example, created documents for the wrong counterparty.

ERPJS logs record:

• Who created the document → AI agent on behalf of a specific user
• Based on what input request → “Find 3 expenses ВЗ, Single tax, ЄСВ…”
• With which fields → with full JSON description of all attributes

So even if the error is noticed a month later — the audit log shows where the document came from, from whom, on what request. A standard internal audit tool, but AI operations are flagged separately.

Why this is not “RPA” or a “macro”

The classic approach to automating these tasks is RPA (robotic process automation) or a macro. They have limits:

1. RPA is set up in advance. Someone must pre-configure a rule “copy three documents from the previous month into the new month, replace such sums”. If the owner suddenly wants not duplicates but 6 documents for two months — or different logic — RPA needs reconfiguring.

2. RPA doesn’t understand context. RPA can’t tell “ВЗ” from “Military levy”. It needs the exact name. The agent figures it out itself.

3. RPA skips drafts. Most RPA scenarios post documents directly (it’s simpler). Error → fix it via a separate procedure. The draft-based agent — every document is reviewed by a human.

The same applies to “macros”: “click a button — 3 documents are created” is fixed logic. The AI agent accepts arbitrary phrasing and chooses which documents to create, how many, with which sums, for which month.

The honest part: where work still needs doing

This specific case worked. But that doesn’t mean MCP write operations are a finished product. What’s still needed:

• Confirmations for risky operations. The agent currently asks for confirmation only when it deems it necessary. We want a configurable threshold: creating a document over X UAH = automatic confirmation request, regardless of agent confidence.
• Bulk operations. If the owner wants to create 24 documents (full year ahead), they need confirm-all-with-one-click, not click each one separately.

I’m publishing this case publicly so we don’t have to wait for the “perfect product”. If you have ERPJS for small business — get in touch.

What the client says

“Hi. I’ve almost completely freed up my evenings for other tasks. All my main work in the system now happens during the day. Thank you!”

— owner, Telegram message (translated from Ukrainian), 2026-05-06

Context: the owner’s main system work — creating documents, reviewing reports, managing prices and inventory — now goes through the MCP-connected AI agent. Previously it ate up the evenings (daytime is for clients, phones, calls). Now it’s done in parallel with the day, in minutes. And messages of thanks like this one have been arriving steadily over the past month.

What this means for ERPJS clients

Previously, “an AI agent does something in my ERP” sounded like a risk. Now it’s a predictable workflow with a clear human role:

• Any document types. MCP covers the full ERPJS spectrum — expenses, invoices, transactions, sales documents. Not a curated subset of “what’s available so far”.
• Agent creates — human confirms. Default: drafts + one click. A UX tuned for gradual trust-building.
• Every operation has an author. Audit trail from a specific user, not “the robot did it”.
• No magic RPA scenarios. Owner writes in natural language, the agent figures it out.

This isn’t “AI replaced the accountant”. It’s “AI did 90% of the work, the human decides on the 10%”.

Frequently asked questions

Two weeks ago, I built an AI-agent in Telegram for a client — with a set of predefined operations. It worked well. Last Friday, I rewrote it as a regular button-based bot to optimize the budget. On Sunday, I realized that was a mistake. On Monday, I connected the agent to the ERPJS MCP server — and got something I didn’t expect.

This post is about a specific dialog that happened after that switch. Real client, real data, real questions. And an unexpected turn that I never programmed.

Context: a small business with 1000+ invoices

The client is a small B2B distributor. They’ve been on ERPJS for a while. All sales are in the system: 1000+ invoices for 2025, several currencies, FIFO cost basis on every line item.

Previously, the owner had a typical choice: spend hours clicking in the ERP UI, or ask me to build a custom report. Now he just types in Telegram, like writing to a colleague.

Round 1: the owner’s request

Owner: Which day of the week is the most profitable?

Agent: I have enough data — 1000 invoices from 2025. Summing revenue (fBaseSum4 in EUR) by day of week…

🏆 Most profitable day — Monday (~13,413 EUR for 2025)

Thursday and Tuesday are close (~12,156 and ~11,847 EUR respectively).

⚠️ Saturday barely works (~1,067 EUR), Sunday — only sporadic invoices.

💡 Data for 2025, 1000 confirmed invoices.

Notice the format of the answer. The agent on its own:

• Understood that “most profitable” needs to be measured in a single currency — and chose EUR as the base
• Grouped by day of week (note: dayofweek isn’t a field in the system; the agent calculated it)
• Spotted an anomaly (Saturday barely works) and commented
• Honestly stated the limits (only 2025, only confirmed invoices)

None of this query was programmed. There’s no “profit by day of week” report in the system — and there won’t be. The agent figured it out itself.

Round 2: clarification

Owner: Is this revenue or profit?

Agent: This is revenue (sum of invoices, fSum4 = Total per invoice).

Profit (gross) is revenue minus cost of goods sold. For that you’d need a GP (Gross Profit) report. Want me to look?

This is the most important moment of the dialog. The agent acknowledged the limits of its previous answer, not pretending to have answered the full question. This is the difference between an AI-assistant and an AI-analyst: an assistant gives an answer, an analyst recognizes when an answer is incomplete.

Round 3: the user teaches the agent

Owner: Do invoices update inventory in your setup? If so, the FIFO cost is in the invoice rows.

Agent: That’s what I needed! In the matrix there’s:

• fFIFO — FIFO cost per unit
• fFIFORowVal — FIFO cost per row
• fRowGP — gross profit per row

So the data for profit calculation is there. Want me to compute GP by day of week?

The owner explained the system architecture in one sentence. The agent found the relevant fields in the schema in a second and proposed the next step. This is collaborative work, not “I ask, you answer”. The agent absorbed the new knowledge and applied it immediately.

More on FIFO and financial accounting — in our financial accounting post.

Round 4: the final answer with the anomaly

Owner: Yes, you have GP per line and per invoice. Compute for April 2026.

Agent: Excellent — the report returned detailed data. Summing revenue (fBaseSum4) and GP (debet) by day of week…

Day	Revenue EUR	GP EUR	Margin %
Monday	~2,200	~510	~23%
Tuesday	~1,100	~240	~22%
Wednesday	~1,900	~490	~26%
Thursday	~1,700	~390	~23%
Friday	~1,500	~360	~24%
Sunday	~8,900	~1,650	~19%

🏆 Most profitable day in April 2026 — Sunday (~1,650 EUR GP)

⚠️ But this is almost entirely one invoice from 06/04 — a plotter for 6,678 EUR (margin only 17%). Without it, the leader is Monday (~510 EUR GP, ~23% margin).

💡 Wednesday has the best margin (~26%) — small retail sales without big discounts.

This is the moment I realized what happened. The agent:

1. Found an anomaly in the data — one invoice distorted the entire statistic
2. Recalculated without the anomaly — and gave a second, more honest conclusion
3. Surfaced an extra insight — about margin by day, which the owner never asked for
4. Switched timeframe without confusion — round 1 was the full 2025 (~13K EUR/Monday), here it’s April 2026 (~2K EUR/Monday). The agent understands “for April 2026” as a new context, not “continue with the same data”.

The owner asked “what’s the most profitable day”, and got an analytical reconnaissance: here’s the nominal answer, here’s where it comes from, here’s why it’s not entirely true, and here’s something else interesting we found.

Why this isn’t “ChatGPT with API”

Many people have heard about “AI-assistants” that hook GPT to an API and answer questions. This isn’t that. The difference is in three things:

1. The agent acknowledges its limits. A classic “GPT with API” gives the first plausible answer. Our agent volunteered: “this is revenue, not profit. Want to compute profit?”. This isn’t trained behavior — it’s a consequence of having access to the system’s structure, not just to a textual description of it.

2. The agent absorbs new knowledge. The owner explained FIFO in the matrix. The agent didn’t “forget” it 2 minutes later — it found the relevant fields in the schema and used them. It’s not magic, it’s architecture: MCP gives the agent access to register schemas, so a natural-language explanation instantly becomes an executable plan.

3. The agent finds things you didn’t ask about. Anomalies, margins, trends — none of these were in the question. The agent realized “Sunday 8,900 EUR” looked suspicious, checked, found a single big invoice, and gave a second version of the answer. This is analyst behavior — reporting not “what you wanted to hear”, but “what the data actually says”.

How it works: MCP in one paragraph

MCP (Model Context Protocol) is the standard through which AI agents access external systems. Instead of pre-programming a set of “tools” like “check stock” or “compute sales” — we expose direct access to the system to the agent through an MCP server. The agent itself decides what’s needed to answer the request. No additional programming for each new question.

The honest part: this is a prototype

I built this MCP server in one weekend. It’s field-tested on one client. This isn’t reference architecture, it’s a manifesto of intent.

What’s still needed:

• Expanding write operations — basics already work: the agent creates documents as drafts. Next up — more complex workflows (document chains) and automatic postings.
• Multi-tenant isolation — works now, but needs testing across more clients.
• Audit trail — all MCP calls are logged, but the format needs consolidation.

I’m publishing this case publicly so we don’t have to wait for the “perfect product”. If you’re an ERPJS user and want to try your own agent — get in touch.

What this means for ERPJS clients

ERPJS is already a system with open business logic for small business. Now an open MCP server is added. This means:

• Your agent — your choice. Claude, GPT, Gemini, custom — any that supports MCP.
• Your communication channel — your choice. Telegram, WhatsApp, Slack, web chat, voice bot.
• Your scenario — your choice. Analytics, operations, monitoring, reporting — all through the same MCP access.

You’re not locked in to a single AI vendor or a single interface form. ERPJS supplies data and operations, you supply the language.

Frequently asked questions