EFT in Canada:
What It Is and How to Configure It in Odoo

What Is EFT? Electronic Funds Transfer, Explained

An EFT (Electronic Funds Transfer) is any movement of money between bank accounts that happens electronically, without paper cheques, cash, or physical exchange. In Canadian banking the term covers two related but distinct flows: outbound EFT (your business pays vendors, employees, or refunds customers by depositing funds directly into their accounts), and inbound EFT or Pre-Authorized Debit (PAD) (you pull funds from a customer's account on a recurring schedule, with their written authorization).

The plain-English EFT meaning is therefore: a bank-to-bank transfer initiated electronically, settled through a clearing network rather than a courier-delivered cheque. In Canada that clearing network is operated by Payments Canada (formerly the Canadian Payments Association) and runs on a file format called CPA Standard 005. Every Canadian bank, RBC, TD, BMO, Scotiabank, CIBC, National Bank, Desjardins, plus the credit unions, accepts a CPA 005 file as the canonical instruction to move money. We will return to CPA 005 in detail below because it is the format your Odoo deployment will ultimately emit.

EFT is not the same as Interac e-Transfer. Interac is a real-time peer-to-peer rail using an email or phone number as the recipient address; it is faster but capped (typically $25,000 per transaction at most banks). EFT is batch-based, typically settles in 1–3 business days, and has no practical cap, businesses move hundreds of thousands of dollars in a single nightly batch. For high-volume AR/AP automation, EFT is the workhorse.

This guide is written by Octura Solutions, an Official Odoo Ready Partner with 100+ implementations across the US, Canada, and France. We have configured Canadian EFT for businesses ranging from 20-employee SMBs to 800-user mid-market manufacturers. The patterns below come from those deployments, not from product documentation.

What Odoo Provides Out of the Box for EFT

Odoo's Accounting module ships with a generic payment-batch framework, plus a Canadian localization (l10n_ca) that adds Canadian-specific tax, chart of accounts, and CPA 005 file generation. The combination gives you:

• Batch payment groups. Select 50 vendor invoices, click "Pay", and Odoo aggregates them into a single batch with one settlement date, one originator account, and a generated CPA 005 file ready to upload to your bank portal.
• Vendor bank-account validation. Each vendor record stores institution number (3 digits), transit (5 digits), and account number (typically 7–12 digits). Odoo validates the institution against a static list of Canadian banks at save time, catching the most common data-entry mistake (transposed digits in the institution code).
• Per-bank journal mapping. Each Canadian bank account is its own journal in Odoo. The bank account record holds the CPA originator ID assigned by the bank and the bank's specific file-format flavour (RBC, TD, BMO, Scotia, and CIBC have minor variations on the standard).
• Customer pre-authorized debit (PAD). The same engine generates inbound CPA 005 files where your business is the debitor. Customer authorization forms are stored against the partner record with the SHA-256 hash for audit.
• Reconciliation against the bank's return file. When the bank returns the camt.054 (or proprietary return format), Odoo matches each settled payment back to the originating invoice and auto-closes the AP/AR entry.

Out of the box, the Canadian localization covers the 80% case: standard CPA 005 file, the big-five banks, vendor and customer payments. The 20% that needs configuration, variable settlement dates, multi-currency payments, USD wire mixed into the same batch, large-volume SFTP automation, we describe in the sections below.

The CPA 005 File Format (and Why Bank Quirks Matter)

CPA Standard 005 is a fixed-width text format. Every record is exactly 1,464 characters. The file contains a header (A record), a list of credit or debit records (C records), and a trailer (Z record). The header carries your originator ID (assigned by the bank when you sign the EFT agreement), the originating account, and the file creation number, a sequence that must increment by 1 on every file you submit, otherwise the bank rejects the upload with a duplicate-file error.

Each Canadian bank wraps the standard slightly. Differences that cost real time on a first deployment:

• RBC, accepts the cleanest pure CPA 005 and tolerates older institution codes. Originator ID is a 10-character alphanumeric string.
• TD, requires a TD-specific control number in the header (assigned per submission) on top of the standard file-creation number. Odoo's l10n_ca handles this when the journal is flagged as TD.
• BMO, strict on the C-record cross-reference number. Limit it to 14 characters or BMO rejects the file. Odoo defaults to 19, so the journal must be configured to truncate.
• Scotiabank, accepts the standard format but enforces additional payor name validation. The originator name in the header must match the legal name on the bank account exactly, including punctuation.
• CIBC, accepts CPA 005 via Cash Management Online with no proprietary extensions, but requires the file-creation number sequence to be at least 4 digits zero-padded.

Octura keeps an internal cheat-sheet of these per-bank quirks; we apply the right flavour when we configure the Odoo journal. If you self-implement and your bank rejects the first file, 9 times out of 10 the issue is one of the five quirks above.

Outbound EFT: Paying Vendors and Employees via Odoo

The most common Odoo EFT use case is automating accounts payable. The workflow:

• 1. Vendor onboarding. When a new vendor is created, capture their CPA-005 banking details on the partner record. Validate the institution and transit; warn if the institution is unknown.
• 2. Invoice approval. Standard three-way match against the PO and receipt. Approved bills land in the AP aging.
• 3. Payment batch selection. Weekly (or whatever your cadence is), open the "Vendor Bills to Pay" view, filter by due date, multi-select, and click "Create Payment Batch". Odoo groups the selected bills by vendor (so one vendor gets one payment even if they have five open invoices) and generates a draft EFT batch.
• 4. Approval workflow. The batch enters an approval state. Per the Payments Canada rules, businesses are expected to have two-person sign-off on outbound EFT batches above a threshold. Odoo's standard approval workflow covers this, the AP clerk creates the batch, the controller approves it.
• 5. File generation. Once approved, Odoo generates the CPA 005 file and offers it for download. The file is saved against the batch record for audit. The file creation number auto-increments on each generation.
• 6. Bank upload. Upload the file to your bank portal (RBC Express, TD Web Business Banking, etc.). Note the bank's confirmation reference back into Odoo against the batch.
• 7. Reconciliation. The next business day, the bank's return file lands in Odoo (manual upload or SFTP poll). Successful settlements close the corresponding AP entries. Returns flag the batch for review.

The same flow runs for payroll. If you use Odoo's Canadian payroll module, employee net-pay amounts feed an EFT batch alongside vendor payments, or in a separate batch if your bank requires payroll to come from a dedicated payroll account (TD and BMO sometimes require this for direct deposit). For complex payroll setups we usually recommend keeping payroll EFT in its own batch with its own approver, to keep audit trails clean.

Inbound EFT: Pre-Authorized Debit (PAD) for Customers

The reverse of vendor payment is pulling funds from a customer's account. In Canada this is called Pre-Authorized Debit (PAD) and is governed by Payments Canada Rule H1. It is the standard way subscription businesses, utility companies, and B2B suppliers on net-30 terms collect from customers without waiting for a cheque.

The mechanics:

• Customer authorization. Before the first debit, the customer signs a PAD agreement listing the amount (or amount range for variable bills), frequency, and the bank account to be debited. The agreement must be stored for the life of the relationship plus seven years. Odoo's PAD module stores the signed PDF against the partner record with an audit hash.
• Recurring schedule. Invoice templates flagged as "Collect via PAD" auto-generate debit records on the due date. Odoo bundles all PAD debits scheduled for the same settlement date into a single inbound CPA 005 file.
• Pre-notification. Canadian rules require pre-notifying the customer 10 days before each debit unless the agreement waives this requirement (most B2B agreements do). Odoo's default is to email a pre-notification 10 business days before the debit date.
• File submission. Same upload process as outbound, generate the file, two-person approve, upload to the bank portal.
• Returns. NSF (non-sufficient funds), account closed, and stop-payment returns come back in the bank's return file. Odoo reopens the corresponding customer invoice and triggers your dunning workflow.

For SaaS and subscription businesses, PAD on Canadian customers is significantly cheaper than credit-card processing (no 2.5–3% fee, just the bank's flat $0.50–$1.50 per transaction) and has dramatically lower involuntary churn (no expiring cards). The trade-off is the 10-day pre-notification and the 90-day customer dispute window (vs. 60 days for credit cards). For most B2B and high-LTV B2C subscriptions, PAD beats card processing on margin.

Reconciling EFT Transactions in Odoo

The hardest part of EFT integration is not file generation. It is reconciliation. The bank's daily statement shows aggregate debits and credits with reference numbers that don't always match Odoo's batch IDs. Three patterns to get right:

• Use the bank's return file, not the daily statement. The return file (camt.054 or proprietary) lists per-payment settlement status with the original cross-reference number. Odoo's auto-reconciliation engine matches against that cross-reference. Reconciling from the daily statement requires manual matching and is the #1 source of month-end reconciliation pain.
• Match the originator account journal entry once per batch. The bank debits your account in one aggregate amount per batch (not per recipient). Odoo creates one journal entry on the originator side and one journal entry per recipient on the AP side; the bank statement line will only match the aggregate. Make sure your bank-statement import rule recognises this, usually by matching the batch reference number that appears in the statement memo.
• Handle returns within the same period. A return that arrives 3 days after the original debit must reopen the AP entry in the same accounting period if possible, otherwise it lands in the wrong month. Odoo's default behaviour is to record the return on the date the return file is imported; configure it instead to record the return on the original settlement date to keep period-end clean.

Once those three rules are in place, EFT reconciliation runs ~95% automatic, the AP clerk only investigates the 5% of items that returned for non-trivial reasons (wrong vendor account, business name change at the receiving end). For a 200-line monthly EFT volume, the AP clerk typically spends 20 minutes on month-end EFT reconciliation rather than the 4–6 hours that manual matching takes.

Common Pitfalls (and How to Avoid Them)

• Duplicate file-creation numbers. The most common rejection. If you generate a file in Odoo, decide not to upload it, then generate another file, the sequence has already incremented, but if your operator manually rolls it back, the next submission collides. Lock the sequence; never edit it manually.
• Vendor account changes mid-batch. A vendor updates their banking info while a batch is sitting in approval. Odoo's default re-reads vendor banking at file-generation time. Configure it to snapshot banking on batch creation instead, and require re-approval if banking changes mid-flight.
• Same-day cutoff missed. Each bank has a daily cutoff (4–5 pm ET). Files uploaded after cutoff settle one day late. Build that cutoff into your AP cadence, process batches by 3 pm at the latest.
• USD payments in a CAD CPA 005 file. CPA 005 is CAD-only. USD payments to Canadian or US vendors go through SWIFT wire, not EFT. Mixing them in the same batch will reject the file. Odoo's payment screen lets you filter by currency before batching, use it.
• Holiday settlement. CPA 005 settles on Canadian banking business days. A batch submitted on the Friday of a long weekend won't settle until Tuesday. Plan vendor due dates around it.

Frequently Asked Questions