Every electronic vendor payment, payroll deposit and pre-authorized debit that a Canadian business sends through its bank in a batch file follows the same rulebook: Payments Canada Standard 005, still widely called CPA 005. Most controllers never read it. They meet it indirectly, when a bank rejects a file with a one-line error message. This article explains what the standard covers, what it leaves to the banks, and what it means for the person responsible for accounts payable.
Who writes the standard, and why "CPA"
Payments Canada operates the national clearing and settlement systems. Until 2016 it was known as the Canadian Payments Association, hence "CPA" in the name that stuck. Standard 005 is the association's specification for the exchange of "Automated Funds Transfer" (AFT) transactions between financial institutions: the batch credits and debits that clear through the Automated Clearing Settlement System.
Only direct clearers (the large financial institutions) exchange files with each other under the standard. Your business is not a member of Payments Canada. You are an originator: you hand a file to your bank, and your bank is responsible for what it sends onward. That is why each bank publishes its own "EFT file specification" for customers. Those documents differ in wording and in a few optional fields, but the record layout they describe is Standard 005, with a record length of 1464 characters. This is why the file is called EFT 1464, CPA 005 or, at some banks, an AFT file.
What Standard 005 actually defines
The standard is a data-format specification. It covers:
- Logical record types and their order: A (header), C (credit detail), D (debit detail) and Z (trailer), plus records for returns and reversals that most originators never produce.
- Field positions, lengths and data types for every record. Each record is exactly 1464 characters; detail records are 24 characters of control data followed by up to six 240-character segments.
- Data conventions: amounts in cents with no decimal point, dates as
0YYDDD, numeric fields zero-filled on the left, alphanumeric fields space-filled on the right, uppercase text. - Transaction type codes: a 3-digit code in each segment stating the nature of the payment (payroll, supplier payment, and so on).
- Identification of the parties: the originator by a 10-character originator ID, the payee by institution number, transit number and account number.
- Control totals in the Z record, which allow the receiving system to prove that nothing was dropped or duplicated.
It does not define how you deliver the file (portal upload, secure file transfer), the cut-off times, the fees or the maximum file size. Those are set by your bank in its agreement with you.
The A record, field by field
The header is the simplest record and the one most often inspected by support staff when a file is rejected. Its meaningful content occupies the first 58 positions; the rest is filler.
| Positions | Length | Field | Notes |
|---|---|---|---|
| 1 | 1 | Record type | Always A |
| 2–10 | 9 | Record count | 000000001 for the header |
| 11–20 | 10 | Originator ID | Assigned by your bank; Zefty calls it the bank emitter ID |
| 21–24 | 4 | File creation number | Must be unique per file, for example 0001, 0002, ... |
| 25–30 | 6 | File creation date | 0YYDDD Julian format |
| 31–35 | 5 | Destination data centre | Provided by your bank |
| 36–55 | 20 | Reserved | Bank communication area, normally blank |
| 56–58 | 3 | Currency code | CAD |
| 59–1464 | 1406 | Filler | Spaces |
Inside a C record
A C record starts with the same 24 characters of control data as the header (record type C, record count, originator ID, file creation number), followed by up to six segments. A segment is one payment. Its fields, in order, are:
| Field | Length | What it contains |
|---|---|---|
| Transaction type | 3 | CPA transaction code for the payment |
| Amount | 10 | In cents, no decimal point |
| Due date | 6 | 0YYDDD |
| Institutional ID | 9 | 0 + 3-digit institution + 5-digit transit |
| Payee account number | 12 | Left-justified, space-filled |
| Item trace number | 22 | Zero-filled; assigned by the bank |
| Stored transaction type | 3 | Normally zeros |
| Originator's short name | 15 | Your business name, abbreviated |
| Payee name | 30 | The vendor's name |
| Originator's long name | 30 | Your business name as registered with the bank |
| Originating direct clearer's user ID | 10 | Your originator ID again |
| Originator's cross-reference number | 19 | Free text: an invoice or bill number |
| Return institutional ID | 9 | Where returns should go |
| Return account number | 12 | Your account, for returns |
| Originator's sundry information | 15 | Optional |
| Filler | 22 | Spaces |
| Settlement code | 2 | Spaces |
| Invalid data element ID | 11 | Zeros; filled by the bank on return |
Those lengths add up to 240. Six segments are 1440 characters; with the 24-character prefix the record reaches 1464. If a file contains 14 payments, it has three C records: two full ones and one with two segments and four blank segments.
The Z record: the bank's checksum
The trailer repeats the control prefix, then reports the total value and the number of debit transactions (14 and 8 digits) and the total value and number of credit transactions (14 and 8 digits). For a vendor payment file the debit totals are zeros. The bank sums the segments it received and compares. A mismatch is a hard rejection, because it means the file was altered or truncated in transit.
How banks validate a CPA 005 file
Validation usually happens in three layers, and the error messages you receive tell you which layer failed.
- Structural checks. Is every record 1464 characters? Does the file start with A and end with Z? Is the record count sequential?
- Content checks. Is the originator ID known and active? Is the file creation number new? Are the dates within the bank's allowed window? Do the institution and transit numbers exist in the Financial Institutions File? Are amounts numeric?
- Business checks. Does the Z record match the detail? Is the total within your authorized limit? Is the account to be debited the one on your agreement?
A file that passes all three is accepted for processing, typically for settlement on the due date in each segment.
What compliance means for accounts payable
For a controller, "CPA 005 compliance" is not a certificate you obtain. It is a property of each file you send. Three habits keep you compliant:
- Never edit a generated file by hand. Fixing a name in a text editor is the fastest way to break a fixed-width record.
- Keep the file creation number under control. One counter per originator ID, incremented on every file, including test files.
- Keep an audit trail. For each file, retain the file itself, the list of bills it paid, the date it was uploaded and who approved it. Zefty stores every export with its file number and produces a PDF report that lists every field of every A, C and Z record, so the audit trail is built at the moment the file is generated.
CPA 005 and Zefty
Zefty generates EFT 1464 files from bills in Zoho Books, with the record layout above. The originator ID, institution, transit and account you enter during bank setup populate the A and C records; each vendor's institution, transit and account, synced from Zoho Books, populate the payee fields; the file creation number is tracked automatically as the "last file number" in your EFT 1464 file settings. Test mode produces a file marked as a test so you can validate the format with your bank before paying anyone.
Key takeaways
- CPA 005 is Payments Canada Standard 005, the specification for batch EFT files exchanged through the Automated Clearing Settlement System.
- Banks publish their own EFT specifications, but they all implement the same 1464-character record layout: A header, C or D detail, Z trailer.
- A C record carries up to six 240-character payment segments, each identifying the payee by institution, transit and account number.
- The Z record's totals act as a checksum; the file creation number in the A record must be unique.
- Compliance is a property of each file. Automating generation and keeping a per-file audit trail is the practical way to stay compliant.
Want the same information in reference form? See our compliance page for the record table and validation rules, or read How it works to see how Zefty builds a compliant file from your Zoho Books bills.