Skip to content
Browserberg Browserberg
Use cases

Supplier invoices, collected from every portal

Suppliers who stopped emailing invoices now expect you to fetch them from a portal. A workflow signs in with a vaulted credential, reads the invoice list as JSON and posts it to your accounting system every month.

Start free Book a call

How the monthly run works

One workflow per supplier portal, one schedule that fires them. Each block below is a plain JSON object; the labels become the variables later blocks read.

  1. Store the portal credential once

    Create a credential in the vault with the portal’s sign-in URL. The workflow refers to it by id; the password itself is released only on that site, at the moment of typing, and never appears in a run’s output.

  2. Sign in and open the invoice list

    A login block drives the sign-in, including a TOTP code if the portal asks for one. A navigation block then opens the invoice overview directly rather than clicking through menus that change.

  3. Read the invoices as data

    An extraction block turns the table into JSON against a schema you define: number, date, net amount, document link. Rows that do not fit the schema are reported rather than guessed.

  4. Hand the result to your ERP

    An http_request block posts the extracted list to your own endpoint. Your system decides what is new; the browser only did the part that needed a browser.

  5. Let the schedule run it

    A schedule trigger fires the workflow on the first of the month in Europe/Berlin time. A missed night is one firing, not a backlog, and every firing is recorded with its outcome.

The whole thing in one publish

import { Browserberg } from '@browserberg/sdk';

const bb = new Browserberg({
  apiKey: process.env.BROWSERBERG_API_KEY,
  baseUrl: 'https://browserberg.com',
});

const wf = await bb.workflows.publish({
  title: 'Monthly invoices from ACME supplier portal',
  blocks: [
    { blockType: 'login', label: 'Sign_in', credentialId: 'cred_acme_portal' },
    { blockType: 'navigation', label: 'Open_invoices', url: 'https://portal.acme-supplier.example/invoices' },
    { blockType: 'extraction', label: 'Read_invoices',
      instruction: 'every invoice issued this month: number, date, net amount and document link',
      schema: { type: 'object', properties: { invoices: { type: 'array', items: { type: 'object',
        properties: { number: { type: 'string' }, date: { type: 'string' },
                      net: { type: 'number' }, url: { type: 'string' } } } } } } },
    { blockType: 'http_request', label: 'Post_to_erp', method: 'POST',
      url: 'https://erp.internal.example/hooks/invoices', body: '{{ Read_invoices_output }}' },
  ],
});

await bb.triggers.create(wf.workflowId, {
  kind: 'schedule', name: 'First of the month',
  cron: '0 6 1 * *', timezone: 'Europe/Berlin',
});

What you get

Credential handling Vaulted, referenced by id, released only on the grant site; TOTP supported
Output JSON matching your schema, plus a per-run record of every block
Schedule semantics Cron plus an IANA zone; daylight-saving changes fire once, never twice
When a portal changes The run fails with the block named; a healing proposal may suggest the fix for you to adopt
Where it runs EU bare metal; the portal sees a normal Chromium session under your own account
Evidence Hash-chained action log with the run id, exportable and verifiable offline

As of 2026-09-04

Questions accounting teams ask

Does the invoice PDF itself get downloaded?

The workflow reads the invoice data and the document link for each row. Fetching the file is best done by your own system from that link, where it can be stored under your retention rules; the browser step exists to get past the sign-in and the table.

What happens when the supplier changes their portal?

The extraction block reports what it could not read instead of inventing values, and the run is marked failed with the block named. If a heal proposal is generated, a person adopts or rejects it; nothing rewrites your workflow on its own.

Can several portals share one workflow?

Better not. Each portal has its own credential, its own URLs and its own table, so one workflow per portal keeps a failure local. The schedule trigger is cheap to repeat.

Does the supplier see automation?

They see a Chromium session signed in with the account you hold. There is no stealth layer and no attempt to hide the session, which is also why this is only for portals where you are the customer.

Read next

Try it on one supplier portal

Five browser hours, no card. The first workflow takes an afternoon; the schedule takes a minute.

Start free Book a call