Show whether an IBAN is for payroll or customer refunds, whether KYC is current, and if fraud monitoring raised a flag.
Overview
On each contact’s bank card, Accounting Pro can add classification, compliance, risk, and regulatory fields. This chapter focuses on the first four groups: how the account is used, how you verified it, and how risky it looks.
How it works
Standard Odoo already stores IBAN and bank name. Accounting Pro layers business meaning: Account usage type tells AP whether they may select it for payroll, KYC status tells finance whether payouts are allowed, and Risk level highlights accounts needing extra approval.
Step-by-step guide
- Open a customer or vendor, go to the Invoicing or accounting tab, and edit a bank account.
- Set Account usage type to the main reason this IBAN exists (payout, collection, refund, payroll, tax, escrow).
- Mark whether it is Primary, Backup, or a Country-specific default.
- Update KYC status as onboarding progresses.
- Record Verification source (manual, bank letter, micro-deposit, open banking, OCR).
- Enter Verification date and choose the Verified by employee once complete.
- Set Risk level and short Fraud flags notes if monitoring detected issues.
- Paste a link to your change log in Change history link when IBAN numbers changed recently.
- Select allowed Regulatory purpose codes, Beneficiary type, and Regulatory country profile for cross-border reporting.
Fields table
| Field name | Description | Example |
|---|---|---|
Account usage type |
Primary business reason this account number is kept. |
Payroll for hourly staff. |
Priority / default level |
Whether this IBAN should be chosen first or only as fallback. |
Backup when primary hits a limit. |
KYC status |
Know-your-customer progress for this bank relationship. |
Expired – refresh ID documents. |
Verification source |
How you proved the account belongs to the partner. |
Micro-deposit challenge. |
Verification date |
Date the verification succeeded. |
2026-04-02. |
Verified by |
Internal user accountable for the verification decision. |
Treasury analyst Luis. |
Risk level |
Low / Medium / High / Blocked for payout decisions. |
High after recent ownership change. |
Fraud flags |
Short reminders about monitoring hits. |
“Name mismatch vs trade register.” |
Change history link |
URL or reference to audit trail of IBAN edits. |
Link to ticket ACC-4412. |
Allowed purpose codes |
Which regulatory payment purposes may use this account. |
Goods + services only, not payroll. |
Beneficiary type |
Whether the account holder is a person, company, government body, or NGO. |
Government ministry account. |
Regulatory country profile |
Special handling flag for certain jurisdictions. |
High-risk jurisdiction profile. |
Field explanations
Each item matches one row in the table above, in the same order.
Account usage type
States the main reason this IBAN exists (payout, collection, refund, payroll, tax, escrow). Helps AP avoid paying a supplier from a payroll-only account.
Priority / default level
Whether this account is the primary one to use, a backup when limits are hit, or a country-specific default when several IBANs exist.
KYC status
Where the bank relationship stands in your onboarding process (not started, in progress, verified, expired). Expired counts often appear on dashboards as a renewal reminder.
Verification source
How you proved the account belongs to the partner (manual check, bank letter, micro-deposit, open banking, document OCR, etc.). Evidence type matters to auditors.
Verification date
The calendar date verification succeeded. Renew when policies require periodic re-verification.
Verified by
The employee who took responsibility for saying the account is good to use. Creates accountability if a fraud case appears later.
Risk level
Your company’s Low/Medium/High/Blocked label for payout risk on this IBAN. Separate from the partner’s overall credit risk-it is about this bank account record.
Fraud flags
Short notes from monitoring (name mismatch, recent IBAN change, etc.) so the next approver sees the context without opening a ticket system.
Change history link
URL or ticket ID pointing to the audit log of IBAN or signatory changes. Update it whenever the account number changes.
Allowed purpose codes
Which regulatory payment purposes may legally be sent to this IBAN (subset of your master purpose-code list). Prevents choosing a wrong purpose on the payment.
Beneficiary type
Whether the holder is an individual, company, government, or NGO-fields some banks and regulators require for screening and reporting.
Regulatory country profile
A reminder flag (standard, high-risk jurisdiction, special reporting) so staff attach the right extra forms-not a legal opinion by itself.
Tip: When an IBAN changes, update Change history link first, then lower Risk level only after a second approver signs off.
Common mistake: Marking KYC Verified without setting Verification source and Verification date – internal audit will ask for evidence.