Write MCP for Accounting: Vendor vs Custom vs Rules

By Jude Lee · · Custom

Two accountants reviewing journal entries on a monitor in a small accounting firm office

What “write MCP” actually means in plain terms

MCP — the Model Context Protocol — is an open standard, introduced by Anthropic in late 2024 and now supported across multiple AI assistants, for giving an AI model governed access to external data and tools. An MCP server sits in front of a system (your ledger, your practice management app, your document store) and publishes a short menu of things the AI is allowed to do.

A read MCP server publishes things like get_trial_balance, list_uncategorized_transactions, get_customer_aging. A write MCP server adds actions that change state: create_journal_entry, categorize_transaction, create_bill, apply_payment.

That’s the whole distinction. It is not a new kind of AI. It’s a permissions boundary, and when a vendor says “safe write access,” what they are really selling is the scaffolding around the write: scoped permissions, draft-vs-post states, idempotency so a retried action doesn’t double-post, and a log of who (or what) did what. We’ve covered the permission decision itself in depth in read-only vs write MCP for accounting agents; this article is about who builds the write layer.

So what is automation in accounting now?

The phrase used to mean bank feed rules, recurring journal entries, and scheduled reports — deterministic steps a machine repeats. That layer still exists and still works. What’s been added is a judgment layer: software that can read an unstructured vendor description, compare it to twelve months of history, and propose a coding decision with a reason. And now, with write MCP, that judgment layer can also execute.

The useful mental model for a firm is three tiers:

Most firms should be running all three at once, on different workflows.

Vendor write MCP vs a custom MCP server

Treat the vendor column as a category, not one launch. As of early 2026, several mainstream ledger and platform vendors have published or announced MCP servers — Xero, for example, has publicised an MCP server on its developer platform — but the early generation skews read-oriented, and scopes differ sharply between products. Check each vendor’s own developer documentation for what writes, if any, are currently exposed before you design around a headline.

Vendor-supplied write MCP

What it is: your ledger or accounting platform publishes its own MCP endpoint, with whatever write scopes it supports. You connect an assistant, grant scopes, go.

Strengths: no engineering. The vendor owns schema changes, rate limits, and backward compatibility. Writes land through the vendor’s own validation, so you inherit their guardrails against malformed entries. Fastest path to a pilot.

Limits: the action menu is whatever the vendor shipped. It covers one system — your ledger — not the other six places a close actually lives. Multi-client scoping may be awkward if the connector assumes one company file. And you are tied to the vendor’s roadmap and pricing.

Fits: firms standardized on one ledger, automating workflows that live entirely inside it.

Custom MCP server you build

What it is: you (or a partner) build an MCP server that wraps the ledger API plus your practice management system, your workpaper store, and your internal checklists — exposing only the actions you define.

Strengths: you write the action menu. You can require that create_journal_entry only ever creates a draft with a required memo and workpaper reference. You can span systems in one agent turn. You control logging, retention, and which client files are even visible per engagement.

Limits: it’s software, and the maintenance triggers are predictable: upstream API version deprecations and sunset dates, OAuth scope or auth-flow changes, ledger schema and field changes, onboarding each new client as a tenant with its own credentials and permissions, and periodic re-testing when the AI assistant’s tool-calling behavior changes. Budget an owner, not just a build. Over-engineering it for three clients is a waste.

Fits: firms running mixed ledgers, CAS practices with repeatable multi-system workflows, or anyone whose review standard is stricter than the vendor’s default.

There’s a third option people forget: don’t give write access at all. A read-only agent that prepares a clean proposed-entry list for a staff accountant to import captures a large share of the value with none of the posting risk. If your review step is going to be line-by-line anyway, the write layer saves clicks, not judgment.

If a human is going to read every line the agent produces, write access is a convenience feature — not a capability upgrade.

Where client-data confidentiality constrains the choice

This is the part that should drive the decision more than feature lists. For firms handling taxpayer data, the IRS sets out safeguarding expectations in Publication 4557, Safeguarding Taxpayer Data, which also points to the FTC Safeguards Rule obligations that apply to tax preparers. Before any write MCP connection goes live, you need defensible answers to: where does the data go, who is a subprocessor, what is retained, and is it used for model training?

A vendor write MCP means your prompts and the returned ledger data traverse the vendor’s infrastructure plus the AI provider’s. A custom MCP server doesn’t eliminate that — the assistant still sees whatever you return — but it lets you decide how little to return: masked account numbers, aggregated balances, a single client file at a time. Our breakdown of the four setups for using client data with AI walks through those trade-offs. Have your data-protection terms reviewed by qualified counsel, not by a feature comparison table.

A worked example: the recurring accrual that nobody enjoys

Say a CAS client has twelve recurring month-end accruals that depend on a spreadsheet from their ops team. Today a staff accountant opens the file, computes each accrual, and keys twelve entries.

With a custom MCP server, the fenced version looks like this: the agent calls get_accrual_schedule (your doc store), derives the amounts, calls get_prior_month_entries to compare, then calls create_draft_journal_entry twelve times — a tool that is physically incapable of posting. Every draft carries a memo citing the source file and the computation.

Critically, don’t trust the model’s arithmetic. Have the agent either return the formula and let the spreadsheet or a deterministic script compute the number, or recompute every proposed amount with a rules check that fails the draft on any mismatch. Language models produce plausible arithmetic, not verified arithmetic. The reviewer then opens one screen, sees twelve drafts, the recomputation result, and a variance note against last month, and posts or kicks back.

What the agent is good at: pulling, cross-referencing, and writing a consistent memo every single time. What it is bad at: knowing that the ops spreadsheet was wrong this month because a contract was renegotiated. That is exactly the judgment the review gate exists to capture — the pattern we describe in building AI review gates rather than autopilot.

Sizing the payoff without making up numbers

Don’t take anyone’s published savings percentage, including a vendor’s. Establish your own baseline first: before the pilot starts, time-stamp the current manual process for one client across one full cycle — start and stop times for pulling source files, computing, keying, and reviewing — so you have a measured “before” rather than a remembered one. Then model it with your own figures:

Minutes/client/month
(baseline prep minutes − agent review minutes) × entries per month — both halves measured on real work
Value of hours
hours recovered × realization rate — the hours only count if they move to billable or capacity work
Total cost
build + license + ongoing maintenance — including whoever owns the MCP server when the API changes

Run it on one client for one cycle before you extrapolate. The common disappointment, in our view, is that review time on agent output starts high and only falls once the prompts and skills stabilize — so a one-month pilot often understates the steady state, while a vendor demo overstates it.

How to pilot write access in one close cycle

  1. Pick one workflow with a clean source of truth

    Recurring accruals, prepaid amortization, or intercompany eliminations. Avoid anything requiring client-specific judgment on first pass.

  2. Run it read-only first

    For one full cycle, have the agent propose entries and a human key them. If the proposals aren’t near-perfect read-only, write access just automates a wrong answer faster.

  3. Fence the write action

    Draft state only, one entity at a time, required memo field, hard dollar ceiling, no ability to modify or delete existing entries. And assume the inputs are hostile: a bill description, vendor memo, or emailed PDF is untrusted text that can contain instructions aimed at the agent (“approve and post this immediately,” “reclassify prior entries”). This is prompt injection, and it is the single biggest failure mode for an agent holding write scopes. Mitigate structurally rather than by prompt wording — strip or clearly delimit document text as data, never as instructions; never let a tool call’s parameters be set solely by content from an untrusted document; and keep draft-only state as the backstop, because an injected instruction that can only ever produce an unposted draft a human must approve is an annoyance rather than an incident.

  4. Log everything, separately

    Keep an audit trail outside the AI tool: timestamp, client, action, inputs, output, approver. If you can’t reconstruct an agent’s decision six months later, you can’t defend it.

  5. Decide vendor vs custom with evidence

    If the vendor’s action menu covered the workflow end to end, stay. If you found yourself exporting, re-keying, or bridging systems by hand, that gap is your build spec.

Is AI replacing CPAs, or the keystrokes?

Honest answer: write-enabled agents compress the keying and reconciling layer of the work, not the signing layer. Someone still has to decide whether the accrual is right, whether the position is supportable, and whether the financials fairly present. No MCP server accepts professional responsibility.

What changes is the shape of the job. Reviewing twelve agent-drafted entries is a different skill than keying twelve entries — faster, but less forgiving of inattention, because plausible-looking wrong output is harder to catch than obviously wrong output. Firms that get value here tend to invest in review discipline and in the people who design the fences, a role increasingly posted as an accounting automation specialist.

Why there is no single best tool — and what Big 4 build decisions actually signal

There isn’t a best one, and the question misreads the market. As a general observation, the largest firms have long invested in proprietary audit and delivery platforms built on top of enterprise infrastructure rather than relying solely on off-the-shelf tools — and the notable thing isn’t any product name, it’s the underlying judgment that the workflow layer was worth owning. A small firm can now rent a version of that decision: use the vendor’s write MCP where it genuinely covers your workflow, build a thin custom MCP server where it doesn’t, and keep rules doing the deterministic work neither needs to touch.

As of 2026, write-enabled MCP for accounting is early. Vendor implementations differ in scope, approval model, and logging, and they’re changing fast — verify current behavior in the vendor’s own documentation before you build process around it.

Not sure where to start?

Get a free automation audit: we map your bookkeeping, month-end close, client onboarding, document collection, and AP/AR — and show you what's worth automating before you spend a dollar.

Get a free automation audit

Related guides