An invoice collector can look like a supplier directory, a desktop app, an API or a browser workflow. For the developer connecting it to finance operations, those interfaces hide an important distinction: what work does the integration actually start, and what can the application rely on afterward?
Our vendor-portal invoice downloader comparison surveys the product choices. This article takes a different angle: a proposed adapter contract for evaluating one exact account before committing to an integration. It is a design guide, not a benchmark or a report of authenticated portal tests.
1. Does this call collect documents or query existing ones?
A tool named get_invoices might query an existing document workspace. Another tool might initiate a browser visit and produce files later. Do not infer the behavior from an API method name or the presence of MCP support.
Ask what triggers fresh collection, how freshness is represented, and whether a caller can tell the difference between a cached record and a new retrieval attempt. A read-only query can be exactly what you need when collection already happens elsewhere. It cannot prove a new supplier document was fetched on demand.
Keep request acceptance, task completion and archive verification as separate events. Returning a task identifier means the request was accepted; downstream finance work should wait for the evidence it actually needs.
2. Can the request express the real account scope?
A connector logo is a discovery aid, not an acceptance test. Evaluate the country, account type, permissions and historical period used by the actual finance process.
An application-side request could look like this:
{
"supplier_ref": "example-supplier",
"account_ref": "finance-account-A",
"period": {
"basis": "invoice_date",
"start_inclusive": "2026-10-01",
"end_exclusive": "2026-11-01"
},
"document_types": ["invoice_pdf", "credit_memo_pdf"],
"destination_ref": "approved-finance-archive"
}
These are illustrative fields, not a BrowserAct or supplier API schema. A specific Bot, connector or API has its own documented inputs. Avoid silently dropping an unsupported field when translating the request; report the gap before running a broader collection than intended.
Use references rather than embedding credentials or storage secrets in this request. A readable job log should not become a second credential store.
3. What does a returned URL actually deliver?
A URL can identify a workspace record, a temporary download, a printed page or an original supplier file. Those are different outputs. Check the actual document type and bytes rather than treating a nonempty link as a completed archive.
If access expires, copy the authorized file into the approved destination while access is valid. Preserve provenance: supplier, account reference, document identifier, retrieval time and relevant version information. A checksum helps compare bytes; it does not establish that an invoice belongs to the expected account.
Also separate invoice documents from supporting data. Shipment-level CSV data can help reconcile charges, but its availability does not establish possession of the supplier's invoice PDF.
4. Who owns the runtime and renewed access?
For a local route, identify the machine and process that must be available. For a managed route, establish how authorized access is configured and how exceptions reach the responsible person. Check these details with the actual product rather than assuming all desktop or cloud tools behave alike.
Include the person who handles renewed login, account changes and second-factor prompts. A connector that works once can still leave an operational gap when nobody owns the next access interruption.
Evaluate cost against this complete task. A low advertised subscription or usage unit does not tell you the cost of setup, exception handling and verified document delivery.
5. Can the adapter explain an incomplete run?
Start with a short list of known documents. Compare what was expected with what reached the archive, then run the same scope again. The second run tests duplicate handling and recovery behavior that a single successful download cannot show.
Require explicit unresolved outcomes: not listed, retrieval failed, file mismatch or access required. Preserve the account and filter context behind each outcome. Avoid collapsing them into a single success flag or retrying every document when only one failed.
BrowserAct can be evaluated as a workflow-building route alongside dedicated collectors. Its entry point does not remove these requirements. The useful integration boundary is a task whose scope, evidence and exceptions your application can explain, regardless of which product executes the browser work.
Top comments (0)