Payroll Validation Gate
Overview
Checks a month's payroll before it is posted. Signs in, opens the draft run, reads the register and refuses to finalize when a row is missing its cost centre, then confirms the register's net total matches the salary debit in the operating account. Writes a check report. The story is judgment: the robot stops on bad data rather than posting it, and proves one number agrees across the HR system and the bank.
Payroll Validation Gate
Payroll is the one process where a robot that blindly does what it's told is dangerous. Post a run with a bad row and you've either paid someone wrong or filed the cost against the wrong budget — and either way, someone spends a week unwinding it. The valuable robot here is the one that stops.
This flow is that robot. It reads the draft payroll register, refuses to finalize when a row is missing its cost centre, and confirms the total actually matches what left the bank — before anyone posts anything.
It runs against Workmonth, a fictional HR system used for training. The data is entirely synthetic.
What it produces
payroll-check.csv in your home folder: the register row count, any rows the gate stopped for,
whether the run is safe to finalize, and the net-total-versus-bank reconciliation. On the seeded
draft run that is 85 rows, one row missing a cost centre, finalize blocked, and a net total of
€247,225.23 that matches the bank debit exactly.
How it works
1. Open the draft run
Sign in and open the payroll runs. The month still being worked is a Draft; completed months are locked. The robot opens the draft to inspect its register.
2. Validate the register — the gate
It reads every row and finds the ones missing a cost centre. Payroll cannot be posted to the ledger with an unclassified row, so the finalize button is blocked. The robot honours that gate and reports the offending row rather than forcing the run through — this is the whole point.
3. Confirm the bank agrees
Then it reads the reconciliation panel: the register's net total against the salary debit in the operating account. When one number matches across the HR system and the bank, the payroll is real, not a spreadsheet error. The robot records that agreement.
4. Report
The report is what a payroll manager needs: the blocked row to fix, and the confirmation that the money is right. Fix the cost centre, and the run is safe to post.
Running it
Ready to run as-is. It signs in with the published training credentials
(priya.sharma@globex.example), which are not secret. Real system credentials belong in the
Robomotion Vault, never in a flow.
More web automation templates
See all 20 →- Any browser: Edge and FirefoxA browser flow built from Web Automation nodes that signs in to Acme ERP Web and searches the customers, run on a robot in Edge and then in Firefox, with only the Browser Type changed.
- Headless ChromeThe Web Inspector lesson's flow, run first headed so you can watch it, then headless with Record Session, so the robot keeps a video of the run nobody saw.
- Payment Run with Hold ReportRuns the weekly vendor payment run in a SAP-style ERP and then accounts for every bill it refused to pay. Signs in with credentials read from the Robomotion Vault, proposes the bills due within seven days, confirms the run so a journal entry is posted per document, and verifies the posted summary against the proposal before going on. Then it opens the bills list, filters to the blocked bills, 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 two-section CSV covering what was paid and what was held back, with the value held back totalled.
- Shipment Status ReportSigns in to a carrier portal and sweeps every page of the shipments list into one report, then narrows that sweep to the shipments that need a person. Reads the login from the Robomotion Vault, walks the pager with a Label and a GoTo until the Next control is disabled, and writes two CSVs: the full book, and an exceptions file covering customs holds, failed deliveries and delays, oldest booking first, with the billed value stuck in each one. Closes with a Log line carrying the counts and the total.
- 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.