AI in Company Finance Operations: What to Delegate and What to Lock

AI in Company Finance Operations: What to Delegate and What to Lock

How to use AI in accounts payable, receivable and reconciliation: what it reads and classifies well, and what stays in fixed rules and human approval.

••

Want to apply this in your company?

Book a call with Juan →

AI in Company Finance Operations: What to Delegate and What to Lock

AI in company finance operations works best when it reads and classifies: it extracts data from invoices and payment slips, suggests categories, interprets customer replies and proposes matches in bank reconciliation. Anything that moves money, such as paying, closing a receivable, collecting or changing bank details, should stay under explicit rules and a person's approval. This article separates the two in accounts payable, accounts receivable and reconciliation.

Key takeaways

  • AI is useful where the input is messy (PDFs, photos, emails, free text) and the output is a suggestion someone checks.
  • Deterministic rules should decide amounts, dates, limits, payment destinations and what can be closed automatically.
  • Human approval is mandatory for anything hard to undo: payments, reversals, discounts, renegotiations and changes to a supplier's bank account.
  • Reconciliation is the best starting point: the risk is low, the gain is visible and every suggestion can be audited.
  • A pilot with one workflow, a decision log and a metric agreed in advance shows whether to expand, adjust or stop.

What is the difference between reading and deciding in finance?

The most useful split is not between simple and complex tasks. It is between tasks that interpret and tasks that commit. Interpreting means turning a document or a message into structured fields: supplier, invoice number, due date, amount, likely cost center. Committing means doing something with a financial consequence: releasing a payment, closing a receivable, granting a discount, changing a supplier's Pix key.

Language models are good at interpreting text with no fixed format. They also make plausible mistakes: they return a well-formatted value that is wrong. So the output of AI in finance should always pass through a check that does not depend on the AI itself. Anthropic's documentation on building agents draws a similar line between workflows with paths defined in code and systems where the model directs its own process. In finance, the path of the money belongs in the first group.

A simple decision guide helps classify each task in your routine:

  • If the input is unstructured and the output is a reviewable suggestion, AI can help (reading an invoice, classifying an expense, summarizing a bank statement).
  • If the input is structured and the rule is known, use a fixed rule, no AI (checking an amount against a purchase order, blocking a payment above a limit, validating a company tax ID).
  • If the action is irreversible or changes money, require human approval, even when the suggestion comes from a rule or from AI.
  • If the task involves an exception, a negotiation or a relationship, AI prepares the context and a person decides.

This guide fits on one page and should be validated with the people who actually run finance, not only with leadership. Whoever reconciles every day knows which exceptions come up and which shortcuts already exist.

Accounts payable: AI reads documents, rules release payments

Accounts payable receives documents in many formats: NF-e XML files, PDF service invoices, payment slips photographed on a phone, supplier emails with the due date buried in the text. This is where AI has a legitimate role. It can extract fields, suggest the accounting classification, flag that an invoice looks like it comes from an existing supplier and summarize differences between the invoice and the purchase order.

What AI should not do is decide where the money goes. Some tasks are better left to rules and approval:

  • Three-way matching between purchase order, goods receipt and invoice, done by field comparison with a tolerance set by policy.
  • Changes to a supplier's bank details, which should require confirmation through an independent channel and approval by two people.
  • Release of a payment batch, with limits per approver and per amount.
  • Duplicate detection, done by an objective key (tax ID, number, amount, date) and not by the model's impression.

There is a specific risk few people consider: documents received from outside are untrusted input. A PDF or email can contain text written to manipulate the model, something the OWASP list of risks for LLM applications describes as prompt injection and excessive agency. If the AI that reads the invoice has permission to pay, any malicious supplier becomes a possible operator. The fix is structural: the AI that reads has no payment tool and only returns fields to a system that validates them.

Another safeguard is idempotency. When an integration sends a payment order or creates a receivable and the connection drops, the system may retry the call and duplicate the entry. Stripe's documentation on idempotent requests is a good example of how a provider avoids this with a unique key per operation. Require the same principle from any financial integration, including the ones you build yourself. If you run an ERP such as Omie, Bling or Tiny, you will find an overview of these decisions in integrating AI with Brazilian ERPs via API: Bling, Omie and Tiny.

Accounts receivable: AI understands the reply, the sequence decides what happens

In accounts receivable the work is split between invoicing, following up, collecting and closing receivables. AI helps mainly with language. A customer replies on WhatsApp that they paid yesterday, but the amount arrived partial. Another asks for a second copy. Another says they will pay on Friday and that the invoice has the wrong tax ID. Classifying these messages by intent (promise to pay, dispute, document request, request for more time) and summarizing the history for the analyst saves time without touching the money.

What should stay in rules:

  • The collection sequence: when to remind, through which channel, at what time and how many times.
  • Limits on discounts, penalties and interest, set in policy and not negotiated by the model.
  • Closing a receivable, which depends on confirmation in the bank statement and not on a message saying the customer paid.
  • Referral to legal or to formal protest, always with approval.

Tone matters too. A badly written collection message hurts the relationship and can create legal trouble. So the text sent should come from approved templates, with variables filled by verified data, and AI works on interpreting the reply. The details on limits and tone are in AI debt collection on WhatsApp: sequence, limits and tone. Because personal and financial customer data is involved, also review the legal basis and record keeping, covered in our guide to LGPD and artificial intelligence for companies.

Bank reconciliation: rules first, AI for what is left

Reconciliation compares what the bank shows (OFX, CNAB, statement API) with what the company has recorded. Most cases are solved by rule: same amount, same date, same document. Good reconciliation starts with this deterministic block because it is fast, cheap and explainable.

AI enters in the remainder, the entries the rules did not match. Typical examples:

  • An unidentified deposit that could correspond to several open items from the same customer.
  • A grouped payment, where the customer settled several invoices in a single transfer.
  • An abbreviated statement description that does not match the registered name.
  • Fees and bank charges that need an accounting classification.

AI proposes the match and the reasoning, and a person confirms. Over time, each human confirmation can become a new rule, which shrinks the remainder and improves the process without relying on guesswork. That is why reconciliation is usually a good first workflow: the error is visible, the suggestion is reviewed before it affects the books and the decision trail builds itself.

AI suggests the match, the rule validates the amount and a person confirms the entry.

For this to work, each suggestion must record which data was used, what the reasoning was and who approved it. Without that record, an internal or external audit has nothing to stand on.

Illustrative scenario: an invoice with different bank details

This is an illustrative scenario, unrelated to any real company. A distributor receives an invoice by email from a recurring supplier. The PDF has the usual fields, but a note in the footer asks for payment to be made to an account different from the one on file.

In a well-designed workflow, AI extracts the fields and picks up the note. A deterministic rule compares the stated account with the one on file and sees the mismatch. The system blocks the item from any payment batch and opens a task for the person responsible. That person confirms the change by phone or through a channel already known for the supplier, never by replying to the email received. Only after that, and with a second approval, is the record changed.

In a badly designed workflow, AI reads the note, updates the record because it seems reasonable and the payment goes out in the next batch. The difference between the two is not the quality of the model but who has permission to do what. The practice of separating input, output and action is covered in guardrails for AI agents: input, output and action controls.

How to start: a step-by-step pilot plan

The temptation is to automate all of finance at once. The safer path is to pick one workflow, limit what the AI can see and do, and measure. The method we use follows four moves: map, limit, pilot and hand over. In practical terms:

  • Step one, map: describe the current workflow from start to finish, who does each step, in which systems, and how much time and rework exist today. Without this baseline there is no way to know whether the pilot improved anything.
  • Step two, limit: define which data the AI can access (for example, the statement and open receivables, no card data) and which actions it can take. At the start, read and suggest only.
  • Step three, define approval: write down who approves what, up to which amount and within what time. A policy template is in AI agent approval policy: practical template.
  • Step four, pilot one real workflow: for example, reconciliation of a single bank account, logging each suggestion, human decision and reason for rejection.
  • Step five, evaluate with the agreed metric: the share of suggestions accepted is one option, as are closing time or the volume of exceptions. What matters is setting the criterion before you begin. See how to measure an AI automation pilot for metrics and decision gates.
  • Step six, hand over and decide: the team takes over operation, with documentation and monitoring, and the company decides whether to expand, adjust or stop.

The NIST framework for AI risk management helps organize this conversation around mapping, measuring and managing risk, without requiring any specific product. In a finance pilot, that translates into concrete questions: what is the worst possible error, who notices it, how quickly and how is it undone.

Also separate what is official documentation, what is implementation experience and what is still a hypothesis. Anyone selling financial automation with a promise of results and without this care is selling expectation, not method.

Frequently asked questions

Can AI approve and pay bills on its own? It is not recommended. AI can read, classify and suggest, but releasing a payment should follow limit rules and human approval, with a record of who authorized it. The risk of plausible errors and of manipulation through outside documents makes full autonomy needlessly dangerous.

Where should we start with AI in finance? With bank reconciliation or document reading in accounts payable, in suggestion mode. In these workflows the error shows up before it becomes a loss, the volume tends to be repetitive and the decision trail forms naturally. Choose only one and define the metric before switching anything on.

Is it safe to send financial data to an AI? It depends on what is sent, where and under which contract. Reduce it to the minimum necessary (avoid card data and unnecessary personal documents), define the legal basis and retention, and review the handling under Brazil's LGPD. If you have doubts about regulatory guidance, consult the ANPD's material and your company's legal counsel.

Do I need to replace my ERP to use AI in finance? Generally no. Many ERPs and financial systems used in Brazil offer an API or file export, and AI can work as a reading and suggestion layer around them. The point of attention is to give the integration only the permissions it needs, starting with read access.

Sources

AI in financeaccounts payablebank reconciliationaccounts receivableAI governance