Returned-Payment RPA
Principle 01From hope to proofWhen a payment is returned, the account has to be updated across several screens of an internal credit system — fields and dropdowns set by the return reason, account age, and status; a standardized comment written; every change logged. The team worked a long daily backlog by hand, one account at a time, accuracy drifting with fatigue. This is an attended UiPath bot that does it from a single codebase: it reads the day’s accounts from a data feed, detects each scenario, drives the system, applies the right changes, and logs every one for audit. A different stack from the platform — the same engineering discipline.
attended bot
one codebase
+ full audit log
~15 sec / account
A day’s accounts in. Updated records + an audit trail out.
Source
The day’s returned-payment accounts arrive as a feed from a reporting platform.
Detect
The bot reads each account and determines its scenario from the data — no manual sorting.
Navigate
It drives the credit system across multiple screens and tabs for that scenario.
Apply
Sets the fields and dropdowns, and writes a standardized, calculated comment.
Audit
Captures before/after for every field, logs the action, flags the unexpected for review.
A decision matrix — not a brittle screen recording.
A recorded macro breaks the moment a field moves. The seventeen scenarios here are an explicit matrix: for each one, the screen path, the dropdown selections, the field updates, and the comment template.
One codebase handles all of them — a new scenario is a row, not a rewrite — and the logic is something a person can read and review, not a black-box recording.
Every change captured — before and after.
Compliance doesn’t accept “the bot did it.” So every field the bot touches is recorded old-value → new-value, timestamped, attributed to the bot, with the calculated comment stored alongside.
An exception is logged with a screenshot. Months later, any account’s change is reconstructable from the log — exactly what an audit needs, produced as a byproduct of the run rather than an afterthought.
It reads the current state before it acts.
The dangerous bot is the one that blindly re-clicks and double-applies. This one checks first: it reads a field or checkbox’s current state and only changes it if it isn’t already set — so a re-run is safe and a half-finished account is recoverable.
On anything it doesn’t expect, it pauses and logs rather than guessing. Idempotent by design, fail-safe by default.
Four layers, so a new scenario is config — not code.
Concerns are separated: an Excel data layer in, a decision engine that turns each scenario into a set of flags, state-aware portal automation, and an audit/logging layer out.
That boundary is what lets a new return type ship as a configuration change rather than a workflow rewrite — and what keeps the automation legible months later.
From a daily backlog to seconds an account.
The manual process took three to five minutes per account and a person’s full attention. The bot does it in roughly fifteen seconds, the same way every time, across hundreds of accounts a day.
The fatigue ceiling is gone, the scenario logic is consistent, and the audit trail comes for free. The kind of work a person should never have had to do by hand is simply done.
It shipped with its own documentation.
The suite came with a self-contained reference — a single portable file, zero dependencies, with interactive tools: a scenario builder, a compare tool, a validation worksheet, an export generator.
Knowledge that usually lives in someone’s head or a scattered wiki was packaged to be opened locally, emailed, or hosted anywhere — so the bot could be handed off, not hoarded.
A different stack. The same engineering values.
This bot predates the unified platform and runs on a completely different stack — yet it already embodied the discipline the platform later made universal. It’s exactly the kind of excellent-but-isolated tool that made the case for one platform instead of many islands.