AI Agent for Accounts Payable and Receivable: Prepare, Check, Never Pay

AI Agent for Accounts Payable and Receivable: Prepare, Check, Never Pay

An AI agent for accounts payable and receivable prepares and checks the repetitive work: it reads invoices and bank slips, matches them against purchase orders and contracts, builds the payment batch, suggests the reconciliation and drafts collection messages. It does not execute anything that moves money. Payments, write-offs, reversals and changes to a supplier's bank details go out only with approval from an identified person, with a record. The value is in reaching that approval with everything already checked, not in removing the person from the process.

Key takeaways

• The agent works on preparation and checking: reading documents, cross-matching, drafts, alerts and organized open items.
• Payments, write-offs, reversals, discounts and changes to a supplier's bank account always require human approval, enforced by a rule and not by a suggestion in the prompt.
• Permissions matter more than intelligence: the agent should have read access and draft-creation access, never the key that releases a transfer.
• Every agent decision must leave a record: what it read, what it compared, what it suggested and who approved.
• The safe path is to start with a single workflow and an agreed metric, and only then decide whether to expand, adjust or stop.

What does a superintelligence agent mean in finance?

The term shows up often in sales material, so it helps to be exact. No agent a company runs today is a superintelligence in the sense discussed in the literature. What exists is an AI agent with access to tools, one that reads, compares and proposes. If you want to understand the difference, read the article on AGI, ASI and AI agents.

In finance this matters for a practical reason. When a vendor promises an intelligence that solves everything, the temptation is to give it too much access. The safer approach follows what Anthropic itself describes when it talks about agents: start simple, use predictable workflows wherever possible and reserve autonomy for where it genuinely helps. In accounts payable and receivable, the useful autonomy sits in reading and checking. Any decision that sends cash out the door stays with a person.

What does the agent prepare in accounts payable?

Accounts payable involves a lot of work before anyone clicks pay. That is where the agent saves your team's attention. The most common preparation tasks:

• Receive documents from several sources (the finance inbox, a shared folder, a supplier's WhatsApp) and organize them into a single queue.
• Extract data from invoices, bank slips (boletos) and bills: supplier, company tax ID (CNPJ), amount, due date, document number, payment line.
• Suggest the classification: cost center, accounting category, project, based on history and company rules.
• Build the draft entry in the management system, marked as pending review.
• Group the week's due dates and propose a payment order, highlighting anything with a late fee or interest.
• Draft the question to the supplier or the requester when information is missing.

Notice that every verb is prepare, suggest, build or draft. None of them is pay. The agent hands over a package that is ready for a person to decide.

What does the agent check before any payment?

Checking is where an agent is usually most useful, because it is tiring for people and the rules are clear. A good set of checks:

• Three-way match: does the document agree with the purchase order and with the receipt of the service or goods?
• Duplicates: is there already an entry with the same supplier, amount and due date, or with a similar document number?
• Supplier: is the CNPJ registered, active in the internal database and identical to the one on the document?
• Destination account: are the bank details on the slip or bill the same as the ones on file? Any difference becomes a red alert.
• Amount and terms: is the value within the contract, the defined tolerance and the cost center budget?
• Taxes and withholdings: does the entry follow the rule your accountant defined, without the agent inventing a tax treatment?

There is one more risk that deserves its own attention. Documents received from outside are untrusted input. A PDF or email can contain text written to fool the model, such as a disguised instruction to ignore the rules or swap the account. This is called prompt injection, and the OWASP prevention guidance describes the defenses. In financial operations the main defense is structural: document content is treated as data, never as an order, and the agent has no permission to perform the dangerous action even if it is fooled.

And in accounts receivable: collection, reconciliation and write-off?

On the receiving side, the agent also prepares and checks, and the boundary is the same.

What it can do:

• Match the bank statement against open receivables and suggest the reconciliation, flagging what matched with certainty and what needs a human look (partial amount, grouped payment, payer different from the account holder).
• List overdue items by aging band and by customer, with the contact history.
• Draft reminders and collection messages in the tone the company has defined, for review before sending.
• Prepare a reissued bank slip or an updated due date, when policy allows it, as a draft.
• Separate discrepancies: overpayments, underpayments, unidentified payments and duplicate payments.

If collection goes out over WhatsApp, the channel's rules apply. An outbound message needs an approved template and the customer's permission, and the conversation has its own service window. Before automating any collection sequence, read about WhatsApp outbound messages, templates and opt-in and the 24 hour customer service window. Collection is also a relationship with the customer, and the wrong tone or timing costs more than the delay.

The write-off itself, which marks the receivable as paid and changes the customer's balance, is an action with accounting impact. The agent suggests, and the person confirms.

What never goes out without human approval?

This is the central part of the design. A useful rule: if an action is hard to undo, involves money going out, or changes data that protects the money, it goes through a person. A decision guide in list form:

• Payment of any amount: bank slip, PIX, wire transfer, corporate card. Individual or batch approval by someone with the authority to approve.
• Changes to a supplier's bank details: requires validation through a second channel (for example, a call to a contact already on file), made by a person.
• Write-off of a receivable: confirmed by whoever reconciles, especially for partial or mismatched payments.
• Granting a discount, rebate, installment plan or renegotiation: a commercial and financial decision, outside the agent's scope.
• Reversals, cancellation of a receivable and issuing a credit note.
• Registering a new supplier, or a new customer with a credit limit.
• Any exception to the rules: amount above tolerance, document without a purchase order, urgency requested by message.

Low-risk actions, such as classifying, reminding someone of a due date or requesting a missing document, can proceed without individual approval, as long as they are logged and reviewable.

The decisive technical point is where that rule lives. If it exists only in the model's instruction text, it is a recommendation. To be a real rule, it must be in the system permissions: the agent uses credentials that cannot release a payment. The OWASP authorization guidance covers this through the principle of least privilege and a permission check on every request. Applied to finance: approval happens in the banking system or the ERP, under the person's own user, and not through a chat reply.

One more detail is worth recording. When an approval triggers a payment through an API, the same order must not be executed twice because of a network failure or a retry. Payment providers solve this with idempotency keys, as Stripe's documentation on idempotent requests explains. Even if your bank or ERP uses a different mechanism, the question to ask the vendor is the same: what prevents a duplicate payment if the request is repeated?

Illustrative scenario: a supplier batch on Thursday

Illustrative scenario, not tied to any real company. A distributor pays its suppliers in a batch every Thursday. On Tuesday, the agent gathers the documents received, extracts the data and builds the entries as drafts. On Wednesday, it runs the checks and finds an invoice that looks like a duplicate of one already entered, a bank slip whose destination account differs from the supplier's record, and a bill with no associated purchase order.

On Thursday morning, the person in charge opens a screen with three groups. The first holds the items checked without reservation, with the reason for each check visible. The second holds the three alerts, each with the evidence side by side. The third holds what is still missing information, with the question to the requester already drafted. The person approves the first group, calls the supplier behind the mismatched slip on a phone number already on file, and sends the duplicate invoice back. The payment goes out through the bank, under their approval. The record keeps what the agent saw, what it suggested and who decided.

In this scenario the agent did nothing a good analyst would not do. It did it consistently, ahead of the deadline, and left a trail.

How do you roll it out without improvising?

The method we apply in AI projects has four steps: map, limit, pilot and hand over. In finance they look like this:

• Map: describe the current workflow as it really is, including who receives the document, where it is entered, who approves, which exceptions appear and where rework happens. Set a baseline to compare against later.
• Limit: decide which data the agent sees, which actions it can prepare and which stay blocked. Data about individuals, such as partners and freelancers, calls for attention to LGPD, and the ANPD is the official source for following guidance. If any workflow involves reviewing automated decisions about people, the article on LGPD automated decision-making and the right to review helps.
• Pilot: choose one small, real workflow, for example checking documents for a group of suppliers, with every decision logged and a metric agreed in advance. Test with fictitious data and a simulated environment before touching real data, as described in the guide on testing AI agents with mock tools and a sandbox.
• Hand over: deliver the operation with documentation, named owners and a routine for reviewing the record. At the end, decide with evidence whether to expand, adjust or stop.

A short checklist for the pilot review:

• Can the agent, technically, release any payment? The answer should be no.
• Does every alert have evidence attached?
• Is there a named owner for each type of approval?
• Does the record allow you to reconstruct a past decision?
• Is there a plan for when the agent makes a mistake or goes offline, and does the manual process still work?

To think about the architecture more broadly, the article on the company superintelligence layer in five building blocks shows how to separate context, tools, permissions and oversight. For risk management in general, the NIST AI Risk Management Framework is a useful reference for anyone who needs to document how the company identifies and handles AI risks.

Frequently asked questions

Can an AI agent pay bank slips on its own?

Technically it can, if someone gives it that permission, but we do not recommend it. The safer design keeps payment release with a person who has the authority, using their own credentials in the bank or ERP. The agent delivers the checked batch and the evidence, and the final decision stays human.

Do I need to replace my ERP to use an agent in finance?

Generally no. The agent can work with the system you already use, reading data and creating drafts through an integration or an export. What you need to verify is whether the system lets you create profiles with restricted permissions, because that is what supports the rule that the agent never releases a payment.

What is the difference between an AI agent and traditional automation in finance?

Traditional automation follows fixed rules and works well when documents are standardized. An agent handles variation better, such as invoices in different formats, loose emails and discrepancies that call for interpretation. In practice, the best design combines the two: a deterministic workflow for what is predictable and AI where judgment is needed, always with human approval on actions involving money.

How do I protect supplier and customer data when using AI?

Start by limiting what the agent can see to what the task requires, and log every access. Check where the data is processed and whether it is transferred outside Brazil, a topic covered in the article on international data transfer under LGPD when using AI providers. Also define who in the company is responsible for the processing and how long the record is kept.

Sources

• Anthropic: Building effective agents
• OWASP: Authorization Cheat Sheet
• OWASP: LLM Prompt Injection Prevention Cheat Sheet
• Stripe: Idempotent requests