Tax Portal ERP Reconciliation
Overview
Reconciles the e-invoices a government tax portal received against the vendor bills booked in the ERP, and reports the three ways the two can disagree: an amount that drifted, an e-invoice with no matching bill (arrived in the portal, never booked), and a bill with no e-invoice (booked, never filed). Two-factor signs in to the portal, pages the received register, then filters the ERP vendor-bill worklist per enrolled vendor to compare counts. Writes a reconciliation CSV. The story is a control: two systems that should hold the same set of documents, checked against each other so a gap is caught rather than discovered at audit.
Tax Portal ERP Reconciliation
Two systems are supposed to hold the same set of documents: the government tax portal, where every supplier files an e-invoice, and the ERP, where finance books every bill. When they disagree, nobody notices until an audit — a bill that was never filed, an e-invoice that was never booked, a gross amount off by two cents. The valuable robot reconciles the two on a schedule and reports every gap while it is still cheap to fix.
This flow does exactly that. It reads the portal's received e-invoices, counts the matching bills in the ERP, and reports the three ways they can disagree.
It spans two fictional training systems — FRS, a government tax portal, and RAP One, the ERP — whose data is entirely synthetic.
What it produces
portal-erp-reconciliation.csv in your home folder: every enrolled vendor with its ERP bill count
against its portal e-invoice count, plus the three exception classes. On the seeded data that is
62 received e-invoices across 6 enrolled vendors, and three findings:
- Amount drift — one e-invoice whose gross is €0.02 over the ERP bill (a rounding tolerance to classify).
- Not found in ERP — two portal-only e-invoices with no bill (arrived in the portal, never booked).
- Missing in portal — one vendor whose ERP bill count exceeds its e-invoice count by one (a bill booked but never filed).
How it works
1. Read the portal
Two-factor sign in as the company, filter the register to received e-invoices, and page through every result ten at a time — stopping when the pager reports no next page, not after a hardcoded count. Each row carries the counterparty and gross; the portal itself tags an amount drift or an e-invoice it could not match to the ERP.
2. Count the bills in the ERP
The vendors that file e-invoices are exactly the portal counterparties that reconcile. For each one, the robot signs in to the ERP, filters the vendor-bill worklist to that vendor and reads how many bills it holds — one number per enrolled vendor.
3. Reconcile & report
Per vendor, the ERP bill count should equal the portal e-invoice count. Where the ERP holds more, a bill was never filed — missing in the portal. Together with the portal-flagged drift and the unmatched e-invoices, all three exception classes land in one CSV, ready to work.
Running it
Ready to run as-is. It signs in with the published training credentials — the portal tax number
FD-380417225 with a static one-time code, and the ERP user HTANAKA — 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.