An invoice row is not an invoice file: designing a browser collection job

When a finance team asks for an invoice downloader, a successful browser interaction is only the start. A table containing invoice numbers and amounts can look convincing while the archive still has no original documents.

The useful engineering question is: which files did this run actually retrieve, and how can the next run prove it did not miss or duplicate them?

This is a design walkthrough adapted from our BrowserAct architecture guide. It is not a report of a tested supplier-portal integration.

Start with the acceptance contract

Before choosing an Agent, a Cloud Bot or an MCP client, define a small job:

• One supplier portal and its regional variant.
• An explicitly authorized account scope.
• An invoice date range.
• Required document types: original PDFs, credit notes or detail exports.
• A destination the finance team can actually access.
• A way to reconcile expected documents against retrieved files.

Keep extracted fields and original documents separate. Shipment-detail CSVs can help reconcile charges, but they do not establish that an invoice PDF exists in the archive.

A manifest might look like this:

{
  "supplier": "example-supplier",
  "account_ref": "account-alias",
  "period": "2026-10",
  "invoice_id": "INV-1042",
  "document_type": "invoice_pdf",
  "status": "retrieved",
  "archive_path": "invoices/2026-10/INV-1042.pdf",
  "bytes": 48216
}

Those are illustrative application fields, not a BrowserAct API schema or an actual downloaded invoice. Add a checksum and reconciliation fields if your archive needs them. Keep credentials out of the manifest.

Treat the job as several states

One completion flag hides too much. A useful collection process distinguishes:

1. Discovered: the portal lists an invoice.
2. Retrieval requested: a download or export action started.
3. Retrieved: the file bytes reached the intended destination.
4. Verified: the document type and invoice identifier match expectations.
5. Reconciled: the expected set has no unexplained gaps.

A portal may generate a file asynchronously. It may return an expiring link rather than a durable archive copy. An export can contain several invoices in one PDF when the team expects separate files. Model those outcomes before deciding what a successful run means.

For retries, use supplier, account, invoice identifier and document type as a candidate deduplication key. Validate the key against the supplier's identifiers; invoice numbers alone may not be globally unique.

Put each interface in the right place

Cloud Bot: a named, reusable task is a useful starting point when finance staff own the recurring process. Inputs should describe the account and period. Outputs should include the agreed documents and an exception list.

Template: a copyable starting configuration helps another customer build a similar job. Their credentials, regional portal and copied workflow still need their own validation.

Agent plus CLI: useful when a developer owns browser execution and the archive. A Skill can preserve the tested operating procedure, supported portal variant and recovery steps.

MCP: a way for an AI client to discover and call available tools. In BrowserAct's documented Cloud flow, the client can run a published Bot or official template and retrieve results. Connecting the client does not create a portal collector automatically.

Inspect retrieval before promising automation

For an Agent-owned job, BrowserAct's CLI exposes browser sessions, page state and media-resource inspection. An inspection sequence can start with:

browser-act --session invoice-audit browser open <browser-id> <vendor-portal-url>
browser-act --session invoice-audit state
browser-act --session invoice-audit media resources list

The angle-bracket values are placeholders. Use an existing authorized browser and the actual portal URL. Listing resources does not guarantee the requested invoice is present; select only a resource returned by the current session. A portal may require a different retrieval path.

Do not turn a click into a claim that a PDF was saved. Establish the real retrieval mechanism, verify the resulting bytes, and only then package the tested procedure into a reusable Skill or Bot.

Make exceptions part of the output

Login renewal, account confirmation, missing invoices and unavailable documents should produce explicit outcomes. Preserve enough state to resume without starting the entire collection again. Keep account access scoped to the task and provide an authorized human handoff when needed.

The repeat-run check matters as much as the first download: run the same period again, check duplicate handling, then test a period containing a known missing document. Those are proposed acceptance checks, not tests performed for this article.

If the supplier already offers a complete native export, email delivery or API feed, evaluate that route first. Browser work earns its place when it closes a remaining operational gap.

The interface should make a reliable document job easier to request. The documents and the reconciliation are what make it useful.

Further reading: BrowserAct's invoice architecture guide, CLI command reference, and MCP integration documentation.

Disclosure: this article comes from the BrowserAct team. The manifest and acceptance checks are design examples; no customer invoice data or validated portal-specific collector is presented.