A bank statement rarely tells the complete accounting story. A transaction may correspond to a payment, receipt, contra entry, journal, or a combination of records. When something is missing, the difficult part is not fetching more data. It is deciding what the evidence supports and what action is safe.
Why reconciliation should be a workflow
A single prompt can describe a reconciliation problem, but it cannot provide the operational guarantees that the process needs. The system must know which records were retrieved, which period and organization they belong to, which rules were applied, and whether a person approved any proposed accounting change.
A workflow makes those responsibilities explicit. Deterministic steps retrieve and normalize data. An agent handles interpretation. A controlled tool creates approved records. The run history preserves how the outcome was produced.
Use AI to investigate ambiguity. Use tools and workflow rules to control access, mutation, and completion.
A reference architecture
The workflow can begin by retrieving five sources in parallel:
- bank transactions for the reconciliation period;
- payments already recorded in the books;
- receipts already recorded in the books;
- contra entries between cash and bank accounts; and
- journals that may explain fees, interest, adjustments, or transfers.
Parallel retrieval reduces unnecessary waiting and keeps every source independent. Each tool returns a structured result with its own status and diagnostics. A merge step then assembles those outputs into one analysis input.
- Start with explicit scope.Organization, bank account, book, currency, and reconciliation period should be workflow inputs—not assumptions inside a prompt.
- Fetch each source separately.Independent tool calls make failures visible and prevent one missing source from being mistaken for an empty dataset.
- Merge into a stable contract.The agent should receive named collections with consistent fields rather than raw provider responses.
- Investigate unmatched items.The agent compares amounts, dates, descriptions, references, and counterparty context.
- Create only through approved tools.Payments, receipts, contra entries, and supporting journals are external actions with explicit inputs and permissions.
What the interactive agent should do
The agent’s job is to form and test explanations for unmatched transactions. It can propose that a debit is a supplier payment, that a credit is a customer receipt, or that two transactions represent a transfer between owned accounts. It should also be able to say that the available evidence is insufficient.
For each proposed record, capture the source transaction, the reasoning summary, the expected accounting effect, and a confidence or review signal. The proposal should be structured data that the workflow can validate—not prose that another step must interpret.
Supporting journals deserve a separate step
Some unmatched transactions need an additional journal rather than a payment or receipt. Bank charges, interest, exchange differences, and rounding adjustments are common examples. Keeping supporting journals in a separate workflow step makes their creation visible and lets the organization apply different approval rules.
Place controls around actions, not analysis
Reading records and calculating differences are usually lower-risk than creating accounting entries. The workflow should reflect that distinction. Retrieval and analysis may run automatically, while material or low-confidence proposals pause for review.
| Step | Primary control | Reason |
|---|---|---|
| Fetch records | Scoped connection | Limits the organization, resource, and operation. |
| Analyze exceptions | Structured input and output | Keeps model behavior inside an explicit contract. |
| Create entries | Permission and approval | Prevents analysis from silently becoming mutation. |
| Complete the run | Reconciliation checks | Confirms that outputs balance and required work finished. |
Preserve evidence after the workflow ends
A reconciliation result should answer more than “did it succeed?” Operators need to know which published workflow version ran, which records were retrieved, which transactions remained unmatched, what the agent proposed, who approved the resulting entries, and which API operations executed.
This is why workflow versioning and node-level results matter. They turn reconciliation from an AI-generated conclusion into an inspectable business process.
The takeaway
Make the evidence path as explicit as the accounting path.
The best use of AI in reconciliation is not unrestricted bookkeeping. It is disciplined investigation inside a workflow that already knows how data is fetched, how actions are authorized, and how outcomes are recorded.