E-Invoice Portal Harvest
Overview
Downloads 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.
E-Invoice Portal Harvest
In a lot of the world, somebody spends the first morning of every month downloading e-invoices from a government portal, one at a time. Log in, wait for the code, search the period, open an invoice, confirm the dialog, tick the box that says you are not a robot, save the XML, save the PDF, go back, next one. Ninety-six times.
This flow does it in about three minutes, and the portal never notices.
It runs against FRS, the fictional Freedonia Revenue Service used for training. The data is entirely synthetic.
What it produces
einvoice-index.csvin your home folder — one row per invoice: document id, direction, counterparty and their tax id, issue date, gross, status, any exception the portal flagged, and the ETTN (the government's unique reference for the document).- Every invoice's XML and PDF, in a download directory under your temp folder. For the seeded register that is 96 invoices and 192 files.
A representative run:
Register page 1/10 - 10 rows so far
...
Harvesting 96 of 96 invoices across 10 pages
Harvested 96 invoices (62 received, 34 issued) in 187s
The portal flagged 3: FRS-2026-004001 Amount drift; FRS-2026-004417 Not found in ERP; FRS-2026-004432 Not found in ERP
Downloaded 192 files
How it works
1. Two-factor sign in
Tax number and password, then a one-time code on a second screen. The browser is opened with a download directory so the files the portal hands over land somewhere the robot can find them.
Note the Make Download Dir node: like optUserDataDir, Core.Browser.Open does not create
optDownloadDir. Something has to make it first.
The flow then waits for the dashboard before navigating anywhere. The session is written to
localStorage as the post-login redirect happens; navigate before that and the portal bounces the
robot back to the login screen.
2. Walk the result pages
The register pages ten records at a time. The robot scrapes a page, reads the pager to learn whether a next page exists, clicks Next, and goes round again. It stops when the Next button reports itself disabled — not after counting to a number somebody typed into the flow.
The pager also reports how many records it holds in total. The flow checks its scraped row count against that number and fails loudly if they disagree, so a silently missed page is an error rather than a shorter spreadsheet.
3. Harvest each invoice
Nothing in this flow changes the portal, so the robot jumps straight to each document by URL rather than clicking back and forth. The ETTN is shown only on the detail page, which is why every invoice has to be opened at all.
4. Two downloads, four clicks each
Click the button, wait for the dialog, tick I am not a robot, accept. Then the same four clicks again for the other format. The accept button stays disabled until the box is ticked, so the fact that the click lands at all is proof the tick registered.
The register's rows stack two values in one cell — the counterparty's name over its tax id, and on some rows an exception chip under the status. Both are split into their own columns. A newline left inside a CSV field would quietly turn one row into two.
5. Index what was collected
The index joins what the register listed with what only the detail page knows.
Running it
Ready to run as-is. It signs in with the published training credentials (FD-380417225), which are
not secret, and a static one-time code.
?chaos=toast-kill on the URLs turns off the portal's toast notifications for the session. Each
download raises one, and a toast is a fixed overlay: a real mouse click that lands on it is
swallowed silently — the click node reports success and nothing happens. Real portals will not hand
you a flag like that, so on one you would wait for the overlay to clear or click through the DOM.
To try the mechanics without waiting for all 96, set msg.limit in the Setup node to a small
number. 0 means the whole register.
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.
- 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.
- Invoice Inbox to LedgerReads vendor-invoice e-mails out of the mailbox and posts each one as a bill in the ERP. It reads the vendor, reference, gross and purchase-order number from each message, derives the net, and keys a new bill - handling the two controls that fire mid-batch: a duplicate reference (cancelled rather than paid twice) and a failed 3-way match against the purchase order (posted but blocked). Writes a posting report. The story is straight-through processing with judgment: the clean invoices post themselves, and the two that should not go through are caught and reported.