Accounts Payable IBAN Verification: A Step-by-Step Guide

Accounts payable teams are the last human checkpoint before money leaves your organization. In high-volume AP environments, the pressure to process payments quickly creates systematic risk: IBANs that were submitted informally, entered without validation, or changed without a documented approval trail flow into payment runs and generate failures, recalls, and occasionally fraud losses.

This guide provides a step-by-step IBAN verification process for accounts payable teams — from the moment a new vendor submits bank details through to the pre-payment final check. It is designed to be implemented without expensive software changes, using tools available today.

Why Is IBAN Verification an AP Responsibility, Not Just a Finance Control?

IBAN verification sits most naturally in the AP workflow for a simple reason: AP is where the data enters and where payments are executed. A control that lives somewhere else in the organization — in treasury, in IT, in compliance — will always have gaps when the AP team processes a payment on an exception basis or under time pressure.

Building IBAN verification into the AP workflow, rather than treating it as a separate compliance step, also creates accountability where decisions are made. The AP team member who processes a payment should be the one who verified the IBAN — not because they are solely responsible for fraud prevention, but because verification-at-execution is faster, more accurate, and more consistently applied than verification-before-archive.

Step 1 — How Do You Collect Vendor IBANs Securely?

The collection method determines your exposure. Email is the highest-risk channel for bank detail collection because it is the primary vector for BEC fraud. A fraudster who has access to a vendor's email thread can intercept a bank detail request and substitute their own IBAN in the response.

Minimum standard for new vendors: use a secure vendor onboarding form (a portal login, a signed document, or a credentialed upload link) rather than accepting bank details by email. If email is unavoidable, require a callback confirmation: after receiving bank details by email, call the vendor using a phone number you sourced independently — from a website, a previous invoice, or a known contact — and verbally confirm the IBAN.

For existing vendors submitting an IBAN change: apply the same callback requirement. The rule is simple: any time bank details are submitted or changed, confirm through a channel you initiate and that you did not receive the bank details through.

Step 2 — How Do You Validate the IBAN Structurally?

Once bank details are received and the callback has been completed, run structural validation before entering the IBAN into your payment system. Structural validation confirms:

• The country code is a recognized IBAN country (not all 2-letter codes are IBAN countries)
• The total length matches the specification for that country
• The BBAN format — the bank and account number segment — is correctly composed
• The MOD-97 check digits are mathematically valid

Paste the IBAN into ibanchecker.cash for an instant check. If any validation step fails, do not enter the IBAN into your payment system. Contact the vendor and request corrected bank details.

For batch validation — for example, when onboarding a list of vendors, or importing data from a previous system — use the bulk IBAN checker to upload a CSV or Excel file and validate up to 100 IBANs at once. The output includes a status column and bank identification for each row, which you can use to filter and action failures.

Step 3 — How Do You Record the Vendor IBAN With an Approval Trail?

A validated IBAN that is stored without documentation creates a gap that auditors and investigators will need to fill later — often after a problem has occurred. For every vendor IBAN you store, record:

• The date the IBAN was received
• The channel through which it was received (email, portal, phone, letter)
• Whether callback confirmation was completed and by whom
• The date and method of structural validation
• The name of the AP team member who entered the IBAN into the payment system
• The name of the manager or second approver who authorized the record

This record does not need to be elaborate — a structured notes field in your ERP, a shared spreadsheet, or a ticketing system comment is sufficient. What matters is that the information is timestamped, attributed, and retrievable.

For IBAN changes, the record should additionally include the previous IBAN that was replaced and the reason for the change as stated by the vendor.

Step 4 — How Do You Handle High-Value or Unusual Payments?

Standard AP payments to established vendors with verified IBANs should flow through the normal process. High-value or unusual payments warrant additional scrutiny. Define thresholds in your AP policy — for example, payments above €25,000, payments to new vendors within the first three months, or payments where the amount is significantly higher than the vendor's historical average.

For payments above your threshold, apply a second-person review: the payment should be reviewed and approved by a second AP team member or finance manager before execution. This review should include confirming that the IBAN on the payment instruction matches the IBAN in the vendor master file — not just that the vendor name matches.

Fraudulent payment instructions often match the vendor name and invoice number while substituting a different IBAN. The second reviewer should explicitly verify the IBAN, not just the payee name.

Step 5 — How Do You Run a Pre-Payment Batch Validation?

Before submitting each payment run, validate all IBANs in the batch — even those that were validated when the vendor was onboarded. This pre-run check catches three categories of problem that ongoing validation does not:

Data corruption: An IBAN that was valid when entered may have been corrupted by a system migration, import error, or manual edit.

Closed accounts: A bank account that was valid 12 months ago may have been closed or merged into a different account. While IBAN validation cannot confirm that an account is currently active (that requires a real-time bank inquiry), it can confirm that the IBAN is still structurally valid and maps to an active bank.

Unauthorized changes: An IBAN that was changed without following the proper approval process will appear in the payment batch without a validation record for the new IBAN. The pre-run check provides an opportunity to catch these cases before payment.

Export the payment batch IBAN column and upload it to the bulk checker before submission. Investigate any IBAN that returns a failure or a bank name that does not match your records. Do not submit the payment run until all failures are resolved.

How Does API Integration Improve the AP Verification Workflow?

Manual validation steps are reliable but create friction that under time pressure leads to shortcuts. API integration removes the friction by making validation automatic at the point of data entry. The ibanchecker.cash API can be connected to your ERP or AP system to validate each IBAN the moment it is entered — before the record is saved — without requiring the AP team member to take any additional action.

For organizations using SAP, Oracle, or Microsoft Dynamics, validation can typically be implemented as a field validation rule or a custom exit point. For organizations using cloud AP platforms like Tipalti, Coupa, or Basware, the API can be integrated via webhook or custom field validation. For simpler setups, a Zapier or Make automation can trigger a validation call each time a new vendor record is created.

Last updated: June 2026