How to turn a QuickBooks export into a bank payment file

For the payee details — Vendor Contact List. The standing list rather than this week’s run. On Desktop this is also the report that carries custom fields, if that’s where you keep banking details.

• QuickBooks Online: Reports → Standard reports, search for Vendor Contact List (grouped under Expenses and vendors).
• QuickBooks Desktop: Reports → List → Vendor Contact List.

For the payment run — Unpaid Bills. Who’s due and how much.

• QuickBooks Online: Reports → Standard reports, search for Unpaid Bills (grouped under What you owe).
• QuickBooks Desktop: Reports → Vendors & Payables → Unpaid Bills Detail.

To get either one out of QuickBooks Online, use the Export/Print dropdown on the report and choose Export to Excel. Desktop exports reports as Excel workbooks the same way.

Two things to do to the spreadsheet before you upload it:

Format the routing and account columns as Text before typing or pasting anything into them. Excel treats them as numbers by default and drops leading zeros without warning — and a transit number that has lost its leading zero is a valid-looking number pointing somewhere else.

Save a copy as CSV (Comma delimited). The generators take CSV, not .xlsx.

Either report gives you the fields QuickBooks treats as accounting. From Unpaid Bills that’s vendor, date, due date, bill number and open balance. From the Vendor Contact List it’s the vendor’s name and contact details.

You don’t get a routing number. You don’t get a bank account number.

That isn’t a report configured wrongly. It’s how QuickBooks holds the information, and it’s the same answer on QuickBooks Online and QuickBooks Desktop.

On QuickBooks Online, banking details entered against a vendor are encrypted the moment they’re saved. Intuit’s own support record puts it plainly: “Once the bank account is entered, our system automatically encrypts it. This means that only the last 4-digit of the account numbers are available.” Asked directly whether a list of vendors with full routing and account numbers can be produced, Intuit’s answer is that it cannot.

On QuickBooks Desktop the reason differs and the result is the same: the vendor record has no standard field for a routing or account number. Where those details exist in a QuickBooks company file at all, someone has put them into a custom field or a note.

This is a QuickBooks constraint, not a limitation of any particular payment tool. Every route out of QuickBooks meets it.

Verified against Intuit’s published support documentation, 29 August 2026.

There are three places to get them, depending on how many vendors you pay.

From the authorisations you already hold. If you collected a void cheque or a direct deposit authorisation when you set the vendor up, the numbers are already in your records. For a handful of vendors this is the fastest route, and it needs no changes in QuickBooks.

From a custom field you maintain in QuickBooks. QuickBooks Desktop lets you add custom fields to the vendor record, which then appear as columns on the Vendor Contact List and export with everything else. That keeps one system of record. It also means routing and account numbers sit in a field QuickBooks doesn’t encrypt, in a company file that gets backed up and shared the way your accounting data does — worth a deliberate decision rather than a default.

From a payee list you keep alongside your books. A spreadsheet holding vendor name, transit or routing number, and account number, joined to the QuickBooks export on the payee name. More moving parts, and the banking details stay out of the accounting file.

Whichever you pick, the details go in once and get reused. This is the mapping work, and it only happens properly once.

The name in your export is the QuickBooks display name — whatever was typed when the vendor was created. That’s often a trading name, an abbreviation, a person’s first name, or something with a note appended to keep two similar vendors apart. The name that belongs on the payment file is the one the receiving bank has on the account — often called the beneficiary name.

The account and transit numbers are what route the money. The name is how your payee recognises the deposit on their statement, and how you recognise it later in your own records. A display name that made sense inside your books might not match the beneficiary name on the account.

Two things also act on it before it reaches the bank: every format caps the name at a fixed width, so a long legal name gets shortened, and the formats accept a limited character set, so accents and punctuation are folded or dropped. You’re told when that happens to a name rather than it changing quietly.

So it’s worth doing once, alongside the banking details. Check each payee’s name against what their bank has, and keep the corrected version in the same place. After that it comes across with everything else.

Once the banking details are in the spreadsheet, every bank format needs the same five things per payment:

Everything beyond those five is set once per file rather than per row — the originator number your bank issued when you enrolled, the file or batch number, and the format’s own control fields.

Leaving an amount blank skips that row, so you can keep every vendor in the same spreadsheet and pay whoever’s due this run.

Everything above is the same wherever you bank. This is where it forks, and the fork is set by the receiving country rather than by where you are.

Paying US vendors

US banks take a NACHA file. One layout, used by effectively every US institution, so the question isn’t which format but which channel your bank wants it delivered through, and what they call your originator identification.

Paying Canadian vendors

Canada has no single equivalent. CPA-005 is the standard, but banks implement it differently and several run their own fixed-length layouts alongside it — 1464-byte and 80-byte variants that aren’t interchangeable. A 1464-byte file pasted into an 80-byte upload screen fails immediately.

PayFile Pro ships named profiles per bank and format rather than a general CPA-005 builder: RBC CPA-005 and Standard 152 · TD EFT 80-byte · BMO 1464 and EFT 80-byte · CIBC CPA-005, 1464 and EFT 80-byte · Scotiabank CPA-005 and ScotiaConnect EFT Import · ATB 1464 · credit unions on Central 1 PaymentStream AFT.

Which one you need is set by your bank and by the upload channel you were enrolled in, so it’s worth confirming before building anything.

Pick your bank and format, paste or upload your rows, and the payments are checked immediately — every field, against that bank’s actual layout. You’re told what’s wrong before anything else happens. No account, no email address, no trial to start.

If the payments are clean you get a preview showing the format, the payment count and the total. You only sign up and spend a credit when you want the file itself.

This checks the payment data you’re about to turn into a file. It isn’t a validator for a bank file you already have.