How to convert a PDF bank statement to IIF for QuickBooks Desktop
This is the conversion people reach for when everything else has been taken away: the bank feed is gone, Web Connect is refused because the Desktop version is past its end of service, and the only thing the bank will still give you is a PDF. IIF is the format that still works, because it imports straight into the register instead of going through Intuit. QBOKit reads the PDF inside your browser and writes the IIF there too, so the statement is never uploaded and there is nothing to install.
🔒 Convert your PDF statement to IIF now — free, runs in your browser, nothing uploaded.
Read this first: this is the riskiest conversion in the whole set
Most guides to this pair sell you a converter. This one starts with the warning, because two separate weaknesses stack on top of each other here and neither is obvious:
- A PDF has no columns. There is only text at positions on a page, so the table has to be reconstructed by guessing which text belongs to which row and column. It is reliable on most downloaded statements and it is not exact. This is true of every PDF converter, ours included.
- An IIF file carries no transaction ids. A
.QBOfile gives every transaction aFITIDthat QuickBooks uses to skip duplicates. IIF has no such field, so a bad import does not fail, it lands, and a second attempt lands again on top of it.
So the order of operations matters more than the tool. Check the preview before you download, and import one statement period at a time. With QBO you can be sloppy and the FITID protects you. With IIF from a PDF, nothing protects you, and the clean-up is manual.
If your Desktop version still accepts Web Connect, convert the PDF to QBO instead and keep the duplicate protection. Only use IIF when QBO is refused. That is genuinely the whole decision.
The steps
- Download the statement PDF from your online banking as usual.
- Drop it on the converter. The page fetches its PDF reader at that moment and reads the text out of the file on your own machine.
- Check the table it found against the statement — a couple of dates and a couple of amounts. This is the step people skip and the one that matters.
- Pick .IIF as the output.
- Type both account names exactly as they appear in QuickBooks — the bank account, and a second account for the other side of each entry. There is no default and the file will not be written without them.
- Import it in QuickBooks Desktop:
File → Utilities → Import → IIF Files.
Get the account names exactly right
This is the single most common way an IIF import goes wrong, and it is worth knowing that the two camps describe it differently. Intuit’s own IIF overview says an unmatched account is created, not refused: If you import a transaction with an account that is not already created in the QuickBooks data file, that account will be created as a new bank account.
DocuClipper’s guide to the same import instead warns about an Account Name does not exist
error and tells you to validate your chart of accounts first.
Both outcomes are bad and the fix is identical, so do not bother working out which you will get: open QuickBooks, look at your chart of accounts, and copy both names across character for character. Matching is fussy about case, punctuation and stray spaces. A single typo — Business Checking against Business Chequing — either stops the import or leaves you with a second bank account holding everything you just imported and a reconciliation that will not balance until you find it.
The second account is where the other half of each double entry lands. Uncategorized Expense is the usual choice, and you re-categorise from there.
Scans and photos will not work, and that is worth being clear about
This needs a PDF that contains real text. A statement downloaded from online banking almost always does, because it was generated as a document. A scan or a phone photo of a paper statement is a picture of text with nothing to extract. Reading those needs OCR, which QBOKit does not do — if you drop one in, it says so plainly rather than handing you an empty file.
This matters particularly for this page’s audience. If you are on an old Desktop version chasing historical periods, the statements you need may well be scans in a filing cabinet. If yours are, a paid cloud service with OCR is the right tool and we are not it. The honest alternative to try first is asking your bank for a CSV export of the period, which most now offer, and converting that to IIF instead — a CSV has real columns, so it removes the first of the two risks above entirely.
What you are choosing between
| Where the statement goes | Scans | Cost | |
|---|---|---|---|
| QBOKit | Nowhere. Read in your browser. | No — text-layer PDFs only | Free, no account |
| Cloud converters | Uploaded to their servers, machine-read there | Yes, via OCR | Monthly subscription, often per page |
| Installed converters | Stays on your PC | Varies | One-off licence, Windows |
We are not the best tool in that table for every case — if you have scans, you need OCR and should pay for it. We are the only row that is free, needs no install, and never receives the document. For a bookkeeper converting a client’s statement, that last column is not a feature, it is the question your engagement letter is about: a cloud converter needs a copy of a document that belongs to someone who was not asked.
You can verify our claim rather than trusting it. Open your browser’s network tab while converting: you will see the PDF reader being downloaded to you and no statement going back. To be straight about the one thing you will see, there is a small request to our server recording that a conversion happened, carrying counts only — how many rows, whether the columns were detected. No cell value, no account number, no file name.
What comes out
Three header lines beginning with !, then one balanced double entry per transaction, separated by real tab characters. This block is actual output from running a five-column statement PDF through the converter, not an illustration:
!TRNS TRNSTYPE DATE ACCNT NAME CLASS AMOUNT DOCNUM MEMO
!SPL TRNSTYPE DATE ACCNT NAME CLASS AMOUNT DOCNUM MEMO
!ENDTRNS
TRNS CHECK 04/01/2026 Business Checking -82.40 DIRECT DEBIT ACME LTD REFERENCE
SPL CHECK 04/01/2026 Uncategorized Expense 82.40 DIRECT DEBIT ACME LTD REFERENCE
ENDTRNS
TRNS DEPOSIT 04/02/2026 Business Checking 2000.00 SALARY PAYMENT APRIL HANDLING CO LIMITED
SPL DEPOSIT 04/02/2026 Uncategorized Expense -2000.00 SALARY PAYMENT APRIL HANDLING CO LIMITED
ENDTRNS
Money out of the bank is a CHECK, money in a DEPOSIT. The TRNS line carries the amount on your bank account and the SPL line the opposite amount on the second account, so every entry balances to zero. Dates are written M/D/YYYY whatever your statement used, because that is what the format expects — a UK statement reading 04/01/2026 as 4 January comes out as 01/04/2026 here, and that is correct, not a bug.
Why the description goes in MEMO and never in NAME
The same rule that creates accounts applies to the payee list. NAME in an IIF transaction is a QuickBooks name-list entry, so an unrecognised NAME gets created too. Bank descriptions are nearly all distinct, and PDF statements are the worst case here because a reconstructed description often picks up a reference number as well — look at DIRECT DEBIT ACME LTD REFERENCE above. Writing those into NAME would add one new payee per transaction to a list you then clean by hand.
QBOKit writes the description into MEMO and leaves NAME empty, as you can see in the block above. Check this before using any other converter: it is easy to get wrong and tedious to undo.
What it fixes on the way through
Once the rows are out of the PDF they are treated exactly like a CSV, so a PDF inherits every repair the CSV path already had:
- Day-first versus month-first decided from the whole date column, not row by row, so a UK or European statement is not half-read as American. See wrong dates after import.
- Separate Paid in and Paid out columns merged into one signed amount — which is what decides
CHECKversusDEPOSIT. The sample above came from exactly that five-column layout. 1,234.56and1.234,56both read correctly, plus parenthesised and trailing-minus negatives.- Title blocks, address blocks and closing-balance lines skipped rather than turned into transactions.
- A tab or line break inside a description stripped out — in a tab-separated file one stray tab would shift every later column on that row and quietly corrupt the import.
If your statement carries a running balance, QBOKit reconciles it: every movement between two balances is checked against the amount that caused it, and you are told how many agree. On a PDF that check is the fastest way to catch a column read wrongly, so look for it.
IIF, QBO or QIF for QuickBooks Desktop?
| Format | Desktop takes it? | Transaction ids | Use it when |
|---|---|---|---|
| .QBO | Yes, via Web Connect | Yes | Your version still accepts Web Connect. Always try this first. |
| .IIF | Yes, via File → Utilities → Import | No | Web Connect is refused, or your version is past its end of service. |
| .QIF | No | No | Never for Desktop. QIF is for Quicken, Xero and GnuCash. |
QuickBooks Online does not import IIF at all. If you are on QBO rather than Desktop, note that it can read a PDF statement itself — see the PDF to QBO guide for what that route costs you in privacy.
What we cannot claim
We have not tested these files against a QuickBooks Desktop install past its end-of-service date, because we do not have one. The output follows the headers Intuit documents, and the full PDF-to-IIF chain is checked by our own test suite — 30 assertions across two statement layouts, covering the balanced double entry, the empty NAME, the M/D/YYYY dates and the tab-field count. But follows Intuit’s documented format and passes our tests
is a smaller claim than QuickBooks accepted it
, and we would rather say so than imply the larger one.
PDF reading here is also new. Statements vary enormously in layout, and a converter that reads one bank’s PDF perfectly can make a mess of another’s. The preview is not decoration.
📮 If yours is refused, or the preview got it wrong, please tell us — hello@qbokit.com. Which bank, and the exact error text QuickBooks showed, is the single most useful thing anyone could send us. Do not send the statement itself; we neither want nor need your transactions.
Convert my PDF statement to IIF — free
Or see it work on a sample statement — no file of your own needed.
Sources
- IIF Overview: import kit, sample files, and headers — Intuit. The definition of an IIF file, the header rows, and the account-creation wording quoted above.
- Import bank statement transactions into QuickBooks Desktop (IIF) — DocuClipper, for the import menu path and for the
Account Name does not exist
wording and their advice to validate the chart of accounts first.