Screening, customer receipts, and hand-off flags

Updated 10 July 2026

Store sanctions and KYC outcomes on outbound wires, tune remittance emails, and describe inbound customer money clearly.

Overview

This chapter covers three optional areas: Payment compliance & KYCVendor & customer experienceCustomer payments, and Automation & integration. Together they close the loop between compliance, AR communication, and IT status.

How it works

Sanctions and KYC fields describe results already obtained from your screening tool or bank portal – Odoo stores the outcome for audit. Customer payment fields only matter for inbound receipts; automation flags help technical teams know whether a file was exported or reconciled with extra evidence.

Step-by-step guide

Fields table

Field explanations

Each item matches one row in the table above, in the same order.

Sanctions screening result

Cleared, Hit, or Pending review from your watch-list screening. Store the real outcome; do not guess, because auditors compare this to the screening provider’s log.

Sanctions screening reference

The ticket, batch, or case ID returned by the screening tool so anyone can trace the decision back to the vendor’s system.

Partner KYC/KYB status

Whether the counterparty’s know-your-customer file is up to date, expired, or still pending. Treasury may block wires when this says Expired.

Regulatory purpose code

The allowed reason code for cross-border payments (goods, services, payroll, etc.). Must match what your bank file format expects or the batch may reject.

Remittance advice template

Which email/PDF template Odoo should use when sending remittance details to the supplier so branding and tables stay consistent.

Communication channel

How remittance information should reach the counterparty (email, portal only, EDI, none). Align with what the beneficiary can actually receive.

Payment reference mode

Whether the payment reference must follow a structured format (e.g. SEPA) or can be free text, per the vendor’s bank instructions.

Customer payment source

The physical or logical channel the customer used (online, bank transfer, cash, check, POS, other). Helps AR explain inbound cash.

Customer collection channel

The commercial channel that produced the receipt (store, ecommerce, subscription, marketplace, partner). Helps marketing and finance without rebuilding data from web shops.

Collected by

The internal user who registered or physically collected the money (useful for cash, checks, or field sales).

Advance / prepayment

Tick when the customer paid before an invoice existed; helps downstream billing and revenue recognition discussions.

Customer reference

The payer’s own reference (portal payment ID, web order number, etc.) so automated matching to sales orders is easier.

Auto-retry profile

A short code naming your retry policy for failed digital collections (how many tries, spacing, escalation). Your IT or payments team defines what each code means.

Exported to Bank/PSP

Tick after the payment file or API call to the bank or PSP succeeded, so nobody double-sends the same instruction.

Reconciled with confirmation

Tick when reconciliation was done using an extra proof (signed PDF, email confirmation) beyond the normal bank feed match.

Pushed to external ERP

Tick when another system (SAP, NetSuite, etc.) has successfully received this payment record, for integration runbooks.

Image

Screening, customer receipts, and hand-off flags