You upload the payment file, wait a few minutes, and the bank portal answers with a rejection. Vendors do not get paid, the payment run is now late, and the error message rarely explains what went wrong. If a bank rejects an EFT file, the cause is almost always one of a short list of formatting or setup problems. This guide walks through the eight causes we see most often with CPA 005 files, what each one looks like from the bank's side, and how to prevent it.
First, understand what the bank checks
A Canadian EFT 1464 file is a plain text file made of fixed-width records of exactly 1,464 characters. It starts with an A record (the header), continues with one or more C records (credit details: who gets paid, how much, to which account) and ends with a Z record (the trailer, with totals).
When you upload it, the bank runs three families of checks:
- Identity checks. Is this file coming from an originator we know, with EFT origination enabled?
- Structure checks. Is every record the right length? Are the fields where they should be? Are dates and amounts formatted correctly?
- Consistency checks. Do the totals in the trailer match the details? Has this file number been used before?
Most rejections fall out of one of those three. Here they are in the order we encounter them.
The eight most common rejection causes
| Cause | What the bank sees | Fix |
|---|---|---|
| Wrong originator ID | Header carries an ID that is not on file | Copy the 10-character ID from the bank's EFT agreement, no spaces or dashes |
| EFT origination not active | Valid customer, no permission to originate | Ask your business banking representative to activate EFT origination on the account |
| Wrong transit or institution length | Transit is not 5 digits or institution is not 3 digits | Correct the vendor's banking details at the source, not in the file |
| Invalid characters in payee names | Accents, ampersands or symbols in a name field | Strip or replace anything outside A–Z, 0–9 and a few punctuation marks |
| Duplicate file creation number | Same file number as a previous submission | Increment the file number for every file, including tests |
| Dates in the past | Payment date earlier than the file creation date | Pick a payment date on or after the day you upload |
| Amount mismatches | Trailer total does not equal the sum of the C records | Recompute totals after every edit; never hand-edit a generated file |
| Wrong file name or extension | Portal refuses the upload or misroutes it | Follow the bank's exact naming convention, usually a .TXT extension |
The rest of the article takes each of these in turn.
1. Wrong originator ID
Every EFT file identifies the sender in the A record with a 10-character originator ID. Banks call it different names: originator ID, company number, customer number, emitter ID. If the value in the header does not match the ID the bank assigned to your account, the file is rejected before anything else is read.
Typical mistakes: a leading zero dropped, a space or dash left in, or the ID from a different bank account of the same company. Copy it exactly as it appears in your EFT service agreement.
2. EFT origination is not active on the account
This one surprises people. You can have a business account, a valid originator ID and a perfect file, and still be rejected because the bank has not switched on EFT origination for that account. Activation is a service request, sometimes with a signed agreement and a short setup delay. Confirm with your representative that the service is active before you submit your first file.
3. Transit or institution numbers with the wrong length
A Canadian transit number has 5 digits. An institution number has 3 digits (for example 003 for RBC, 004 for TD, 815 for Desjardins). A common error is a vendor record where the institution was typed as 3 instead of 003, or a transit number that has 4 digits because someone dropped a leading zero. In a fixed-width file, a missing digit shifts every character after it, so the whole C record becomes unreadable.
Fix the data at the source. If you store vendor banking details in Zoho Books, correct them there so every future file is right.
4. Accents and special characters in payee names
CPA 005 files use a restricted character set. A vendor named « Bélanger & Fils » will cause problems in many bank implementations: the accented é and the ampersand are either rejected outright or replaced with a character the bank does not accept. Some banks reject the entire file; others reject only the affected record, which leaves you with a partial payment run to reconcile.
Zefty handles this automatically. When it builds each C record, it strips characters outside A–Z, 0–9 and the hyphen from the payee name, so accents and symbols never reach the file.
5. Duplicate file creation number
The A record carries a file creation number. Banks use it to detect a file being submitted twice, which is a real protection against paying everyone double. The flip side is that if you reuse a number, even by accident, the file is treated as a duplicate and rejected.
The fix is to never manage this number by hand. Zefty stores the last file number in the EFT 1464 File Settings and increments it for every file it generates. The next number is shown on the Dashboard so you always know where you stand.
6. Payment dates in the past
Each credit record includes a payment (due) date. If that date is earlier than the file creation date, most banks reject it. This happens when a file is generated on Friday and uploaded the following Tuesday, or when someone manually edits a template from last month.
Generate the file when you are ready to upload it, and choose the payment date deliberately. In Zefty, Generate Payment File asks for a Payment Date, defaulting to today, before it writes anything.
7. Trailer totals that do not match
The Z record states the number of credit records and their total value. The bank recomputes both from the C records and compares. If a file was hand-edited after generation, if a line was deleted, or if an amount was retyped, the totals no longer match and the file is refused.
Never edit a generated file in a text editor. If a bill needs to change, change it before generation and produce a new file.
8. Wrong file name or extension
Each bank expects a particular naming pattern. Some want a .TXT extension, some derive the name from your originator ID, and some reject anything that does not match. This is not a content error, so the message from the portal is often vague ("invalid file").
Zefty names the file for the bank you selected during setup, so the name matches what that bank's portal expects.
Preventing rejections before they happen
A few habits eliminate nearly all of the above:
- Keep vendor banking data clean at the source. Zefty flags any bill whose vendor is missing banking details in red and blocks it from export until it is fixed.
- Use test mode for your first file. A test file is marked as a test, is never posted back to Zoho Books, and lets your bank confirm the format before real money moves.
- Review the PDF report. Every export in Zefty comes with a field-by-field audit of the A, C and Z records, so you can check the originator ID, dates and totals in plain language before uploading.
- Do not touch the file after generation. If something is wrong, fix it in Zoho Books or in Zefty and generate again.
Key takeaways
- Bank rejections come from a short list of causes: identity, structure and consistency.
- Originator ID and EFT origination status are the first things to verify with your bank.
- Transit numbers are 5 digits, institution numbers are 3 digits. Leading zeros matter.
- Accents and symbols in payee names must be removed before the file is built.
- File numbers must never repeat; payment dates must not be in the past.
- Never edit a generated file by hand.
If you are still seeing rejections after checking this list, our Canadian support team can help you read the bank's error and trace it back to a field. Visit the support page or write to [email protected] with the bank's message and your file number.