Skip to content
Gathena
da

Learn · Guide

Invoices that only exist behind a login, fetched on a schedule

Some suppliers, such as many utilities, never send the invoice. Someone has to sign in, find it, download it and file it, often with a code that arrives by email. This guide shows how that could run on its own in Azure. At each step it shows what runs, why this choice, and what keeps it safe.

Runs
on your schedule
Runs in
your own Azure
AI in the run
none

  1. Step 1

    First, check whether the portal can be skipped

    Many suppliers send the invoice by email if you ask, or if you switch it on in the portal's settings. Some countries go further. In Italy, VAT-registered businesses have had to issue invoices electronically through the national exchange system, SdI, since 2019, so a company registered there can receive them at one address, with no portal at all.

    Why this choice

    An invoice that arrives by itself needs no login, no code and no script to maintain.

    What keeps it safe

    There is no stored password and no script that can break when a portal changes.

    for the portals that remain

  2. Step 2

    How the script is made

    A builder agent, Claude Code, opens the portal with the Playwright CLI and finds the clicks: the sign-in, the invoice list, the download button. From that it writes a plain Playwright script. Playwright is Microsoft's open-source library for controlling a browser from code. The script goes into Git, and a deploy pipeline packs it with a browser into a container image.

    Why this choice

    The agent is used to build, not to run. The scheduled run is the plain script with no AI in it, so it does the same thing every time and makes no calls to a model.

    What keeps it safe

    The operator reviews and approves each change before the pipeline deploys it. The pipeline signs in to Azure with its own identity, so no password or key is stored in the code or the pipeline.

    Builder agent · Claude Code

    explores with Playwright CLI

    commits

    Git repository

    changes the operator approved

    on approval

    Deploy pipeline

    builds the container image

    pushes

    Container Registry

    holds the image

    deployed to Azure

  3. Step 3

    The scheduled run

    Azure Container Apps Jobs start the container on a cron rule you set, for example once a month after the invoice usually appears. The container opens a headless browser, which is a browser with no screen, runs the script, and stops when it is done.

    Why this choice

    Container Apps Jobs are made for runs that start and then stop. You pay while it runs, and there is no server to look after between runs. Microsoft's own Playwright image already holds the browser and everything it needs.

    What keeps it safe

    The run has its own managed identity, an Azure sign-in for the container, with access only to its own secrets and its own storage. The browser runs as its own user without administrator rights, as Playwright's documentation recommends for sites you do not control.

    Schedule · cron

    a rule you set

    starts

    Container Apps Jobs

    • one run, then it stops
    • the Playwright script
    • a headless browser
    • own user, no admin rights

    signs in and saves

  4. Step 4

    The login details: created, stored and used

    The login details are the portal's user name and password, and in scenario A below, the authenticator's setup key. Where the portal allows extra users, a separate user is created for the run. The person who holds the login types each value straight into Key Vault, Azure's store for secrets. From then on, only the run reads them, and only while it runs.

    Why this choice

    The password never passes through chat, email, the code or the builder agent. There is one place to protect it, and one place to change it.

    What keeps it safe

    Key Vault encrypts the secrets and keeps every version. The run's managed identity is the only identity allowed to read them, and only these secrets. People are given a role to set or change them. With Key Vault logging switched on, every read and every change is recorded. The run holds the values in memory only, and its trace starts after the sign-in, so no password or code ends up in the evidence it saves.

    1. 1 · Create

      A login for the run

      • a separate portal user, where the portal allows it
      • its access can be withdrawn on its own

    2. 2 · Store

      Typed straight into Key Vault

      • by the person who holds the login
      • never in chat, email, code or the builder agent
      • one secret each: user name, password, setup key

    3. 3 · Use

      Read by the run, at run time

      • its managed identity signs in to Azure; nothing is stored
      • allowed to read these secrets, nothing else
      • held in memory; the trace starts after sign-in

    4. 4 · Change

      Changed in one place

      • a new password is a new version in Key Vault
      • the next run uses it; nothing is redeployed
      • every read and change is logged

    used at sign-in

  5. Step 5

    The sign-in code: two scenarios

    Most portals ask for a second step after the password: a short code. How the run gets that code depends on what the portal offers. Scenario A, an authenticator app, is the one to prefer. Scenario B, a code by email, works when the portal offers nothing else.

    Why this choice

    In scenario A, the run makes the code from the setup key and the time, the same way the app on a phone does, so it needs access to nothing else. Scenario B needs read access to a mailbox and has to wait for the email.

    What keeps it safe

    In both scenarios, a missing or wrong code stops the run and alerts the operator. The run tries once, so it never locks the account. A run cannot read codes sent by text message: for those portals, ask the supplier for an authenticator option, or keep that portal manual.

    • A · Authenticator app

      preferred

      Set up once

      1. In the portal's security settings, choose an authenticator app.
      2. The portal shows a QR code and a setup key.
      3. The person saves the setup key in Key Vault, and can add it to their own app too, so a person can still sign in.
      4. They confirm with one code.

      Each run

      1. The run reads the setup key from Key Vault.
      2. It makes the current code from the key and the time; the code changes every 30 seconds.
      3. It types the code. There is no mailbox and no waiting.

      Watch for

      The setup key works like the phone itself: with it and the password, anyone can sign in. That is why it lives in Key Vault next to the password, and nowhere else.

    • B · Code by email

      when nothing else is offered

      Set up once

      1. Give the portal user an email address that is used only for these codes.
      2. Give the run read access to that one mailbox. Microsoft 365 can limit an app to named mailboxes, so it can read no other mail.
      3. Note the sender address the supplier's codes come from.

      Each run

      1. The run signs in with the password, and the portal sends a code.
      2. The run waits for a new email from that sender, received after the sign-in started.
      3. It reads the code, types it, and marks the email as handled.
      4. If no email arrives within a few minutes, the run stops and alerts the operator.

      Watch for

      The run can read a mailbox, so keep that mailbox for codes only, and keep the run's access limited to it.

    signed in

  6. Step 6

    Storage and alerts

    The invoice is saved in Blob Storage, named by supplier and month. Every run writes its log to Azure Monitor.

    Why this choice

    Blob Storage keeps every invoice in one place that the bookkeeping can link to.

    What keeps it safe

    When a page looks different from what the script expects, the run stops instead of guessing. It saves a screenshot and a trace, which is a recording of each step after the sign-in, and Azure Monitor alerts the operator.

    • Blob Storage

      saves · invoices · failure evidence

    • Azure Monitor

      logs · alert on failure

    talks to

  7. Step 7

    What the run talks to

    The run uses three services outside Azure. It signs in to the supplier's portal and downloads the invoice. It reads the mailbox only when the portal sends codes by email. And it leaves a draft entry with the invoice attached in the accounting system, through that system's API, for example e-conomic's.

    Why this choice

    The draft puts the invoice where the bookkeeper already works, so nobody has to fetch or attach it.

    What keeps it safe

    This is the only place the run writes into a business system, and it writes drafts only. It can never book and it never pays. Check each supplier's terms of use before you automate their portal, because some do not allow automated sign-in.

    • Supplier portal

      sign in, download

    • Mailbox

      only if codes come by email

    • Accounting · e-conomic

      a draft with the invoice

      ← writes a draft

    handed to people

  8. Step 8

    Who does what

    The operator approves changes to the script and fixes it when an alert comes. The bookkeeper reviews the draft and books it in the accounting system they already use. Whoever pays the bills pays this one in the bank, as today.

    Why this choice

    Fetching and filing are the repetitive part. Booking and paying need a person's judgement, so they stay with people.

    What keeps it safe

    The only orange line on the map is the one that writes into a business system, and a person stands at the end of it. Each role's card shows what it can see and do, and its limits.

    • Operator

      Through
      Git and the builder agent (Claude Code)
      Can see
      the script, the run history, the alerts
      Can do
      approve changesfix the script
      Limits
      no change runs before it is approved

    • The scheduled run · its own identity

      Through
      Azure Container Apps Jobs
      Can see
      its own secrets and storage; the portal
      Can do
      downloadsavewrite drafts
      Limits
      drafts only; never books or pays; stops on anything unexpected
      → writes drafts intoAccounting · e-conomic · a draft with the invoice

    • Bookkeeper

      Through
      the accounting system (e-conomic)
      Can see
      the draft with the invoice attached
      Can do
      review and book
      Limits
      outside the run

    • Whoever pays

      Through
      the bank
      Can see
      the booked invoice
      Can do
      pay
      Limits
      outside the run

Sources

Guide written 29 October 2026 from the providers' documentation as it stood that day.

Products are named as examples of the kind of system.

If some of your invoices only exist behind a login, we can look at which ones could be fetched this way, together with your IT, in-house or your IT partner.

Book a conversation