Visa, BILL and Billtrust pilot agent-executed invoice payments

The announcement

Visa, BILL and Billtrust announced a live pilot on 20 October in which authorised agents complete approved invoice payments through supplier portals. Visa says the arrangement uses agent authentication, tokenised credentials and controls linked to buyer instructions, while retaining supplier acceptance policies. Participating BILL buyers and Billtrust suppliers are processing transactions. The agent executes an eligible payment already approved by the buyer; it does not decide which invoices should be paid. This is a pilot, not universal merchant availability.

Independent merchant analysis: identify the decision boundary

The useful starting point for a business considering this model is a diagram of its existing approval process. An invoice may be valid, accepted by procurement and scheduled by treasury without being ready for immediate execution. Discounts, disputes, credit notes and cash planning can change the amount or date. Software permission should therefore reflect the final approved instruction, not merely the presence of an invoice in an accounting system.

Give each decision an owner. Procurement confirms that the purchase belongs to the business. The receiving team confirms delivery where relevant. Finance resolves the amount and accounting treatment. Treasury controls the payment schedule. The execution service then acts within the approved scope. These suggested responsibilities may sit with fewer people in a small business, but the records should still distinguish them. One broad approval label makes later investigation unnecessarily difficult.

Bind execution to the correct invoice version

A hypothetical supplier submits an invoice for ten units, then issues a credit note for two returned units. If an agent operates from the original invoice while finance has approved the adjusted balance, successful technical execution would produce the wrong commercial outcome. The payment instruction should identify the approved document version, amount, currency and relevant adjustments. A change after approval should enter a defined review process rather than silently changing the executable amount.

Use a stable obligation reference that survives retries and system handoffs. The buyer's invoice identifier, the supplier's account reference and the payment provider's transaction identifier may all be different. Preserve their relationship instead of forcing every system to use one display label. Accounts receivable staff should be able to locate the payment without reading an agent's entire activity log, while an investigator should be able to reconstruct the full sequence when needed.

Preserve the supplier acceptance policy

Automation should not become a way to ignore how a supplier accepts payment. Ask the implementation team how the permitted method, amount, currency and account are established before execution. If the portal rejects the proposed route, the workflow should return a clear exception. It should not improvise another beneficiary or submit altered information simply to make the payment succeed. An authorised agent needs a bounded task, not an instruction to pay by any available means.

Suppliers should review their own payment pages as operational interfaces. Clear account identification, invoice selection and confirmation records help both people and permitted automation. A portal that permits a payment but cannot explain which invoice it settles still leaves finance with manual work. Test partial payments, combined invoices and credits according to the actual acceptance policy, and keep unsupported scenarios outside the initial deployment.

Design for uncertain results

The difficult case is often a payment submitted just before a connection fails. The buyer does not know whether execution completed, while the supplier may already have received an authorisation. Repeating the instruction without checking can create a duplicate. Define the authoritative status source, the query procedure and the point at which a person takes over. Keep the obligation pending until the uncertainty is resolved.

A retry should retain the relationship to the original attempt. Engineering should demonstrate how repeated messages, delayed confirmations and interrupted sessions are handled. Finance should test whether these events create duplicate ledger entries or unexplained balances. A successful response from a browser interaction is not necessarily the same as confirmed settlement, so distinguish submitted, authorised, completed and reconciled states in the operating model.

Review access and revocation

A business should know how it can withdraw an agent's authority when circumstances change. Consider a compromised account, an employee leaving, a disputed supplier relationship or an incorrect payment batch. Specify who can stop new instructions and how already submitted transactions are identified. The stop procedure should be tested before the business relies on the automation during a busy payment cycle.

Access reviews should address scope as well as identity. An agent permitted to execute a particular class of invoices should not automatically receive permission to edit supplier master data or approve a new beneficiary. Keep sensitive changes under their own controls. Ask the provider which evidence is retained about the instruction, its approval and its execution, and how the merchant obtains that evidence for an internal investigation.

Measure the whole receivables outcome

A supplier evaluating a pilot should measure more than the number of portal visits removed. Compare the time from approved obligation to payment confirmation, the time needed to apply cash, the number of unmatched receipts and the effort spent resolving exceptions. An automated payment that arrives with incomplete references can shift work from accounts payable to accounts receivable rather than remove it.

Use a defined population for the comparison. Choose invoices with similar terms and complexity, and record changes in customer mix or payment timing. Do not attribute every improvement to automation if the pilot also changes the payment method or the team handling the cases. Include the buyer's and supplier's support workload so that the operating result is visible on both sides of the transaction.

Set an accountable pilot agreement

Before processing real obligations, agree the pilot's scope, escalation contacts and criteria for expansion. List the documents and states the workflow supports, along with the cases that require human handling. Resolve who communicates with the counterparty when a payment is uncertain or incorrect. A technology demonstration can establish feasibility, but a live payment process needs an owner for the unresolved case at the end of the day.

Review pricing and liability under the actual contracts. The announcement does not provide a merchant-specific fee schedule, guaranteed savings or an answer to every dispute scenario. Ask how erroneous execution, duplicated instructions, provider outages and reconciliation failures are handled. Do not assume that familiar brands remove the need to understand the arrangement. Keep commercial approval separate from the technical decision to connect an integration.

Rehearse a case in which a supplier changes its portal layout while an approved payment is waiting. The correct response should be a controlled exception, not an agent guessing which field now contains the beneficiary reference. Include a case where the supplier account is closed and another where the invoice has already been paid through a different route. These tests expose whether the implementation recognises changes in the commercial obligation as well as changes in the screen. Document the evidence needed to resume execution, who can approve that decision and how the final outcome reaches both accounting teams. An exception record is valuable when the people reviewing the case were not involved in the original purchase.