What an Accounts Receivable MCP Server Needs to Do

An accounts receivable MCP server is a service that exposes receivables data, and a controlled set of receivables actions, to an AI assistant through the Model Context Protocol, so the assistant can answer questions about aging, invoice status, payment history and dispute state without anyone pasting a spreadsheet into a chat window. Monk is an AI-native invoice-to-cash platform that runs invoicing, delivery, cash application and collections as one system, and the design questions that govern an AR MCP server are the same ones that govern any agent given access to a live ledger. The protocol is the straightforward half of the problem. The difficult half is the boundary between operations an assistant may run on its own and operations that must stop at a person before anything reaches a customer.

One point of scope first. This post describes what an AR MCP server would need to do, as a general capability any team could build or buy against. Nothing here is a claim that Monk ships an MCP server or a connector for any particular AI assistant. Monk's confirmed integrations are with QuickBooks, NetSuite, Salesforce, HubSpot, Stripe, Slack and Gmail, and Monk is SOC 2 Type II compliant. Controllers ask about this now for an ordinary reason: engineering colleagues wired an assistant into a database in an afternoon, and finance wants to know why the sales ledger cannot be treated the same way.

Why does an assistant with no tools give confident wrong answers about your ledger?

Because a model with no access to your data answers from the shape of the question rather than the state of the account.

Ask a general assistant which of your customers is the worst payer and it returns a well-formed method, an invented example and no facts. Paste in a CSV and it answers about the file you pasted, which was stale when you exported it. The Model Context Protocol closes that gap. A server declares tools, which are callable functions with typed inputs and outputs, resources, which are readable context, and prompts, which are reusable instruction templates. A host application discovers them and calls them, and every call becomes a discrete, schema-checked, loggable event.

Receivables data makes this harder than it sounds, because it is scattered. The invoice sits in the ERP, the payment in the bank feed, the contact in the CRM, the conversation in a shared mailbox, and the reason an invoice is stuck in somebody's memory. An AR MCP server is an aggregation and permission layer over all of those.

Which AR read operations are worth exposing first?

The ones a controller asks every week and currently answers by exporting to a spreadsheet.

Six reads cover most of the useful surface: aging, invoice status, payment history, contact records, dispute state and activity history. The detail counts more than the list. Invoice status has to go further than open or paid and carry delivery state, meaning whether the buyer's portal accepted the document and why it was rejected if it was. Payment history has to include partials, short payments with deduction reasons and unapplied cash. Contact records need a validity signal, so the agent knows whether the address on file has ever produced a reply.

Three properties make these reads safe. Every response carries an as-of timestamp, so an answer can be reproduced. Every object carries a stable identifier, so a follow-up call refers to the same invoice rather than a description of it. Every list is paginated with a hard cap, because an agent asked a broad question will request the whole ledger and reason poorly over a truncated answer.

Which write operations are dangerous enough to need a gate?

Anything a customer can see, and anything that moves money.

Customer-facing writes come first: sending a reminder or statement, posting into a buyer's portal, replying to an inbound thread. These are irreversible in the way that counts. A ledger entry can be corrected, but an email that reached a CFO cannot be recalled, and a badly aimed one costs a relationship rather than a record.

Money-moving writes come second: applying a cash receipt, writing off a balance, issuing a credit memo, processing a refund. Cash application errors are technically reversible and operationally expensive, because the correction travels through the ledger, the reconciliation and often the customer's own records. A credit memo is worse, being both an accounting entry and a commercial statement.

The third category is the one teams miss. Changing payment terms, placing an account on credit hold, escalating to an agency, amending a contact record. None of these send an email and all of them change what happens next. An agent that quietly updates the billing contact has changed where every future invoice goes.

Two requirements apply to every write. Each call needs an idempotency key, so a retry after a timeout does not send a second reminder or apply a receipt twice. Each needs a dry-run mode returning the exact artefact it would produce, because an approval gate is only as good as its preview.

What has to be inside an approval gate for it to be worth anything?

The final artefact, the reason it was proposed, and one reversible decision.

A gate that asks whether the agent may send an email to Acme is a rubber stamp with extra steps. A gate worth building shows the rendered message exactly as the customer will receive it, the recipients, the invoices and amounts referenced, the evidence used, and the policy rule that routed it to a human. The reviewer can approve, edit and approve, or reject with a captured reason. That reason is the most valuable data the system produces, because it tells you which policies are wrong.

Autonomy works better as tiers than as a switch. At the first tier the agent suggests and a person does everything. At the second it drafts and a person approves each item. At the third it acts inside a written policy, for example reminders under a stated value to customers with no open dispute, and reports afterwards. At the fourth it acts and escalates only exceptions. Move one segment of the book up one tier at a time.

Two failure modes deserve explicit design. Batch approval, where a reviewer accepts forty drafts in one click, restores the risk the gate removed. Stale approvals, where a draft approved on Monday sends on Thursday after the customer has paid, argue for a short expiry and a revalidation check before send.

How should auth, scoping and the audit trail be designed?

Per-user OAuth, least privilege scopes, short-lived tokens, and an append-only log recording the human and the agent as separate actors.

The server should act as the person using it rather than as a shared service account. If a credit controller cannot see the enterprise segment in the ERP, the assistant should not see it on their behalf. Scopes belong split by object and by verb, so a read-only deployment is a configuration rather than a promise. Amount caps and rate limits belong on the server, because a prompt is advice and a server check is a control.

An audit record for agent actions needs more fields than a standard application log: tool name and version, input arguments, output or error, the acting human, the agent identity and model version, the approval identifier, the idempotency key, the timestamp, and a pointer to the artefact produced. It must live outside the conversation history, because transcripts are deleted, edited and never designed as evidence. When a customer asks in six months what you told them, the log answers and the transcript does not.

Two procurement questions follow: where does the data go, and who processes it. A server run inside your own environment sends only the fields the assistant requests, which is a smaller surface than uploading exports. SOC 2 Type II is the usual baseline for any subprocessor in the path.

Why is an AR assistant only as good as the exception data underneath it?

Because the ledger records what is owed and almost nothing about why it has not arrived.

Take an invoice 47 days overdue. The accounting system knows the customer, the amount, the due date, the balance. It does not know that the buyer's portal rejected it for a missing purchase order line, that the goods receipt was never posted, that the certificate of insurance expired in March, or that a project manager mentioned a dispute on a call. Each of those is the reason, and none are in the ledger. Across the receivables Monk manages, 39% of cash flow slowdown is caused by edge cases, and 92% of enterprise invoices must be submitted through a vendor portal or network rather than paid from an emailed invoice.

An agent handed only ledger reads will answer anyway. Asked why an invoice is unpaid, it constructs a plausible story from due dates and payment averages, and the story is wrong in a way that is hard to detect, because it is written in the register of an analyst who has checked. More reads over the same shallow data do not fix this. Treating the exception as a first-class record does: a typed object with a reason code, an owner, the evidence, a state and a next action.

This is the part that is difficult to buy and difficult to fake. Exposing an aging report over a protocol is a week of work. A current, structured account of why each overdue invoice is stuck requires portal monitoring, inbound reply parsing and document tracking. An agent reading that layer can work a collections question. An agent reading a trial balance can summarise one.

How does Monk handle this?

Monk runs the exception layer as part of the platform and puts its own agents on top of it, with approval gates on the actions that reach a customer.

Connections to QuickBooks, NetSuite, Salesforce, HubSpot, Stripe, Slack and Gmail let the invoice, the customer record, the payment and the conversation resolve to one object rather than four. AI cash application matches 80% of receipts automatically, rising to 95% with suggested matching rules, which is the write operation most teams are least comfortable automating and the one where evidence is most checkable. Julia, Monk's AI agent for Intelligent Collections, works the follow-up on top of that data and achieves a 24% higher response rate than standard dunning, with 90% of collections resolved with zero human intervention. Intelligent Collections ingests the context of the conversation, so a reply about a missing purchase order changes what happens next. Customers see an average 40% reduction in DSO and save 26 hours a month. Monk manages more than $2B in accounts receivable and is SOC 2 Type II compliant.

That describes agents running inside Monk against Monk's own data model, and it is again not a claim that Monk publishes an MCP server. If the architecture matters to you, ask during evaluation.

Where should you start?

Write the tool list before you write any code, and put a human name against every write.

Take the twenty oldest overdue invoices and, for each, note the one question you would want an assistant to answer and the one action you would want it to take. Then check whether the answer exists in a system of record or in someone's inbox. The share living in an inbox is the size of your exception problem, and it is the ceiling on what any assistant can do for you.

Next, split candidate operations into three lists: reads an agent may run unattended, writes it may run inside a written policy, and writes that always stop at a person. Give each item in the second list a value cap and an eligibility rule you could hand to an auditor. If the rule takes more than one sentence, it belongs in the third list for now. To see the exception layer, cash application and Intelligent Collections running against your own ledger, book a demo.

Frequently Asked Questions

What is the Model Context Protocol in plain terms?

It is an open standard for connecting AI assistants to external tools and data. A server declares typed operations and readable resources, and a host application discovers and calls them. The integration is written once against a standard rather than rebuilt per assistant vendor. For finance teams the benefit is that every call becomes a discrete, schema-checked, loggable event.

Is a read-only AR MCP server useful on its own?

Yes, and it is the sensible first deployment. Read-only access removes the whole category of risk that involves a customer receiving something, while still answering the questions people export spreadsheets for. It also shows you which operations people call. Add writes once you know what is being asked.

Which AR write operations should never be automated?

Issuing credit memos, writing off balances, changing payment terms, placing accounts on hold and escalating to legal should require a person regardless of value. These are commercial decisions with contractual consequences. Sending a customer-facing message can be automated within a written policy, given a value cap, an eligibility rule and a full record. The test is whether a mistake costs a correction or a relationship.

How does auditability work when an agent takes the action?

The log records the agent and the human separately, because both are actors. For each call you want the tool and version, the inputs, the result, the approving person, the model version, an idempotency key and a pointer to the artefact produced. Store it outside the chat transcript. Without this you cannot answer a customer asking what you sent and when.

What stops an agent sending the same reminder twice?

Idempotency keys and a server-side check against activity history. A retried call after a timeout is common, and without a key the second attempt looks like a new instruction. The server should also refuse a send if an equivalent message reached the same contact inside a defined window, and revalidate before sending that the invoice is still open.

Does connecting an assistant to my ledger mean my financial data trains a model?

That depends on the provider terms you agree, and it is a contract question rather than a protocol question. Ask for the data processing terms in writing, check retention periods, and confirm the subprocessor list. Monk is SOC 2 Type II compliant, and Intelligent Collections ingests the context of the conversation to decide what to do next rather than training on customer data.

Can I build this against QuickBooks or NetSuite directly?

You can build the read operations against either API without much difficulty, and many teams have. The gap appears on the exception side, because neither system stores portal rejection reasons, missing goods receipts, expired compliance documents or unspoken disputes. You will also build the approval gates, the audit log and the idempotency handling yourself. Decide up front whether you are building a reporting assistant or a collections system.