How to build a robot ledger for RPA, with a template

Once a company has ten or twenty RPA bots, it loses track of which bot does what and who looks after it. Then a bot stops after its builder has moved on, and only then does anyone learn it exists: what Japanese teams call a “rogue bot” (野良ロボット).

The basic tool against this is a robot ledger (ロボット管理台帳): a list with one row per bot, saying what it does, who is responsible for it, and what to do when it stops. This article covers the 15 columns to fill in, how to fill them, when to update them, and the rules that keep a ledger from becoming a formality. We also provide an Excel template that follows this article.

What a robot ledger is

A robot ledger lists the bots running in the company. Each bot gets one row, with its name, run cycle, the work it does, inputs and outputs, the person responsible, what to do when it stops, and so on.

With a ledger, you can:

See the whole picture: how many bots there are, which work they serve, and which systems they operate
Act when one stops: whom to contact, and how to do the work by hand in the meantime
Hand over: what the next owner needs to take over
Explain: show auditors and internal control reviews how bots are managed

There are public models for what a ledger should contain. In the study materials for its RPA implementation guide for financial institutions (December 2019), FISC (The Center for Financial Industry Information Systems) lists more than 40 robot management items, from the robot’s name and run cycle to contractors and legal and regulatory impact. It also says the ledger must be prepared before a robot goes live, updated whenever the robot is changed or its owner changes, and checked against reality periodically.

For local governments, the RPA guidebook from Japan’s Ministry of Internal Affairs and Communications (July 2025) calls robots left without maintenance after their staff are transferred “rogue robots” and warns that they can become a security risk.

This article and the template use 15 columns: 14 items chosen from FISC’s list that every robot needs regardless of industry, plus the robot’s status.

The 15 columns

Column	What to write	Example
Robot name	A name that says what the robot does. Name it after the work, not after its builder or team	Enter received invoices
Robot ID	A number unique in the company, traceable to the scenario or file name in your RPA product	RB-0012
Run cycle	When it runs. If someone starts it by hand, say so and who	Every business day at 9:00
Status	Running, paused, stopped, or retired	Running
Follow-on conditions	What runs after it, or which work takes its results	Starts “Build the payment schedule”
Business description	What it does, from where, to where, in two or three lines	Reads the PDF invoices suppliers send and enters them in the accounting system
Input and output data	The files and screens it reads, and what it creates or updates	In: invoice PDFs in a shared folder / Out: entries in the accounting system
Manager in charge	Both the accountable manager and the person who looks after it	Owner: head of accounting / Operator: Sato, accounting
Contractor	Who builds or maintains it outside the company, and the contract term	None
Error handling policy	Who does what when it stops, and whether there is a manual fallback	Accounting enters invoices by hand and tells IT
Business importance	How much a stop hurts (high, medium, low), and why	High (month-end payments)
Customer impact	Whether customers or suppliers are affected	None
Connected systems	The screens and systems it operates, with URLs or versions	Accounting system (web), shared folder
Legal and regulatory impact	Whether a wrong result touches laws or regulations	Yes (accounting and tax records)
Documents	Where the manual, design notes, and handover notes are kept	Shared folder “RPA/RB-0012”

FISC’s list also includes items such as operating hours, the start date, change history, the business flow, volumes handled, and the effect before and after adoption. Where stricter management is required, as at financial institutions, add them.

Tips for filling it in

Name robots after the work: “Sato’s robot 3” means nothing once Sato moves on
Always fill in the owner and operator: a row with these empty is a rogue bot in the making. If there is only one person, find a second
Be specific about connected systems: not just “accounting system” but whether it is the web or desktop version, and the URL for an outside service. When that system’s screens change, you can find the affected robots at once
Write the manual fallback in the error handling policy: so the work does not stop while the robot is being fixed

When to update it

A ledger starts going stale the moment it is written. Agree on these update points:

When	Columns to review
A robot is built or changed	All of them, especially the description, inputs and outputs, connected systems, and documents
An owner is transferred or leaves	Manager in charge
A system it operates changes	Connected systems, error handling policy
A robot is stopped or retired	Status, follow-on conditions
The yearly inventory	Business importance, customer impact, legal and regulatory impact, and a check against the robots actually running

Record what changed in a change log separate from the ledger. The template includes a sheet for the date, robot ID, what changed, who changed it, and who checked it.

Rules that keep the ledger alive

A ledger that is not updated soon drifts from reality. These rules make it easier to keep up:

No robot runs unless it is in the ledger: make a ledger entry a condition for running a new robot in production
Whoever approves a change checks the ledger was updated: make changing the robot and updating the ledger one procedure
Open the ledger when someone is transferred: when you hear of a transfer, find that person’s robots in the ledger and reassign them
Compare with your management tools: once a year, compare the run history on the RPA management server with the ledger, and find robots missing from the ledger or listed but not running
Do not start with too many columns: if 15 is too many at first, start with five: name, description, owner and operator, connected systems, and error handling policy, and add the rest later

Common mistakes

Written once and never again: the ledger is made at the end of the adoption project, and later changes never reach it
Only a person’s name in the owner column: when that person leaves, nobody knows who is responsible
Procedure documents not linked from the ledger: you cannot get from the ledger to the documents, and end up reading the scenario to understand it
Built by IT alone: only the business teams know how important the work is and how to do it by hand when the robot stops

For how to investigate robots whose builders are already gone, see Taking over an RPA bot whose builder has left.

The Excel template

An Excel template with these 15 columns is free to download from the download page:

The ledger sheet: 15 columns, an example row, and choices for status and importance
A sheet on how to fill in each column and when to revise it
A change log sheet

Kitewell exports the ledger

Descarty’s Kitewell exports every workflow to Excel as a robot ledger that follows FISC’s management items. The name, ID, run cycle, status, follow-on workflows, description, the Excel files it reads and writes, the systems it connects to, and the workflow’s knowledge are filled in from the workflow definitions. Columns people decide, such as the manager in charge, contractor, error handling policy, business importance, customer impact, and legal and regulatory impact, are left empty.

Without the work of updating a ledger by hand, it no longer falls behind with every change. For how traditional RPA and AI RPA differ, see RPA problems.

Summary

A robot ledger lists every robot in one row: what it does, who is responsible, and what to do when it stops
Fill in 15 columns chosen from FISC’s management items. Never leave the owner and operator, connected systems, or error handling policy empty
Update it when a robot is built or changed, when people move, when a system it operates changes, and at the yearly inventory
Rules such as “no robot runs unless it is in the ledger” and “approving a change includes updating the ledger” keep it from becoming a formality

Sources

FISC (The Center for Financial Industry Information Systems): RPA implementation guide (published February 2020, in Japanese)
FISC: Draft of the RPA implementation guide and list of robot management items (study materials, December 2019, in Japanese)
Ministry of Internal Affairs and Communications: RPA guidebook for local governments (July 2025, in Japanese)