How to Convert NAB Bank Statements to Excel or CSV

NAB does not hand you a single export format. Personal NAB Internet Banking exports transaction history as spreadsheet (Excel), QIF, or PDF — not CSV. Business Internet Banking adds a CSV transaction report alongside the PDF business statement. NAB Connect delivers electronic account statements as an Account Information File in NAI or BAI2 format, with CSV, PDF, and QIF available as well. Which format you can actually download depends entirely on which NAB product the account sits on, and a lot of the generic bank-statement-converter advice online skips over that.

To convert NAB bank statement to Excel or into a CSV that imports into Xero, MYOB, or QuickBooks Online, each transaction field needs its own column: date, payee, raw narrative, BPAY or PayID reference, amount, and running balance. That shape is what BAS reconciliation and accounting-software imports expect; a PDF rendered as one long text blob is not.

This article walks the NAB-specific workflow as a decision, not a converter pitch. Which NAB product your client is on, what that product actually exports natively (including the two corrections the SERP keeps getting wrong), when the PDF statement is still the document that matters even if a CSV is available, what the transaction narrative actually contains on a NAB line, and how the extracted data lands in Xero, MYOB, or QuickBooks Online AU. It also covers when the NAB to Xero direct feed beats extraction and when extraction earns its place for historical backfill, audit working papers, and non-Xero accounting systems.

Two corrections up front, because they change the workflow. The flat claim that "NAB doesn't export CSV" is only true for personal Internet Banking; Business Internet Banking and NAB Connect both do. And NAB Connect's native electronic statement format is the Account Information File in NAI or BAI2, not MT940 — there is no native MT940 export, and customers who need MT940 convert downstream.

Which NAB product your client is on

Before you decide how to get data out, identify which NAB banking product issued the statement. NAB operates several distinct platforms, and the export options, the statement-archive window, and the workflow all branch from that answer.

NAB Internet Banking (personal tier). The retail online-banking product used by individuals and sole traders. The transaction-history screen exports to spreadsheet (Excel), QIF, or PDF. There is no CSV export on the personal tier — this is where the "NAB doesn't export CSV" line has a narrow kernel of truth. If the client is operating as an individual or under a sole-trader ABN on a personal account, this is almost certainly the tier.

NAB Internet Banking (business tier). The everyday business online-banking product for AU SMBs — companies, trusts, partnerships, and sole traders running on a business account. Adds a CSV transaction report alongside the PDF business statements. Most SMB bookkeeping clients sit here, and the distinction from the personal tier is the single most common point of confusion when a bookkeeper expects CSV and finds they can't get one.

NAB Connect. The corporate-tier platform, pitched at larger SMBs, mid-market, and corporate customers. On top of CSV, PDF, and QIF, NAB Connect delivers electronic account statements as an Account Information File in NAI or BAI2 format. If the client has a dedicated NAB relationship manager, a treasury function, or runs payroll and payments through a portal branded "NAB Connect", this is the tier.

NAB Direct Link. The host-to-host and file-transfer layer that delivers NAI/BAI2 directly to a customer's treasury system or ERP without anyone logging into a portal. Used by corporates with automated bank-statement ingestion, and rarely what an SMB bookkeeper is dealing with — but worth knowing about because it surfaces on search queries and file-format questions.

NAB Business One. A legacy SME product name that still shows up in search queries and on older statements. Most Business One customers have been migrated into Business Internet Banking, but the name lingers and a client may refer to their setup by it.

Most AU SMB bookkeeping clients are on NAB Internet Banking's business tier. NAB Connect is the cutover point where richer electronic-statement formats become available, and collapsing the two into "NAB online banking" is the mistake that makes generic converter advice miss on half the workflow.

NAB is one of Australia's big four (ANZ, Commonwealth Bank, NAB, Westpac), and the NAB-specific extraction walk here has direct siblings for the other big-four banks — the ANZ bank statement to Excel workflow covers the same decision for ANZ customers, and the equivalent walk-through for converting Commonwealth Bank statements to Excel handles CBA. If your client portfolio spans more than one big-four bank, the shape of each article is parallel; the export specifics and product-line decisions differ per bank.

What NAB actually exports natively, by product

Once you know the product, the native-export options follow cleanly. Here is the comparison stitched together from NAB's own help-centre pages across the four product lines:

NAB product	Native export formats
NAB Internet Banking (personal)	Spreadsheet (Excel), QIF, PDF
NAB Internet Banking (business)	CSV transaction report, PDF business statements, QIF
NAB Connect	CSV, PDF, QIF, NAI/BAI2 Account Information File
NAB Direct Link	NAI/BAI2 delivered to host/file-transfer endpoints

Two things to pull out of that table, because they contradict what a lot of converter-vendor pages assert:

Personal Internet Banking exports spreadsheet and QIF, not CSV. The spreadsheet export produces an .xlsx file, which is not interchangeable with a CSV for every downstream workflow — Xero's bank-statement import wizard, for example, expects CSV or OFX, not XLSX. If the client is on the personal tier and needs CSV, the options are to open the spreadsheet export and save it as CSV from Excel, or to extract from the PDF. There is no one-click CSV button on the personal product.

Business Internet Banking and NAB Connect do export CSV. The flat claim that "NAB doesn't export CSV" is a converter-vendor talking point, not a fact — it is true only for personal Internet Banking. On a Business Internet Banking account, the CSV transaction report is the first thing to try for a quick NAB Internet Banking transaction export into a spreadsheet. It will cover ongoing transactional work well; it falls short for workflows that need the full statement artefact rather than a transaction list.

NAB Connect's Account Information File is NAI or BAI2, not MT940. NAB Connect's published file-format guides list the Account Information File NAI/BAI2 as the supported format for electronic account statement delivery. There is no native MT940 export. Customers who need MT940 — typically multinational treasury teams running SWIFT-based cash-management tools — convert BAI2 downstream, run BAI2 through an ERP's format-translation layer, or ask NAB directly about alternatives. If you are searching for an NAB Connect BAI2 file and expecting it to arrive as MT940, that expectation is off by one format.

For orientation: NAI and BAI2 are banking-industry electronic-statement formats designed for machine import into treasury systems, ERPs, and reconciliation tools — structured, fixed-field, line-oriented files the bank delivers daily. They are not human-readable in the way a PDF or CSV is, and they are not the format a bookkeeper opens directly; they are the format a cash-management system ingests. For SMB bookkeeping inside Xero, MYOB, or QuickBooks Online, the CSV (from Business Internet Banking or NAB Connect) or the PDF (extracted into CSV) is the working format.

When the PDF statement is still the canonical document

If Business Internet Banking and NAB Connect export CSV, a reasonable question is: why bother with the PDF at all? Download the CSV, open it in Excel, done.

The answer is that the CSV transaction export and the PDF statement are different documents doing different jobs. The CSV is a list of transactions within whatever date range you specified at export time. It does not carry opening balance, closing balance, statement-period boundaries, page numbers, branch reference, or the statement-issue metadata that makes a document recognisable as a bank statement in the first place. It is a transaction list, not a statement.

That distinction matters in several downstream workflows:

• BAS preparation working papers. The PDF statement evidences opening and closing balances and gives the reconciliation tie-out its anchor. An auditor or BAS reviewer opens the working papers expecting to see the bank-issued statement as the source document, not a re-keyed transaction list.
• External audit working papers. CA ANZ and CPA Australia practice expectations treat the bank-issued statement as the source document for bank-balance assertions. A CSV transaction export that the bookkeeper generated themselves, from a transaction-search screen, does not carry the same evidentiary weight as the PDF statement NAB issued on the statement-cycle date.
• Finance and serviceability packs. Lenders and mortgage brokers ask for bank statements as the document underwriters assess for serviceability — they expect the PDF with the bank's branding, statement period, and issue date. A CSV attached to a serviceability application does not meet the underwriter's request.
• Insolvency and forensic-accounting reconstruction. When a forensic accountant is rebuilding a transaction history from fragmentary records, the PDF's statement metadata — period boundaries, running balances, page numbers — is what anchors each transaction to a specific statement and allows cross-checking across periods.

ATO record-keeping rules require supporting documents for BAS and income tax to be retained for five years, and bank statements are a core class of supporting document — the PDF statement, not an ad-hoc CSV pulled from a transaction screen, is what fits that retention requirement.

CSV is a parallel export for different jobs; it is not a substitute for the statement. When the workflow demands the PDF — for BAS working papers, audit, lender packs, or retained evidence — extraction is the bridge between the canonical PDF and the structured data the accounting system, auditor, or lender actually needs.

What lives in an NAB transaction narrative

A NAB transaction line is rarely a single tidy string. It is a bundle of sub-fields that the payment rail delivered, rendered into the statement's narrative space. Knowing which sub-field is which, and which one matters for which job, is the difference between clean BAS coding and half an hour hunting through transaction text for a BPAY biller code.

The sub-fields a NAB transaction can carry:

• Payee or counterparty. The name of the other party — usually the merchant's registered trading name for card and direct-debit transactions, and the registered name of the account holder for account-to-account transfers. This is what the bookkeeper matches to a supplier in the ledger.
• Raw narrative. The free-text description field where NAB drops whatever the payment rail delivered. This is the field generic extractors tend to jumble: reference numbers, biller codes, merchant location, and merchant category descriptors can all land here as one run-on string if no one tells the extractor to split them.
• BPAY biller code and CRN. A BPAY payment identifies two things: the biller (a unique five- or six-digit biller code assigned by BPAY) and the specific bill (the customer reference number, or CRN). BAS coding often hangs off the biller code because it maps one-to-one to a supplier — the CRN distinguishes one invoice from another for the same biller. If both land in a single narrative blob, the supplier lookup has to be done manually per line.
• PayID identifier and PayID name. PayID routes a payment to a payment-address label (a phone number, email address, or ABN) rather than a BSB and account number. The PayID name is the registered name behind that label — the account holder's name as it was registered with the payment address. When the raw narrative is terse or unhelpful, the PayID name is often the only thing that answers "who is this payment to" without opening the underlying invoice.
• Osko reference. Osko is the real-time retail-payments rail. An Osko payment can carry a short reference message alongside it, and suppliers routinely use that field to quote an invoice number. If the Osko reference is preserved as its own column, matching payments to invoices is almost automatic; if it is collapsed into the narrative, it becomes an ad-hoc text search.
• Internal NAB transaction code. NAB also assigns an internal transaction code that classifies the line type — fee, interest, transfer, card, direct debit. It is useful for bulk filtering during reconciliation (pull out all interest entries at once, separate fees from genuine transactions, and so on) when you preserve it as a column rather than treat it as decoration.

The failure mode generic extractors produce, when they are not told otherwise, is collapsing all of that into one column. The payee merges with the BPAY biller code, the CRN merges with the Osko reference, the PayID name gets truncated against a character limit the extractor imposed, and the NAB transaction code disappears into the narrative. A clean extraction for a NAB statement keeps each of those sub-fields in its own column, named for what it is, so the bookkeeper coding BAS or reconciling a supplier ledger can pivot, filter, and match against the right field directly.

Extracting a NAB PDF into a structured spreadsheet

The target shape for the extraction output, based on what the previous two sections established, is a spreadsheet where the transaction rows carry every sub-field in its own column: date, amount, running balance, payee, raw narrative, BPAY biller code, BPAY CRN, PayID name, Osko reference, and NAB transaction code. Alongside the transaction rows, the statement-level metadata — account number, BSB, statement period, opening balance, closing balance — is preserved, either as header rows or as repeated columns on each transaction row, depending on how the downstream consumer wants it.

What separates an extraction that produces that shape from one that produces a single jumbled narrative column is instruction. A generic PDF-to-table tool guesses at column boundaries from the PDF's visual layout and produces whatever falls out — usually one column for date, one for amount, one for running balance, and a single fat column for everything that was visually inside NAB's narrative space on the statement. That output needs a second pass in Excel to split the narrative into its sub-fields, and for BAS coding across several statements per month across several clients that second pass is where the hours go.

The alternative is an extraction tool you can instruct: tell the tool that BPAY biller code, BPAY CRN, PayID name, and Osko reference should each be their own column; tell it which transactions are fees, interest, or transfers based on the NAB transaction code; tell it what to do with opening and closing balances. When you are weighing AI-powered bank statement extraction against a tool that works on fixed templates or a generic OCR wrapper, the presence of an instruction layer is the deciding factor for NAB statements specifically, because the narrative anatomy is bank-specific and the column split needs to reflect it.

That is the shape of the workflow our tool covers. The extraction interface is a single prompt field with a file upload area — the same interaction pattern as ChatGPT or Claude — where you upload the NAB statement PDF and describe the columns you want. For a NAB transaction-account statement, a prompt along the lines of "Extract each transaction as one row. Columns: Date, Amount (signed; debits negative), Running Balance, Payee, Raw Narrative, BPAY Biller Code, BPAY CRN, PayID Name, Osko Reference, NAB Transaction Code. Include the account number, BSB, statement period, opening balance, and closing balance as repeated columns on each row" produces the shape above, delivered as Excel (.xlsx), CSV (.csv), or JSON (.json). The same prompt can be saved to a prompt library and re-run across every NAB statement in the bookkeeper's monthly cycle, which is how the workflow becomes repeatable.

The extraction applies to any NAB PDF statement you put in — a recent business-account statement downloaded from NAB Internet Banking this morning, a historical PDF archived three years ago, or a Visa Business Card statement from the card account. The PDF is the input shape; the column prompt is what teaches the extraction what a NAB statement looks like.

Importing the extracted data into Xero, MYOB, and QuickBooks Online AU

Each of the three major AU accounting platforms accepts bank-transaction data in a slightly different shape, and the extraction output from the previous section maps onto each one cleanly when the columns are named for what they carry.

Xero. Accepts CSV with a column-mapping step at import time, and OFX as a direct-import format without the mapping step. For CSV, the headers the import wizard looks for are Date, Amount, Payee, Description, and Reference. Debits and credits can sit together in one signed Amount column (negatives for debits) or as separate Debit and Credit columns — Xero handles either. For NAB statements the cleanest approach is usually a signed Amount column, with Payee mapped from the extracted payee field, Description from the raw narrative, and Reference from whichever of the BPAY CRN, PayID name, or Osko reference is the most useful match-point for the supplier.

MYOB. Accepts QIF, OFX, or CSV, with the specifics depending on the product tier — MYOB AccountRight, MYOB Business, and MYOB Essentials each have slightly different import paths. CSV import is the common path for bookkeepers working from extracted NAB data, and the column expectations and the bank-feed-vs-import mechanics are covered in depth in importing bank statements into MYOB; follow that walk-through for MYOB-specific detail.

QuickBooks Online AU. Accepts QBO (Intuit's own bank-statement format), OFX, or CSV. CSV import with a column-mapping step is the everyday choice when starting from an extracted spreadsheet. Date, Description, Amount, and balance-column handling are the fields to produce; QuickBooks Online's CSV mapper is forgiving on column order but strict on date format, so setting the extraction to output dates as DD/MM/YYYY (AU convention) avoids the most common import failure.

The through-line is that the extraction output from the previous section — date, amount, running balance, payee, narrative, reference sub-fields as distinct columns — maps onto what each import wizard asks for. You pick the column from the extracted spreadsheet that corresponds to the platform's expected field, save the mapping, and the next statement in the monthly cycle imports with the same mapping. For most SMB bookkeeping inside Xero, MYOB, or QuickBooks Online AU, the reason you are doing any of this is BAS preparation; the downstream BAS workflow from there is covered in preparing BAS in Xero, which picks up once the bank transactions are sitting in the accounting file.

The NAB to Xero direct feed versus PDF extraction

For bookkeepers already using Xero, there is an obvious prior question: why extract at all when NAB has a direct bank feed into Xero?

NAB offers a direct feed into Xero for most business customers, delivered through Australia's Consumer Data Right (CDR) infrastructure. Once the feed is connected, transactions flow daily from the NAB account into Xero's bank account screen, ready to reconcile against invoices and bills. For the specific job of ongoing reconciliation — coding last week's card transactions, matching supplier payments against bills, reconciling yesterday's receipts — the feed is simpler than extraction, and it is the right answer. There is no case for extracting a PDF statement weekly when the feed already has the data in the ledger.

Extraction earns its place where the feed does not cover the job, and there are five shapes of problem where that applies:

• Historical periods that pre-date the feed connection. CDR feeds typically start delivering transactions from the date the feed was authorised, not retrospectively. If the connection went live in March and the client needs the full previous financial year in the ledger for a tax return, the feed does not backfill — the prior-period PDFs have to come in via extraction.
• Audit working papers. When the auditor wants the PDF-anchored version of the transactions, with statement metadata preserved against the figures, the feed's view into Xero does not satisfy the request. The bank-issued PDF is what the auditor documents against, and extraction from that PDF is what produces the structured version for the working papers.
• Feed reliability gaps. CDR feeds miss, duplicate, or misclassify transactions more often than their reliability story suggests. When a reconciliation shows a difference between the NAB feed data in Xero and the PDF statement, extraction from the PDF is how you get a clean parallel view to identify exactly which line the feed got wrong.
• Accounting systems the NAB feed does not reach. Sage, FreeAgent, Reckon, and a long tail of industry-specific and bespoke accounting tools are not on the NAB-to-Xero feed. If the client's ledger is in one of those, the feed simply is not available as an option. Extraction into CSV or OFX is the import path.
• One-off workflows outside ongoing bookkeeping. Lender serviceability packs, insolvency reconstruction, forensic-accounting investigations, and due-diligence data rooms are all jobs where the feed was never the answer. These ask for statement-anchored structured data against specific PDFs, and extraction is the only path that produces it.

Use the NAB-to-Xero direct feed when the job is ongoing reconciliation inside Xero; use extraction when any of the five conditions above applies. Running both in parallel for the same reconciliation is not the answer.

Historical, card, and merchant statements

The workflow above covers recent transaction-account statements for NAB Internet Banking business customers — the common case. Three statement shapes sit outside that common case and come up often enough to flag.

Historical statements beyond the online archive. NAB Internet Banking holds a bounded archive of PDF statements. Transaction search tends to run back further than the statement-PDF archive; the window for downloadable statements is typically the period the account has been enrolled in online banking, but older downloadable statements age out of the online archive even when transaction search still returns them. When a bookkeeper, forensic accountant, or mortgage broker needs statements older than the online archive — for an NAB historical statement download covering an audit backfill, an insolvency reconstruction, or a full-financial-year tax lodgement — the request route is through a NAB branch or through NAB's phone support on 13 22 65. Lead times run days to weeks depending on how far back the statements go, and there can be a fee per statement for off-archive retrieval. Request them early in the engagement rather than at the deadline; this is the step that quietly blows timelines in audit and due-diligence work.

NAB Visa Business Card statements. The NAB Visa Business Card is a separate product with its own monthly statement — different document structure from the transaction-account statement, a different set of fields to preserve on extraction. Card statements carry merchant category codes (MCCs) alongside the merchant name, foreign-currency amounts when the card was used overseas, the AUD conversion amount, and FX conversion fees applied against each foreign-currency transaction. NAB Visa Business Card statement extraction is the same shape as for the transaction account — PDF in, structured spreadsheet out — but the column set the bookkeeper asks for differs: merchant, MCC, foreign amount, foreign currency, AUD amount, FX fee, transaction date, posting date. The interaction is the same; the prompt describes different columns.

NAB Merchant Services settlement statements. Businesses taking card payments through NAB Merchant Services receive monthly (sometimes daily) settlement statements documenting gross card receipts, interchange, scheme fees, and the netted settlement amount paid to the business account. These are PDFs and they are extractable on the same shape as the transaction-account and card statements, but the column set is different again: settlement date, gross card receipts, transaction count, interchange fees, scheme fees (Visa, Mastercard, Amex, eftpos separately), and net settlement. For anyone reconciling a retailer's Xero bank transactions against NAB Merchant Services payouts, extracting the settlement statement is what makes the reconciliation possible line-by-line rather than just on the net figure.