Skip to main content
DoneThat

AI Adoption GuideFinanceClose

Account reconciliation agent

Auto-matches GL to bank and sub-ledger feeds and surfaces only true exceptions, using tools like BlackLine, FloQast, or Numeric.

Finance processPlanBudgetInvoiceCollectPayCloseReportAudit

By Don, DoneThat’s AI coach · updated

The recon is not done until a person signs a cited packet

A useful account reconciliation agent returns a match packet that names a GL line and the bank or sub-ledger line it claims to clear. Anything it cannot cite stays unmatched. The accountant still signs the recon. That is the quality bar. Clearing the account, shrinking the exception list, or posting a reconciling item the books never supported is not a successful run.

Treat the agent as a matcher and a highlighter, not as the signer. Whether the workpaper lives in BlackLine, FloQast, Numeric, Workday, or a close binder, the packet rules do not change. Propose pairs with enough lineage that a reviewer can open both sides without guessing. If the packet cannot point at both sides, it is not a match.

The same cite-or-leave-open rule already applies next door. Cash that arrived as a remittance still has to land on the right invoices in cash application via remittance parsing. Intercompany still has to pair with a counterparty cite in intercompany elimination matching.

Pull the GL and the opposing feed in the same cut

Load a single GL extract for the account and period you are reconciling, then load the opposing feed for the same cutoff. For a bank rec, the opposing feed is the bank statement or BAI-style activity through the statement date. For a sub-ledger rec covering AR, AP, fixed assets, or prepaid, the opposing feed is the sub-ledger trial or activity through the same period end. Mixing a GL cut at period-end with a bank file that includes later activity is how you manufacture timing noise the agent will then try to solve.

Agree the grain before matching starts. GL lines should carry account, amount, posting date, document or journal id, and a line id the ERP will still recognize next week. Bank lines should carry amount, value date, bank reference, and the description the bank actually sent. Sub-ledger lines should carry the sub-ledger document id, amount, and open or cleared flag. If either side is a daily total with no line id, stop. You cannot cite a total.

Lock the cut. Once matching begins, do not silently refresh one feed. A GL reload that drops a reversing entry while the bank file stays frozen will look like a new exception, or like a match that no longer exists. If you must reload, re-run the whole packet and discard the previous proposals.

Scope the account. Operating cash, lockbox cash, and a payroll imprest account are different recs. Dumping three bank feeds into one GL cash account without a mapping table is not a load step. It is a design defect. Map bank accounts to GL accounts first, then run one rec per mapped pair.

Cite both sides or do not match

A match is a packet, not a green check. Each accepted pair should state, in a form a reviewer can copy into the workpaper: GL line identifier, GL amount and date, opposing line identifier, opposing amount and date, and the rule that joined them. If the rule cannot be written in one sentence, the pair is not ready.

One-to-one is the default. Many-to-one is allowed only when every child is listed. A bank ACH can clear two GL receipts only if both GL line ids appear in the packet and the amounts sum without remainder. A remainder is not a rounding story. It is an unmatched stub.

Do not net across dates to force a tidy zero. A deposit on the 3rd and a withdrawal on the 18th are not a match because the account landed at zero. They are two lines. Matching them hides a real inflow and a real outflow.

Illustrative path: you are reconciling operating cash at month-end. The bank file shows an incoming ACH of $15,000.00 with reference CUST-4418. The GL shows cash receipt journal 4821, line 3, for $15,000.00, same customer reference, posted one day earlier. The agent emits a packet citing GL 4821/3 and bank item B-99102, joined on amount and customer reference. The same file also shows a $42.00 bank analysis fee with no GL line. The agent does not pair the fee with an unrelated $42.00 AP payment two weeks earlier. The fee stays unmatched. That unmatched line is the work.

When a proposed pair would require a human to squint (partial amount, shared round number, description that almost matches), send it to exceptions. Near-matches are how forced matches get into the binder.

True exceptions stay unmatched

The exception list is the product, not a failure of the matcher. Unmatched means unmatched. The agent does not invent a reconciling item, a timing label, or a journal to make the rec foot. It can group unmatched lines by likely cause (bank fee with no GL, GL receipt not yet on the bank, stale check, amount difference on the same reference) so the accountant can work them in order. Grouping is not clearing.

Work exceptions in a fixed order.

Identify-only items: bank fees, interest, or chargebacks that have a bank line and no GL. The accountant decides the journal. The agent may draft a suggested entry. It does not post it, and it does not treat the draft as a match.

Timing: GL posted, bank next period, or the reverse. Leave both sides open in this period's packet. Do not match them to a future statement you have not loaded.

Amount breaks on the same reference: same customer or vendor id, different amount. That is research, often the same class of problem journal entry anomaly detection is watching for on the GL side. The packet should show both amounts and both line ids. It should not average them.

Orphans with no plausible pair stay unmatched until the accountant writes the reconciling item or posts the missing entry. If the close needs an accrual because a fee is known but the invoice is not in, that is a separate judgment. Point the accountant at accrual auto-suggestion rather than letting the rec agent mint a balance-sheet plug inside the match grid.

Three ways auto-match corrupts the close

Forcing a match. The worst packet is a pair that foots because someone scored the run on match rate. Typical force patterns: pairing two unrelated lines because the amount is common; absorbing a small difference into a rounding bucket with no policy; matching a bank line to a GL line in a different account because the description string overlapped. A forced match removes the exception a reviewer would have caught. Prefer an honest unmatched list over a complete-looking rec.

Treating auto-match as signed. A completed matching run is not a signed reconciliation. The control is the accountant's sign-off on the packet: matched pairs reviewed, unmatched items listed with disposition, and a tie-out to the GL balance and to the bank or sub-ledger balance. If your close checklist marks the rec complete when the agent finishes, you have replaced a control with a job status. Whether you store that packet in BlackLine, FloQast, Numeric, or Workday does not change who signs.

Inventing a reconciling item. When the rec does not foot, the temptation is to insert timing or other until it does. If the difference is a missing fee, post the fee. If it is an unpresented check, list it as outstanding with the check number. If it is unexplained, it stays unexplained on the exception list. The agent may propose a label. The accountant accepts or rejects it.

Sign-off is still an accounting control

Hand the accountant a packet they can sign: GL balance for the account, opposing balance for the same cut, matched pairs with cites, unmatched items with no invented plugs, and a residual that foots. If the residual is not zero, the rec is not ready. Do not hide it inside a matched pair.

The signer is a person with authority to own the account. Timestamp sign-off after the last reload of the feeds. Keep the packet so next period's outstanding items either clear with a new cite or remain with the same line ids. When the rec is signed, unmatched items that need entries move into the journal process. The books have to change, or the exception will return.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first