Reference · built on requestOperator by FibricFinance & billing

Vendor Bank Change

A change to a vendor's remittance details detected in the ledger or the inbox, with a payment hold proposed until a callback confirms it.

Request accessPricing ↗

About

The email asking accounts payable to update a supplier's bank account is a common route for payment fraud, and the change itself is quiet: one field on one record. This operator watches the vendor records in your ledger or procurement system for changes to bank details, remittance email, or address, and watches the AP mailbox for requests to make them.

When it sees either, it proposes three things: a hold on payments to that vendor, a callback task to the phone number on file before the change, and an alert to the controller with the old and new values side by side. If the callback fails, it proposes reverting the record. Every step waits for approval and is written to the vendor's record.

This is a reference listing. It documents what Fibric would read from Vendor Bank Change and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Xero contacts whose BankAccountDetails, EmailAddress, or addresses changed, found by UpdatedDateUTC and the contact's History entries
  • Business Central vendors changed since the last poll, by lastModifiedDateTime, with email, phoneNumber, address, and paymentMethodId compared
  • Coupa suppliers with changed remit-to addresses or payment method, and the user who updated them
  • Vendor records in NetSuite, QuickBooks Online, or Sage Intacct, compared field by field between polls
  • Messages in the AP Gmail mailbox that ask for a bank, remittance, or address change, and their sender domain
  • Bills approved and payments scheduled to the vendor, so the hold lands before the next run
  • Callbacks recorded against earlier changes, so a confirmed change is not raised again

Proposed actions

  • Target capability: propose a hold on all scheduled payments to the vendor until the change is confirmed
  • Target capability: propose a callback task to the AP owner using the phone number on file before the change, never one from the request
  • Target capability: propose an alert in Slack or Microsoft Teams to the controller with old and new values, who changed them, and when
  • Target capability: propose reverting the vendor record to its prior values when the callback fails or goes unanswered
  • Target capability: propose recording the confirmation on the vendor: who called, whom they reached, the outcome, and the date

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Hold the payment, then call

    A Xero contact's BankAccountDetails changes. Bills to that contact are proposed for hold, a callback task goes to the AP owner in Slack with the number on file, and the receipt records the outcome.

    With Xero, Slack

  • See the request before the change

    An email to the AP Gmail mailbox asking to update remittance details is raised with its sender domain, and any Business Central vendor edit that follows is held until confirmed.

    With Gmail API, Microsoft Dynamics 365 Business Central

  • Coupa supplier edits with the editor named

    Changed remit-to addresses on Coupa suppliers are alerted to the controller in Microsoft Teams with the updating user shown, and payments held pending the callback.

    With Coupa, Microsoft Teams

  • Revert when nobody answers

    A NetSuite vendor change with no confirmed callback after your interval is proposed for reversion to the prior values, with the hold kept in place and the vendor told by Amazon SES.

    With NetSuite, Amazon Simple Email Service

Requirements

  • A ledger or procurement connector exposing vendor records and their modified timestamps: Xero, Business Central, Coupa, NetSuite, QuickBooks Online, or Sage Intacct
  • A chat or email connector for the alert and the callback task: Slack, Microsoft Teams, or Amazon SES
  • Optionally, the AP mailbox through the Gmail API, so requests are seen before the record changes
  • A phone number of record for each vendor, captured at onboarding and kept apart from the request
  • A hold mechanism: a blocked flag on the vendor, a payment approval step, or removal from the payment batch
Authentication
It holds no ledger or mailbox credentials of its own. Vendor records, messages, and payment schedules are read through the connectors you attach with the scopes you grant.

Limits

  • It sees changes in the systems you attach. A change made directly in a bank portal or payment platform outside them is not seen.
  • Where a system has no change history, detection compares snapshots between polls. The old value is known; who changed it may not be.
  • It does not make the call or judge the voice. A person calls the number on file and records the result.
  • Business Central's vendor API exposes payment method and contact fields, not bank account numbers. Changes there are detected through the fields it does expose.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Vendor Bank Change ↗

Questions and answers

Which steps need approval?
The hold, the callback task, the alert, and any reversion are separate proposals. Each shows the vendor, the field changed, old and new values, the change source, and payments affected. Approve, edit, or decline each.
What ends up on the vendor's record?
A receipt on the vendor: the change detected, the hold placed, who called which number, whom they reached, the result, and who approved each step. Reversions record the values restored.
Does it ever release a held payment on its own?
No. A hold is placed and lifted only on approval, once each. Recording a confirmed callback proposes the release; a person still approves it.
Ask about Vendor Bank Change

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy