Bank Reconciliation With AI: What to Automate and What to Check

Bank Reconciliation With AI: What to Automate and What to Check

Bank reconciliation with AI works best when you split it into two parts. Deterministic rules resolve the clear entries, where amount, date and identifier all match. AI handles only the ambiguous cases, suggesting a match that a person approves or rejects. Closing out receivables and payables, adjusting balances and posting differences remain decisions with an audit trail, not free actions by the model.

Key takeaways

• Start with rules: most of the volume can usually be resolved without any language model, which is cheaper, more predictable and easier to audit.
• Use AI to suggest, not to decide: it proposes a match with a justification, and a person approves before anything is posted.
• Separate reading from writing: the agent can read bank statements and the accounts payable and receivable, but posting and settling should require approval.
• Log every suggestion, approval and rejection, because that history is what lets you measure and improve the process.
• Pilot with one account and one type of entry before expanding, with a success criterion agreed in advance.

What is bank reconciliation and where does it usually get stuck?

Reconciling means comparing what the bank recorded (the statement) with what the company recorded (the ERP, the spreadsheet or the financial system) and explaining every difference. In theory it is a mechanical task. In practice it gets stuck in predictable places.

The first is the grouped entry: a single deposit from the card acquirer that bundles several card sales, already net of fees. The second is the partial or combined payment: a customer pays two invoices in one Pix transfer (Brazil's instant payment system), or pays one invoice in two installments. The third is the poor statement description, where the payer's name is abbreviated, truncated or belongs to someone else (a partner, the accountant, a group company). The fourth is small, recurring differences: bank fees, interest, rounding and clearing delays.

The key point is that these cases are not equally hard. Treating everything as an AI problem is as common a mistake as treating everything as a spreadsheet problem.

What should you automate with deterministic rules?

A deterministic rule is one where, given the same inputs, the result is always the same and can be explained in one sentence. In reconciliation, that covers a large share of the work.

Good candidates for fixed rules:

• Exact match on amount and date, with a unique identifier present on both sides (for example, the Pix transaction ID, your own boleto number or the authorization code). A boleto is a Brazilian bank payment slip.
• Match on amount and date within a defined tolerance window, when only one candidate is possible.
• Known recurring entries, such as the monthly bank fee, a service package and a fixed-amount debit from a supplier.
• Reversals and refunds with an explicit reference to the original entry.
• Transfers between the company's own accounts, which appear as an outflow on one side and an inflow on the other.

Keeping these rules outside the model has two benefits. First, cost and latency stay low and behavior is stable. Second, when something goes wrong, you can point to exactly which rule caused the problem. This principle holds for any AI system: use the simplest solution that works and add complexity only when needed, as Anthropic describes in its guidance on building effective agents.

One practical caution: rules need an owner and a version. If someone widens the date tolerance, that change should be recorded, because it changes which entries get resolved automatically.

Where AI helps: the ambiguous cases

After the rules run, a residue of entries with no clear match remains. This is where a language model can help, because the problem shifts from exactness to interpretation.

Examples of legitimate use:

• Interpreting the text descriptions on the statement and linking them to a registered customer or supplier, even with abbreviations or similar names.
• Suggesting that a single credit corresponds to the sum of two or three open invoices from the same customer.
• Proposing that an acquirer deposit corresponds to a set of sales, showing the calculation that adds up to the amount.
• Classifying entries with no counterpart (fees, interest, charges) into suggested accounting categories.
• Summarizing for the reviewer why the suggestion was made and what evidence supports it.

In all of these cases, the AI output is a structured proposal: statement entry, suggested entry in the system, confidence level and a short justification. It executes nothing. A person approves, and the approval is what triggers the posting.

It also helps to limit what the model sees. It needs the statement for the period and the open items, not the whole customer base, and no personal data beyond what is necessary. This reduces LGPD risk (Brazil's data protection law) and improves quality, since less irrelevant context means less chance of invented matches.

What should a person always check?

The useful question is not whether the AI was right most of the time, but which errors are acceptable. A misclassified small entry is different from settling the wrong customer invoice, which causes an improper charge or leaves a real debt uncollected.

A simple decision guide:

• Exact rule match: no individual approval needed, but include it in periodic sampling and in an exceptions report.
• AI suggestion with a small amount and a clearly identified customer: quick batch approval, with the evidence visible.
• AI suggestion that groups several invoices or uses a payer different from the one on file: individual approval.
• Any difference to be posted as a loss, discount or adjustment: approval by someone with financial authority, never automatic.
• High-value entries, related-party entries or entries without supporting documents: mandatory review, with the reason recorded.
• Month-end close: human check of the final balance between statement and ledger, regardless of what was automated.

There is also a governance reason to keep a person in the loop. If an automated decision affects a data subject, such as billing an individual customer, the right to review matters. It is worth reading LGPD automated decision-making and the right to review to see how this applies to your case. And to define what should never go to the model, what not to delegate to AI in business helps you draw the boundary.

How to build the workflow, step by step

A lean, auditable workflow can follow this order:

• Import the statement in a structured format (OFX, CNAB or the bank or aggregator API, depending on what the company uses) along with open items from accounts payable and receivable.
• Normalize the data: dates, amounts, signs, names and identifiers, before any comparison.
• Run the deterministic rules in order, from most restrictive to most flexible, tagging each resolved entry with the rule applied.
• Separate the residue: everything unresolved or with more than one candidate.
• Send the residue to the model with minimal context, asking for a structured suggestion with justification and confidence level.
• Validate the output in code: does the suggested amount match the sum? Does the invoice exist and is it open? Is the account the expected one? Suggestions that fail validation go back to the manual queue.
• Present the suggestions to the reviewer with the evidence alongside, and allow approve, reject or correct.
• Only after approval, execute the posting in the system, recording who approved, when and on what basis.
• Generate an exceptions report and an aging list of old open items for the close.

The code validation step is the one most often forgotten and the one that protects the most. It is a direct application of output guardrails, covered in guardrails for AI agents: input, output and action controls. If your finance team works in Bling, Omie or Tiny, the integration path and write risks are covered in integrating AI with Brazilian ERPs via API.

Illustrative scenario

Imagine a small distributor (illustrative scenario, not a real case). The statement shows a Pix credit from a sender with an individual's name and no invoice identifier. In accounts receivable there are two open invoices from a corporate customer whose partner has that same name.

The exact rule does not resolve it, because the amount does not match a single invoice. The tolerance rule does not either, because there is no unique candidate. The entry goes to the residue. The model receives the credit and the relevant open items and suggests: this Pix corresponds to the sum of the customer's two invoices, the sender is a registered partner, and the sum matches the exact amount. The code confirms that the invoices exist, are open and that the sum is the one stated.

The suggestion reaches the finance person with the evidence side by side. Because the payer differs from the one on file and two invoices are grouped, the decision rule requires individual approval. She confirms, the posting is made, and the record keeps the suggestion, the approval and the justification. Had she rejected it, the reason would also be recorded and could be used to adjust the process.

How to measure whether it works and which risks to control

Without measurement, reconciliation with AI becomes a feeling that things are better. Before switching anything on, record a baseline: how long the team takes to close, how many entries stay pending and how many differences are found too late. Then, during the pilot, track simple indicators:

• Share of entries resolved by rule, by approved suggestion and by manual work.
• Suggestions rejected or corrected, with the reason.
• Postings reversed after approval, which signal a review failure or a rule failure.
• Time between the statement entry and its reconciliation.

To structure criteria and decision points, how to measure an AI automation pilot offers a useful model. To build a set of test cases from anonymized real examples and check behavior before expanding, Anthropic describes the logic in its material on evaluating AI agents. And as a general risk management reference, the NIST AI Risk Management Framework helps organize who is accountable for what.

The main risks are concrete. Financial and personal data call for minimal access, protected secrets and logs without excess information. The model can confidently suggest a wrong match, which is why code validation and approval exist. And changes in statement format or bank rules can break normalization without warning, so the workflow needs an alert for unusual volumes or formats.

In the method we apply, the path follows four moves. Map the current process and the baseline. Limit data and actions, leaving the AI with read access and suggestions only. Pilot one real workflow, such as one account and one type of entry, with logs and an agreed success criterion. And hand over the operation, deciding from the records whether it is time to expand, adjust or stop.

Frequently asked questions

Can AI do the entire bank reconciliation on its own? Technically it can propose a match for almost everything, but that does not mean it should execute. What is exact should be resolved by rules, and what is ambiguous should be approved by a person. Settling invoices and posting differences are actions with financial effect and deserve an audit trail.

Do I need to replace my ERP or financial system to use AI for reconciliation? Generally no. The most common approach is to work with an export of the statement and open items, or with the API of the system you already use, starting with read access only. Writing to the system comes later, restricted and with approval, once the pilot shows the suggestions are reliable.

Can bank statement data safely go to an AI model? It depends on the design. Send only what is necessary, avoid unneeded personal data, define where data is processed and stored, and log access. For data about individuals, align with the LGPD, consult the guidance of the ANPD (Brazil's data protection authority), and do a formal assessment when the risk justifies it.

How do I know whether reconciliation with AI is working? Compare against the baseline recorded before the pilot: close time, old open items and differences discovered late. Also track rejected suggestions and reversed postings. If the correction rate is high or the team does not trust the suggestion queue, the fix is in the rules and the context, not in giving the model more autonomy.

Sources

• Anthropic: Building effective agents
• Anthropic: Demystifying evals for AI agents
• NIST AI Risk Management Framework
• ANPD: Autoridade Nacional de Proteção de Dados