RPA in Procurement: Six Real Use Cases and Four Traps

Robotic process automation, RPA, is software that mimics a person clicking through screens. It logs into a portal, copies a number, pastes it into another field, and hits submit, exactly as a human would, only faster and without lunch breaks. In procurement it gets sold as the fix for every repetitive task. Some of those pitches are right. Several are quietly setting you up for a mess two years out. After building and cleaning up a fair number of these bots, I have a simple rule: RPA is a bridge, not a building. Below are six real procurement use cases with an honest verdict on each, the four traps that catch teams every time, and a lifecycle policy that keeps your bots from becoming a liability.

What RPA actually is (and is not)

RPA drives the user interface of a system. That is the whole trick. It does not talk to a database, it does not call a clean, versioned API, it reads pixels and field labels and clicks buttons. This is exactly why it is powerful and exactly why it is fragile. Powerful, because you can automate a system you have no other way into. Fragile, because the moment that screen changes, the bot is blind.

The tools are mature. UiPath and Microsoft Power Automate desktop flows both let you record a sequence of clicks and replay it on a schedule. The tooling is not the risk. The judgement about what to point it at is the risk. For the wider decision of when to automate at all, see my workflow automation buyer's guide.

Six procurement use cases, with a verdict on each

1. Supplier portal price scraping

You have forty suppliers, each with a login-gated portal, each showing current prices. A bot logs in nightly, reads the price grid, and drops the numbers into your spend model. Verdict: worth it, with a warning. The interface is outside your control, there is usually no API on offer, and the volume is real. This is a defensible RPA use. But read the portal's terms of use before you build anything (see the traps below), because automated access often breaches them outright.

2. Catalogue price-file updates into your ERP

A supplier sends a price file, and a bot keys the new prices into your own purchasing system screen by screen. Verdict: avoid. Fix the integration instead. This is a bot pointed at a system you own. Your ERP almost certainly has a price-list import, an OCI or cXML punchout, or an API. Using RPA here automates around a gap that configuration would close permanently. You are paying to maintain a bot that a one-time integration would retire. This is the classic case covered in procurement and ERP integration.

3. Tender document assembly

Pulling boilerplate, scope templates, evaluation grids, and prior-tender clauses into a single packaged tender document. Verdict: strong, but this is often document automation, not RPA. If the sources are your own files, a templating tool or a document-generation flow beats screen-driving. RPA earns its place only when the content lives behind a system with no export. Where the inputs are unstructured supplier submissions, this shades into a different discipline: see document AI in procurement.

4. Supplier master data enrichment

A bot takes a new vendor record, visits a trade registry or a sanctions-check site, reads the result, and writes it back. Verdict: mixed. Good for the lookup, dangerous for the write-back. Reading a public registry is a fair use. Letting a bot silently update the supplier master is where governance breaks down: master data changes need an owner and an audit trail, not a script quietly overwriting fields at 2am.

5. PO acknowledgement chasing

The bot checks which purchase orders have no supplier acknowledgement, then emails a reminder or updates a tracker. Verdict: good, low-risk, high-relief. It is a nagging task nobody wants, the logic is stable, and the downside of a miss is small. If your ERP supports acknowledgement webhooks or EDI, prefer those; absent that, this is a sensible bot.

6. Government and customs portal submissions where no API exists

A regulator or customs authority requires filings through a web portal that offers no machine interface at all. A bot logs in, fills the declaration from your data, and submits. Verdict: the single strongest RPA case in procurement. You do not own the interface, there is no API to build against, the volume is high, and the manual alternative is soul-destroying. This is what RPA was invented for. Guard the credentials tightly and confirm the portal permits automated submission.

Scoring the six on what actually matters

Three factors decide whether an RPA candidate ages well: the volume that justifies the build, the stability of the target interface, and whether an API alternative exists today that would make the bot unnecessary. Here is how the six score.

The four traps that catch teams

Every failed procurement bot I have unpicked fell into one of these four. None of them are technical failures. They are governance failures dressed up as a screen change.

Trap 1: The bot holds credentials that violate the portal's terms of use

This is the trap I lead with because it is the one that can cost you a supplier relationship or worse. Many supplier, banking, and government portals explicitly forbid automated access and credential sharing in their terms of use. A bot that logs in with a named user's password is often a breach the moment it runs, regardless of intent. Before any portal bot is built, someone must read the terms and get sign-off in writing. Where automation is permitted, use a dedicated service account, never a person's login, and store the credential in a proper secrets vault, not in the bot's script.

Trap 2: The bot breaks every time the portal is redesigned

RPA reads the screen. When a supplier moves a button or renames a field, the bot fails, silently or loudly. Third-party portals redesign on their schedule, not yours, and they will not warn you. A bot with no failure alerting will quietly stop filing for a week before anyone notices the backlog. Budget for this: assume every external-facing bot will break once or twice a year and staff the maintenance accordingly.

Trap 3: The bot bypasses the very approval control it was meant to speed up

A bot built to accelerate a purchase-approval step sometimes accelerates it straight past the approval. If the automation submits a PO that a human was supposed to review, you have not sped up a control, you have removed it. Any bot touching an approval, a payment, or a master-data change must operate inside the control, not around it. Automate the preparation and the chasing; keep the human decision where policy requires one.

Trap 4: The bot becomes the only documentation of a process

Two years on, the analyst who built it has left, nobody wrote down the steps, and the only record of how the customs filing works is 300 lines of recorded clicks. Now the bot is not automating a process, it is the process, and you cannot change, audit, or explain it. Every bot needs a plain-language description of what it does, why, and what the manual fallback is, maintained separately from the bot itself.

The field observation: where durable bots point

Here is the pattern I keep seeing across procurement functions. The most durable bots, the ones still running well years later, point at third-party systems you do not control: customs portals, supplier price pages, registry lookups. They survive because there was genuinely no other way in, so nobody was ever going to build the integration that would replace them.

The least durable bots point at your own ERP. They automate a screen in a system where configuration, a standard import, or a proper integration would have done the job cleanly and permanently. Those bots exist because someone wanted to avoid an IT ticket, and they carry the maintenance cost of that shortcut forever. So the diagnostic is simple: if the bot is aimed at a system you own, stop and ask why the platform cannot do this itself. Usually it can, and the honest answer is that the integration was harder to fund than the bot was to record. That is a budgeting problem masquerading as an automation win.

A bot lifecycle policy

The difference between a fleet of useful bots and a swamp of undocumented liabilities is a policy that treats each bot as an owned asset. Four things, minimum, for every bot you run:

• Ownership. Every bot has a named business owner and a named technical maintainer. If either seat is empty, the bot is turned off, not left running.
• Credential management. Service accounts only, credentials in a vault, least privilege, and rotation on a schedule. No personal logins, ever.
• Change notification. Failure alerting on every run, plus a subscription (where possible) to the target system's change notices so a redesign is expected, not discovered through a backlog.
• Mandatory annual review. Once a year, every bot is re-justified: is the volume still there, does the target now offer an API, is the terms-of-use position still valid, is the documentation current? Bots that fail the review are retired. This is the step that stops the swamp from forming.

Conclusion

RPA is a bridge you build because there is no road yet, and you should treat it like one: useful, necessary sometimes, and never mistaken for permanent infrastructure. Point it at third-party systems with no API and real volume, and it will serve you for years. Point it at your own ERP to dodge an integration, and you have signed up for maintenance that outlives the person who built it. Read the terms of use before any portal bot exists, keep credentials in a vault under a service account, never let a bot slip past a control it was meant to help, and review the whole fleet once a year. Do that, and RPA is a genuine asset. Skip it, and you are automating your way into a liability nobody remembers how to unwind.