Vendor Onboarding
Overview
Turns a procurement onboarding request into a vendor master record across two systems. Reads the "new vendor onboarding" e-mail, takes the vendor name, category and terms straight from the request, then creates the vendor in the ERP - filling the General, Payment and Contact tabs with the bank and tax details from the onboarding packet. The IBAN is mod-97 checked on save, so a bad account number is refused before it can ever become a payable. Writes a record of the created vendor. The story is a clean hand-off: a request in one system becomes a validated master record in another, with no re-keying.
Vendor Onboarding
Onboarding a new supplier is dull, and dull is where mistakes hide. Someone in procurement e-mails the details, someone in finance re-keys them into the ERP, and a single transposed digit in the IBAN means the first payment bounces — or worse, pays a stranger. The valuable robot here does the re-keying without the typos, and lets the ERP's own checksum catch a bad account number before it becomes a payable.
This flow reads the onboarding request out of the mailbox, opens a new vendor in the ERP, fills all three tabs from the request and the attached packet, and saves. The IBAN is run through a mod-97 checksum on the way in; a valid number is accepted, a bad one is refused.
It spans two fictional training systems — Lookout Mail for the request and RAP One for the vendor master — whose data is entirely synthetic.
What it produces
vendor-onboarding.csv in your home folder: the vendor as it was created — name, the ERP's new
vendor ID, category, terms, tax ID, IBAN, the checksum result and the saved status line. On the
seeded request that is Fjordline Data GmbH, hosting, Net 14, created as a fresh V-#### vendor
with its IBAN passing the mod-97 check.
How it works
1. Read the onboarding request
Sign in to the mailbox and open the "new vendor onboarding" e-mail. The vendor name, category and payment terms are read straight out of the request body. The bank and tax details travel in the attached onboarding packet; the flow carries them as the vetted values to key in.
2. Create the vendor in the ERP
Sign in to RAP One and open a new vendor. The robot fills the three tabs the way a clerk would — General (name, category, terms, reconciliation account), Payment (tax ID and IBAN) and Contact (billing e-mail) — then saves. As it enters the IBAN, the ERP runs it through a mod-97 checksum and shows the result live; a failed checksum blocks the save entirely, so a vendor that saves is a vendor whose bank details are structurally sound.
3. Confirm & report
The robot reads back the created record — its new vendor ID, the saved status line and the checksum result — and writes it to a CSV. The change to the vendor master is now auditable, and the supplier is live and payable in the ERP.
Running it
Ready to run as-is. It signs in with the published training credentials
(hiroshi.tanaka@globex.example for the mailbox, HTANAKA for the ERP), which are not secret. Real
system credentials belong in the Robomotion Vault, never in a flow.
More web automation templates
See all 16 →- Bank ReconciliationTakes the payments and receipts the ERP could not reconcile and confirms each one against the real bank statement. It pulls the ERP's flagged paid-bill exceptions and open invoices awaiting cash, then signs in to the bank, searches the operating account by reference and reads what actually settled - quantifying the four ways money and ledger drift apart: a missing payment, a transposed amount, a double payment and unapplied cash. Writes a reconciliation CSV. The story is evidence: the ledger raises the question, the bank statement answers it, and every discrepancy comes out with a number attached.
- Logistics Exception CenterBuilds one worklist of every active delivery exception from the carrier, then dedupes it against the systems that may already be handling it - the mailbox that was notified, and the help desk where a ticket may already exist. Joining the three on the tracking number tells the robot which exceptions were mailed, which already have a ticket, and which nobody has picked up yet. Writes a consolidated exception CSV. The story is consolidation: three systems each hold part of the picture, and the robot joins them so a stuck shipment is neither missed nor double-worked.
- Monday Morning BriefingOne robot, every system, the whole week's work on a single page. It signs in to the CRM, the mailbox, the ERP, the carrier and the help desk in turn, reads the one number that matters from each - duplicate contacts, invoices to post, ledger exceptions, stuck shipments and refund requests - and writes a consolidated briefing with a total across all five. The story is reach: the back-office queues a team would open one browser tab at a time, gathered into one report before anyone has had coffee.
- CRM Duplicate CleanupCleans up a CRM by merging duplicate contacts - the same person entered twice under name variants like Bob and Robert. Signs in, switches the contact list to its duplicates view, and merges the first remaining pair until none are left, keeping the primary record and folding each variant into it. Writes a before-and-after report. The "your CRM cleaned itself while you slept" demo.
- E-Invoice Portal HarvestDownloads every e-invoice for a tax period from a government portal and builds an index spreadsheet of what was collected. Signs in with a one-time code, walks the paged register until the portal says there are no more pages, then opens each document to read its government reference number and pull down both the XML and the PDF. Every download is gated behind a confirmation dialog and an "I am not a robot" checkbox.
- Friday Payment RunPrepares a weekly vendor payment run in the ERP. Signs in, proposes every bill due within seven days and confirms the run, then separately opens the bills list, filters to the blocked bills the run left out, and reports each one with the reason it is on hold - a pending goods receipt, a quantity or price mismatch against the purchase order, or a missing PO reference. Writes a CSV of what will be paid and what will not.