If you reconcile 30 bank accounts, you do four things 30 times: get the statement, match the lines to the ledger, explain what does not match, and sign. Automating bank reconciliation means a system does the first three, and you do the fourth with a short list in front of you. The part that stalls most projects is the first one, because some of your banks have no feed and no API.
This guide covers the four layers of an automated reconciliation, how to cover the banks that sit outside a feed, and what you should keep a person responsible for.
Layer 1: get the data in without downloading it by hand
A bank feed is the standard answer. An aggregator such as Plaid pulls transactions and balances from thousands of institutions on a schedule, read-only. For accounts it covers, this layer is done.
Check two things before you rely on it. First, confirm the feed delivers the statement ending balance, not just transactions, because you reconcile to the balance the bank asserted. Second, confirm what happens when a feed breaks. A feed that pauses after one failed sync and says nothing leaves you reconciling against stale data.
Layer 2: match with rules before you match with judgment
Matching runs best in order:
- Exact matches. Same amount, same direction, same date window, one candidate on each side.
- Reference matches. A check number, wire reference, or invoice number ties the bank line to the ledger entry.
- Combination matches. One bank deposit covers several ledger receipts, or the reverse.
- Recurring items. Fees, interest, and loan payments that follow a known pattern get a rule that names the amount and description.
Keep the tolerance on amount at zero for cash. A tolerance of a few dollars lets a real error slide through as rounding. If a bank fee differs by a known amount each month, write that into a rule instead.
Layer 3: send exceptions to a person with the evidence attached
Whatever does not match goes into a queue. A useful queue entry shows the bank line, the nearest ledger candidates, the age of the item, and a suggested action: record a fee, wait for a deposit in transit, or investigate a possible duplicate.
Three queue practices keep the review short:
- Every exception has an owner and an age, so nothing sits open without a name on it.
- The system proposes a resolution, and a person confirms it. A proposal that posts itself is the failure mode to avoid.
- Items carry forward with their history, so a reviewer sees how long a deposit in transit has been in transit.
Layer 4: review and sign off against the statement
The reviewer checks that the adjusted bank balance equals the adjusted book balance, that the ending balance matches the statement, and that aged items have explanations. Preparer and reviewer should be different people. Sign-off locks the reconciliation, and reopening it keeps the open items visible.
For the manual version of these steps, see bank reconciliation, step by step.
The banks with no API
Most automation guides stop at Layer 1 because the feed either works or it does not. Real finance teams have accounts at regional banks, credit unions, foreign banks, insurers, and payment processors where no aggregator reaches. You have four options, and they differ in cost.
| Option | What it takes | Weak point |
|---|---|---|
| Manual download | A person logs in monthly and uploads a statement | Late, and one sick day delays the close |
| Scheduled statement email or file drop | The bank sends a file; a process reads it | Few banks offer it, and formats change |
| Local provider or direct bank integration | A contract per bank or per region | Slow to set up and uneven in coverage |
| Portal access by an agent | An agent logs into the bank portal with vaulted credentials and pulls the statement | Needs read-only access, a log of every pull, and a bank that permits it |
Adopt covers this gap with portal access. Agents log into bank portals that Plaid does not cover, pull the statement, and hand it to the same matching and exception layers as every other account. Credentials sit in a secret vault, the connection is read-only, and every pull is logged. Check your bank's terms of service for automated access before you switch it on, and ask your vendor how they handle that question.
What to keep a person responsible for
Automation changes who does what. It does not remove accountability.
- Approval of postings. A person approves every journal entry that reaches the ledger.
- Exceptions the system cannot explain. These are the reconciliations that matter most, and a system that guesses on them is dangerous.
- The sign-off. The reviewer's name and date are the control an auditor looks for.
Adopt's agents prepare the reconciliation and a named reviewer approves it. Nothing posts to your books without that sign-off.
A rollout in three steps
- Pick five accounts: two high-volume, two with no feed, one with a history of aged items.
- Run automation beside your current process for one close. Compare the outputs line by line and write down every difference.
- Move accounts over as the exception list shrinks. Keep the high-risk accounts on a tighter review for another cycle.
If you want to see it on your own accounts, book a pilot and bring your messiest bank account, or sign up free and connect one.
Related reading
FAQs
Related Articles

Why we bet Adopt AI on agents running the office of the CFO


12 Month-End Close Problems and How to Fix Each One

See it running on your workflows
Automate your accounting workflows

