How is robotic process automation applied to bank reconciliation, and what does it do there?

What is robotic process automation, and how does it differ from built-in matching or a bank feed?

The Federal RPA Community of Practice is a U.S. government practitioner group whose RPA Program Playbook and Executive Guide: Creating a Robust Controls System for RPA Programs set out recommended practice for agency automation programs. The Executive Guide describes robotic process automation (RPA) as low- to no-code software used to automate repetitive, rules-based tasks, and says all RPA technologies mimic human actions. It works through the front end of the applications you already use, signing in, reading screens, clicking, typing and downloading, and neither the bank portal nor the ledger is changed to accommodate it. The Executive Guide lists data reconciliation among RPA's popular uses.

Two other instruments do overlapping work and are often confused with it:

• The accounting software's own matching. Intuit's help for QuickBooks Online, for example, says QuickBooks can automatically match bank transactions to the transactions already in QuickBooks. What an automatic reconcile does, and how to check it, is a separate question.

• A direct data connection. Intuit's help says that once a bank account is connected, QuickBooks automatically downloads recent transactions, which a person then reviews, categorizes and adds to the books. Once the connection is set up, retrieval happens between programs with no screen driven.

  Intuit's help also says that data a connected third-party app sends is recorded in the audit log as a System Administration event. The same label marks QuickBooks Online's own automatic changes, so an integration's writes are not attributed to the app itself. Review what an integration posts as you would the robot's postings.

Of the three, robotic automation is the one coupled to screens and page layouts, so reserve it for steps that neither a built-in feature nor a supported connection covers.

Which reconciliation steps can a robot perform, and which stay with a person?

The Community of Practice's Executive Guide notes that automations are limited to what they have been programmed to do. That draws the line: a robot can take any step whose correct action can be written down before the run, and a step that needs a decision about something new stays with a person. A typical cycle sorts like this:

What must your process already have before a robot can run it?

Robotic execution is viable only when four conditions already hold:

• Both sides are machine-reachable. The robot can reach the statement data and the ledger detail by routes that work the same way every cycle, under its own sign-in.
• Inputs are stable. Statement layouts, export formats and the screens the robot uses rarely change. When assessing a candidate process, the Community of Practice's RPA Program Playbook asks about each system's stability, meaning how often it changes.
• Matching rules are written and deterministic. Each rule gives one answer for a pair of items, such as "same amount, same check number, bank date no more than five days after book date," and says what happens when more than one item qualifies: normally, all of them go to the exception list rather than the robot picking one. "The one that looks right" is not a rule. The RPA Program Playbook recommends automating processes that are relatively mature with well-defined business rules, and completing the process design document before development begins.
• Exceptions have a named destination. A named person works the unmatched list each cycle, with a deadline before the reconciliation is signed.

Test the third condition hardest. If people match differently today, the robot encodes whichever version its builder watched, and the ambiguity becomes harder to see. The RPA Program Playbook's remedy is to capture the various ways a task is executed and agree one standard for the automation to follow, on paper, before anything is built.

What if statement data comes only from signing in to a bank portal?

Establish first whether a supported route exists. Ask the bank whether it offers a direct connection to your accounting software or a downloadable transaction file. If either route exists, most of the case for robotic retrieval disappears. If a robot must sign in, that is the most access-sensitive part of the design. Ask the bank for a separate user with view and download rights only, confirm that its online-banking agreement permits automated sign-in, and ask how that user can pass multi-factor authentication with no person present. Never switch off multi-factor authentication to let a robot through. If the only answers are weakening that check or having a staff member relay codes, or if the bank cannot accommodate the rest, keep retrieval with a person and automate from the downloaded file onward.

What if the ledger has no interface for other programs?

Treat the ledger side separately from the statement side, since one may have a supported route while the other does not. When a locally installed or hosted ledger offers no programmatic interface, and its documentation shows no file import for transactions, driving its screens is the only way for a robot to write to it, so that fragility has to be accepted rather than avoided. If the ledger can export account detail to a file, the robot can work from the export and leave all posting to a person.

What should the robot do with an item it cannot resolve?

Decide this before anything is built. The Community of Practice's Executive Guide advises inserting human approvals into the automated workflow, and each of the three possible designs leaves a different trail:

Where should the robot sit relative to your accounting system?

Placement decides what the robot can write, where the evidence lives and what a failed run leaves behind:

Starting with the second or third placement, and moving to the first only after several clean cycles, limits what a flawed rule can damage.

How is a robotic run reviewed, approved and evidenced?

A finished run is not an approved reconciliation. AccountingTools' reference on segregation of duties says a separate reviewer ensures all entries are valid, supported by documentation and aligned with financial policies. The robot is the preparer and a person is the reviewer. Each cycle should leave four records:

• A run log. The Community of Practice's Executive Guide recommends audit logging that identifies errors and alterations, kept in centralized, protected storage so it cannot be tampered with. For a reconciliation, the log shows start and end times, inputs, rule-set version, matches, postings and errors.
• The exception queue. It lists each unmatched item with its resolution, who resolved it and when.
• The reviewer's sign-off. A named person works the exception queue and records each resolution. A different named person, who is not the rule-writer (the owner, where staff is small), reviews those resolutions and any adjusting entries and samples rule-matched items. That reviewer checks the statement ending balance the robot used against a statement they obtain directly from the bank, not the robot's download, and checks the book balance the robot used against the general-ledger balance for the period at sign-off, then approves.
• Retained evidence. Keep the log, queue and sign-off with the reconciliation. Intuit's help says QuickBooks Online audit-log events are available for two years, so export what you need if you keep records longer.

How should the robot's sign-in be set up and governed?

Give the robot its own identity on every system it touches:

• Its own named user. The Community of Practice's RPA Program Playbook recommends that bots be uniquely identified to tell them apart from human users, and that human sponsorship be required before an automation receives credentials. Intuit's help for QuickBooks Online says the audit log shows the user who made each change, so a robot signed in as your bookkeeper leaves entries indistinguishable from the bookkeeper's own. Confirm that your subscription allows a separate user for this purpose.
• Least privilege. The RPA Program Playbook says an automation should receive the minimum access its task requires, and nothing more. At the bank that means view and download only, never payment rights; in the ledger, only what its rules need.
• Separated duties. The RPA Program Playbook says the same segregation-of-duties policies should apply to automations as to human users. A robot that retrieves, matches and posts is preparing the reconciliation end to end, so it must never approve its own work or post an unexplained difference to force a balance. Because the robot both fetches the evidence and writes the record, the review must bring its own copy of the evidence. AccountingTools notes that segregation of duties is harder in a smaller organization with too few people to shift tasks between; there, the owner reviewing every reconciliation and every entry the robot posted keeps a second person in the process.
• Periodic review. The Community of Practice's Executive Guide recommends that credentials for every unattended automation be assigned, stored and managed. Include the robot's accounts in your periodic access reviews, and keep its password out of scripts and shared files.

Why do robots break, and what upkeep do they need?

A robot is coupled to every screen, file layout and credential it uses. The Community of Practice's RPA Program Playbook says an automation typically breaks because of an update to a host application, and that failures can also result from changes in credential requirements. Typical triggers in a bank reconciliation include:

• A redesigned bank portal or a new step in its sign-in
• A new or reordered column in the statement export
• An update to the accounting software's screens or reports
• An expired password or a change to the robot's user rights

These changes arrive on the other party's schedule, not yours, so the upkeep is permanent:

• Keep a list of every system, screen, file and credential the robot depends on, as the RPA Program Playbook recommends for each automation.
• Treat a reconciliation that did not arrive on schedule as a failure, because a broken robot may simply produce nothing.
• Follow the Executive Guide's advice to check routinely that the automation still operates as intended, for example by reconciling one account by hand each quarter and comparing.
• Keep someone able to reconcile by hand, because the Executive Guide warns that an organization can lose the expert who understands the end-to-end process well enough to correct a problem.

What will robotic automation not fix?

A robot runs your existing process faster and more consistently. It does not supply matching rules, repair unreliable source data or make the accounting decisions that exceptions require. Hand it an incomplete statement file or a ledger full of miscoded entries and it processes the same problems faster. The Community of Practice's RPA Program Playbook cautions that easy automations often do not resolve wider business process challenges. If reconciliations are late, disputed or never quite balance, fix the rules and upstream posting first; automating an undefined process encodes the ambiguity instead of removing it.

How can you test your own cycle before anything is built?

Work through these checks for each bank account you want to automate:

Then prove the rules on one account for one cycle, running the robot alongside the manual reconciliation and comparing item by item. Run the pilot with posting switched off: the robot writes its matches and proposed entries to a file (the second placement), and only the manual reconciliation posts. The Community of Practice's Executive Guide expects the process owner to validate an automation's results, with testing complete and documented, before it goes into production. Any item the two methods treat differently marks a rule that was assumed rather than written.