Troubleshoot Supplier Bank Approvals
This article covers the Vendor Bank Approvals page: rows that refuse to be approved, and approvals that do not do what you expected. Every row keeps its own reason in the What Happened column, so start there.
Before troubleshooting a refusal, be sure it should be approved. This list exists to stop money going to the wrong account, and most refusals are the control working.
This account cannot be approved: reason
Cause: The proposed account number fails the ISO 13616 check — its check digits or its length are wrong for the country.
Solution: Do not correct it yourself. A malformed account number on a supplier invoice is either the supplier's typo or a sign the document was altered, so confirm the real account with the supplier by phone before doing anything. Then create the bank account by hand and reject the row.
The related message on a document is:
The IBAN number on this document fails the ISO 13616 check (check digits or country length). Ask the supplier to confirm it before accepting: a malformed number is either their typo or a sign the document was altered.
This row is not linked to a vendor yet. Use Assign Vendor first.
Cause: No vendor could be identified from the sender, so there is nobody to attach the account to.
Solution: Choose Assign Vendor and pick the vendor. That also fills in the vendor's Peppol Endpoint if it was blank, so later documents from the same sender match on their own.
The fuller version of this refusal explains why it is not simply skipped:
Assign a vendor first. Until this row names a vendor there is nothing to attach the account to, and approving it would record a decision about nobody.
Only an open row can be approved. This one is status.
Cause: The row was already decided.
Solution: If you need to review it again, choose Reopen. Note that a rejected account is never reopened automatically, however often it arrives — later documents carrying it only raise the Times Seen count.
Only an open row can be rejected. This one is status.
The same rule applies to the other actions, each with its own wording: Only an open row can be assigned to a vendor. when you choose Assign Vendor, and This row is already open. when you choose Reopen on a row that was never decided.
Cause: The row has already been decided.
Solution: Choose Reopen to put a decided row back to Open, then decide again. A rejected account is never reopened automatically, however often it arrives.
The vendor already carries this account
The vendor already carries this account, so there was nothing to approve. The row is closed as No Longer Needed.
Cause: Somebody added the account to the vendor in the meantime.
Solution: Nothing. The row closes as No Longer Needed, which is a record that it was reviewed rather than ignored.
There are already 99 vendor bank accounts starting with code for vendor number.
Create the account by hand and reject this row.
Cause: The code from Vendor Bank Account Code and all 99 numeric suffixes are taken for this vendor.
Solution: Exactly what the message says — create the account by hand and reject the row. If you hit this legitimately, the vendor's bank accounts are worth a clean-up.
Approving changed nothing on the vendor
Recorded only. No bank account was created — Approved IBAN Action on the E-Invoice Platform Setup page is set to Record Only.
Cause: Approved IBAN Action is Record Only, which files the decision without touching the vendor.
Solution: If you want approvals to create the account, change the setting to Create Bank Account. Only choose Create and Set Preferred where you trust the approval step completely — that option redirects payments, which is what invoice fraud is aiming for.
The account was created but payments still go elsewhere
Vendor bank account code was created. It is not the preferred account, so nothing is redirected until someone chooses it.
Cause: Create Bank Account adds the account without nominating it.
Solution: This is the intended behavior. If the new account should receive payments, set Preferred Bank Account Code on the Payments FastTab of the vendor card deliberately.
Vendor number has n bank accounts with an IBAN and no preferred one
so we cannot tell which to invoice into. Set Preferred Bank Account Code on the vendor card.
Cause: Several accounts, none nominated.
Solution: Set Preferred Bank Account Code on the vendor card.
Approving fails with a permission error
Cause: Approving can write a vendor bank account, which is standard purchasing data this app does not grant on its own.
Solution: Ask for the D365 PURCH permission set. See Permission Sets.
No payment details were sent with this document
Cause: The supplier's document carried no payment means. There is nothing to approve.
Solution: Nothing to do here. If you expected bank details, ask the supplier — and note that no public register links an IBAN to a company, so they cannot be looked up.
One variant is worth reading carefully:
No payment details were sent with this document. The invoice is paid to vendor number but names vendor number as the supplier, and a self-billed document cannot state a different payee.