How is robotic process automation applied to the accounts payable process, and what does it do there?

What is robotic process automation?

The Federal RPA Community of Practice's controls guide, Creating a Robust Controls System for RPA Programs, describes robotic process automation (RPA) as a low- to no-code, off-the-shelf technology used to automate repetitive, rules-based tasks, and says all RPA technologies mimic human actions. The controls guide adds that RPA can interface with the front end of any system, working its screens as a person would. Three consequences follow:

• It follows rules; it does not reason. The controls guide says RPA automations can do only what they have been programmed to do.
• It leaves the systems unchanged. The Community of Practice's RPA Program Playbook presents it as a low-complexity answer to problems otherwise needing expensive fixes such as system upgrades.
• It automates tasks, not processes. The Program Playbook says so in those words; in payables it takes over one link in the chain.

Both guides were written for government programs and bind no business: the controls guide says it should not be considered prescriptive guidance, and the Program Playbook says it should not be read as official agency policy or mandated action.

Which payables steps is it applied to, and what does it do at each?

GSA's federal RPA use-case inventory records agency automations that create a direct-pay entry in the financial system and route it for approvals, verify that line-item totals match the invoice, email requests for the receiving reports needed to pay outstanding invoices, and log into an invoicing platform to run its aging report. In a business's payables cycle, the unit of work looks like this:

Where does the automation stop and a person take over?

Two of these steps are beyond rule execution; the other two RPA could be configured to perform, and they stay with a person by design:

• Approving the bill. The controls guide recommends inserting human approvals into the RPA workflow for chosen categories of transaction; apply that to every bill the automation creates, not only those above an amount. Switch on your platform's approval step for bills before the automation runs, and confirm the automation's role cannot save a bill past it; Zoho Books' U.S. Transaction Approval help, for example, applies approvals once you enable them for a module, Bills included. Without that step, the automation does not create bills.
• Reading an ambiguous document. A credit memo laid out like an invoice, or a line no rule covers, goes to a person.
• Explaining an exception. The automation can flag a total that is off, not decide whether the vendor, order or receipt is wrong.
• Vendor details and payment. The automation never creates or edits a vendor record, and releasing payment stays a separate human step, part of automating vendor payments.

Why can't its match against the vendor record catch changed bank details?

A match shows only that an invoice agrees with the vendor record, not that the record is genuine: a false request that first changes a vendor's remit-to, bank or contact details makes every later invoice match. The defence is verifying the change itself:

• Hold the bill. An invoice whose remit-to or bank details differ from the record, and any bill for a vendor with new or changed payment or contact details, stays out of approval and payment until the change is verified, whoever made it, an outside bookkeeper included. A new vendor's first payment waits for the same check.
• Use an independent channel. The FBI's Internet Crime Complaint Center recommends using secondary channels and/or two-factor authentication to verify requests for changes in account information. Call a number you looked up yourself, never one from the invoice, the request, the vendor's messages or a newly changed vendor-record entry.

Verifying vendor changes and releasing payment belong to vendor-payment controls.

How is it different from what the accounting software already does, and from invoice scanning?

Three kinds of automation need telling apart in payables:

• Native features. They run inside the accounting product: Zoho Books' U.S. Transaction Approval help, for example, says approvers can check and edit transactions before approving them.
• Capture and extraction. They turn documents into fields: Zoho Books' U.S. Documents help says that once Autoscan is enabled, uploaded documents are autoscanned and new transactions can be created from them.
• RPA. It operates screens to perform the rule-based steps neither of the others covers.

RPA acts on fields; it does not interpret documents. GSA's EOA Playbook asks, in choosing an automation technology, whether a process's data are structured or unstructured; an invoice arriving as a PDF or scan needs extraction first. Combined, extraction produces fields, the automation applies rules, a person submits the reconciled batch to the platform's approval step, and extraction failures join the exception queue.

Test a step in that order before building. GSA's EOA Playbook asks which automation tools an organization already has; check your platform's current U.S. help and any integration you use first, because a platform feature does not depend on screens staying the same.

Is a step in your payables process a candidate?

Put the step through five tests:

• Defined. GSA's EOA Playbook, in its sample staff survey, asks whether a set of instructions could easily be given to a new employee.
• Stable. The RPA Program Playbook, whose intake form asks how often each system changes, names changed process requirements and a break, typically from a host-application update, as the two prominent reasons a live automation needs attention; frequent change of the procedure's rules or its systems makes a poor candidate.
• Rule-expressible. The EOA Playbook's survey asks whether the process relies on well-established rules; what no rule covers goes to a person.
• Predictable input. Invoices arrive as structured data, such as a portal export, or pass through extraction first.
• Volume. The EOA Playbook's survey asks whether there is a high, steady volume of activity, enough to be worth the build and its upkeep.

A step that fails on judgment or volume is better left to a person or a native feature. One that fails the first test needs defining first: the Program Playbook's facilitation practice captures the various ways a task is executed and brings stakeholders to one standard the automation will follow. Automating an inconsistent procedure only repeats it faster.

What changes when the step spans two systems with no shared key?

A supplier portal or spreadsheet that exchanges no data with the ledger is where screen-driven automation may be the only option. GSA's EOA Playbook asks whether a process's systems are connected; where they are not, the automation must supply what a shared key would:

• Match on several fields. Use supplier ID, invoice number and amount together, never a name alone, and divert anything without exactly one match.
• Refuse duplicates. The controls guide tells programs to monitor that automation tasks are not duplicated; check the invoice number before writing.
• Report differences. GSA's use-case inventory includes an automation that validates data across systems and emails analysts the discrepancies it finds.
• Reconcile every run. The review section below sets out how.

What controls does an automated actor in the books need?

Treat the automation as a user with its own identity, limits and duties:

• Its own login, attended or not. The Program Playbook reports that some agencies let attended automations inherit their operators' credentials, but recommends as best practice that bots be uniquely identified apart from human users, that specific systems give automations their own credentials, and that a human sponsor be required to create them. Its own Level 2 model still combines operators' credentials with the automation's. Give attended automations their own login anyway: under a person's login or a shared account, the automation holds whatever that login holds, vendor-edit and payment rights included, and its entries look like a person's.

  No person uses its login: keep its password in a vault its builders and operators cannot open, put the mailbox behind its user under the owner or sponsor rather than the builder, and treat a password reset or a person's login as an incident. The controls guide calls for programs to assign, store, and manage non-person entity credentials for unattended automations.

• A platform that allows it. Zoho Books' U.S. Users & Roles help describes inviting a user by name and email address but does not say whether an automation may have a user of its own; confirm that with your platform, and if it cannot, do not build there.
• Least privilege. The Program Playbook sets the goal of the minimum access required to complete the task, and nothing more; Zoho Books' Users & Roles help describes custom roles built by selecting modules and levels of access.
• No approving, paying or vendor edits. The Program Playbook applies the same segregation-of-duties policies to automations as to people; the automation's role creates and reads, nothing more.
• Attribution. The controls guide aims for auditors to trace data, decisions and actions for all automations, with audit logs in protected storage safe from tampering; keep the automation's run log and change record where its builders and operators cannot alter them. Zoho Books' audit-trail FAQ says its audit trail shows how, when and who modified a transaction, and only an Admin can view it.

How should changes to the automation be controlled?

The controls guide allows no ad hoc changes, keeps developers out of day-to-day operation, and has the process owner initiate a change request for approval by the program office. In a business, the change is approved before it is made, and never by the person who makes it. The controls guide has the process owner validate results in a test environment; without one, check every entry of the first run after a change against its source before those bills are approved.

Does it matter whether it runs unattended or is launched by a person?

Unattended automations run on a schedule or trigger, such as an input file landing in a folder in the Program Playbook's example; a failure surfaces only if an alert reaches a named person. A run that never starts raises no failure, so alert that person too when an expected run is overdue; the controls guide tells programs to monitor that automations are on schedule. The controls guide describes attended automations as run by human operators, and the Program Playbook calls for separation-of-duty controls that stop the custodian running one from altering its coding. An attended automation still uses its own login, and its operator does not approve what it created.

Does it matter whether it writes to the books or only reads?

A read-only automation that extracts, compares or reports still needs its own login, limited to reading. Approval, posting limits and change control matter most once it creates records, because a wrong rule then alters the books.

The controls guide expects development, testing and operation of automations to be performed by three distinct parties. A one-person office cannot meet that, and the controls guide offers no substitute; an after-the-fact outside review does not replace the separation where the automation writes to the books. There, keep the automation to read-and-report work. Where two or three people share the work, whoever builds or changes the automation neither approves its changes or bills nor samples its output.

What maintenance does screen-driven execution require?

When an automation breaks, the Program Playbook names an update to a host application as the typical cause. The controls guide's remedy is to learn from IT system owners when changes to systems or applications are scheduled, or the automated processes can break. Outside vendors running your accounting platform, a supplier's portal or your email can change screens without telling you, so advance notice cannot be the remedy. Three duties follow:

• Know what it depends on. The Program Playbook recommends documenting all software, systems, front ends and credentials each automation needs.
• Monitor every run. The controls guide calls for a robust monitoring regime with fail-safes coded into the automations and error logs, and documented protocols for when an automation fails.
• Re-check routinely. The controls guide recommends routinely checking that deployed automations continue to operate as intended; re-test after releases you hear about, and let reconciliation and sampling catch the rest.

What review must remain over the automated step?

The controls guide warns that at automation scale, flawed logic and processing errors have significant impact: a keying slip affects one invoice, a wrong rule every invoice until someone checks. Three checks replace the clerk's eye:

• Reconcile each run. Before approvers see the batch, items received must equal entries created plus exceptions, by count and amount, counting entries from the platform's own list of bills entered under the automation's login for that run, never from the automation's log or summary; this proves completeness, not that any payee or bank detail is right.
• Sample the output. Each period, someone other than the person who configured the rules compares a few entries with their source documents, vendor and remit-to details included.
• Own the exception queue. In GSA's use-case inventory, a receiving-report reminder automation writes items it has no contact for to a separate file the process owner looks up by hand. Name one owner and a clearing cadence; vendor-detail exceptions go to whoever verifies vendor changes.

What does one automated step look like from input to the point a person acts?

A distributor's largest supplier posts a weekly invoice file to its portal; the portal has no integration with the accounting system, and the platform's own import will not take the file as it arrives. The step, registering those invoices, runs like this:

1. Input. A clerk saves the week's file from the portal into a watched folder, starting an unattended run under the automation's own login. It holds 40 invoice rows totalling 18,450.00. If the week's file has not landed by its due time, the payables lead is alerted.
2. Rules. For each row, it finds the vendor by supplier ID and the purchase order by number, checks that the lines add to the invoice total and the invoice number is new for that vendor, and compares the remit-to details with the vendor record.
3. Output. Thirty-six rows pass, totalling 16,920.00. For each, it creates the bill against its purchase order, saves it as a draft and writes a log line.
4. Exceptions. Four rows totalling 1,530.00 go to the exception file with reasons: invoice 2207, whose lines of 400.00, 350.00 and 125.00 add to 875.00 against a stated 895.00; an unknown purchase order (310.00); a duplicate (180.00); and a remit-to address that differs from the vendor record (145.00).
5. A person acts. The payables lead pulls the platform's list of bills entered under the automation's login for the run (36 bills totalling 16,920.00) and confirms that, with the exception file's 4 rows totalling 1,530.00, it equals the file's 40 rows and 18,450.00, then asks the supplier to correct invoice 2207, resolves the order query and discards the duplicate. The remit-to difference stays on hold until verified as above. Only when no vendor in the batch has an unverified change of details, which the match cannot show, does the payables lead submit the 36 drafts for approval; payment is released separately.