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