YNAB says no transactions or skips your file: what to check before importing again

Start with the warning, not a different converter

YNAB's File-Based Import guide, updated September 22, 2026, recommends CSV and also accepts QFX, OFX and QIF. These instructions use the web app on a computer. A PDF or Excel workbook is not one of those file types, and renaming its extension to .csv doesn't convert it.

The guide lists malformed bank files and a file with no rows containing both a date and a nonzero amount as possible reasons for “No Transactions.” But its separate $0 FAQ explicitly says zero-amount rows are no longer skipped during file import. The page doesn't explain the difference, so don't delete genuine zero-value entries as a blanket fix. Distinguish them from blank padding and informational rows in the preview. If a fresh bank download is malformed, ask the bank for a corrected export rather than guessing missing data.

A single Amount column is enough

Older instructions can send you on an unnecessary spreadsheet detour. YNAB's CSV formatting overview, updated August 13, 2026, says separate reformatting is no longer necessary. Its September 14, 2026 release note describes the built-in CSV converter. Start with the bank's native export, not an old five-column template.

Before working through the columns, confirm the destination account at the top of the import window. Then check the mappings for Date, Payee, Memo, Outflow and Inflow: Date needs the transaction date, not a reference number, and the amount fields need transaction amounts, not the running balance. If the first record is a transaction rather than headings, select No header row so it isn't mistaken for column names. These controls are documented in the current import guide.

One signed Amount column can supply both fields: select that same column for both Inflow and Outflow. YNAB reads its positive and negative values, so you don't need to split it first. With separate money-in and money-out columns, map each to its corresponding field. A known purchase and a known deposit, refund or payment give you something to compare against the source. If both directions are reversed, the documented Swap Inflow and Outflow option can correct that. Don't reverse an entire file to repair one bad row.

The guide says account settings are remembered by default, so check the mapping again if your bank changed its export layout. Categories and split transactions do not import from the file. Automatic categorization is different: the release note describes payee cleanup and categorization inside YNAB, not importing your spreadsheet's Category column.

Check the date itself, not just whether it looks like one

A date mapped to the wrong column can leave no usable transaction dates. An ambiguous date can be more deceptive: 04/05/2026 can mean April 5 or May 4, depending on the source convention. Compare the preview with a known transaction and the statement period before confirming the import. A plausible date in the wrong month is still wrong.

The current YNAB pages cited here don't publish an exhaustive list of accepted CSV date formats, so don't treat an older tutorial's US date layout as a universal current requirement. The fictional CSV below uses year-month-day to make its intended dates clear; we haven't tested that layout in YNAB. If you standardize a working copy, establish the bank's date order and year first. Keep the original and inspect the resulting preview. The date and number format guide explains the ambiguity checks.

Skipped can mean already known, even after deletion

YNAB distinguishes matching a manually entered transaction from skipping a repeated import. Its duplicate and skipped transaction guidance says an imported transaction can match a manual entry when the amounts are exactly equal and the dates are within ten days. That is not a ten-day duplicate-suppression window: for File-Based Import used regularly or alongside Direct Import, YNAB says it skips imported transactions with the exact same date and amount to avoid duplicates. This is its documented rule, not evidence that every pair of equal-date, equal-amount purchases is one transaction.

A row disappearing from your view doesn't necessarily mean the importer forgot it. The same guidance says a transaction that was imported and then deleted cannot be imported into that account again. Don't assume a fresh download, an edited payee or different separators reset that history. Never change a genuine transaction's date or amount just to make it look new.

Before deciding a row is missing, search the register and read the skipped-row explanation. Payee text may differ because YNAB now cleans imported payees. If two genuine purchases share a date and amount, an incorrect match is another possibility to check. Its matching guide, updated September 28, 2026, describes this possibility and how to unmatch transactions. You can inspect the match details in the web register by double-clicking the transaction, then clicking the link icon in the second column. Resolve a wrong match before adding another entry. If the purchase is still missing after checking the register, keep its source evidence and ask support or enter it manually.

Three different date boundaries can affect a backfill

“Old transactions” can refer to three different things in the current import guide. Keep them separate when checking why recent rows appeared but older ones did not.

• Transactions before the account start date aren't necessarily excluded. If your file includes them, the import window offers a choice to include or exclude them, so check that choice rather than assuming every row in the file was selected.
• The reconciliation boundary is different: YNAB says transactions dated more than three days before the last reconciled transaction aren't imported. That means the date of the transaction, not simply the day you clicked Reconcile.
• For history more than one year old, YNAB does not recommend file imports. The guide presents this as a recommendation, not a stated hard one-year file limit.

For a fictional last reconciled transaction dated October 15, 2026, October 11 is more than three days earlier; October 12 is exactly three days earlier. That calculation only explains this boundary. An October 12 row can still be skipped for another reason.

Don't undo reconciliation merely to force an old file through. First decide whether you need the history in YNAB or just need a separate spending worksheet. YNAB's transaction-entry guide, updated July 10, 2026, notes that categorizing old spending may not be worth the work for a forward-looking plan. If you do need to backfill, use the historical-import checklist to record the missing period and existing coverage.

Three file rows, but only two genuinely new transactions

This synthetic example is one fictional USD checking account. Assume the October 11 Cedar Supplies purchase is already imported in YNAB, neither later row is present, and the account-start and reconciliation boundaries do not exclude them. Keep this example out of your real account; use it to understand the file and the arithmetic.

Date,Payee,Memo,Amount
2026-10-11,Cedar Supplies,Notebook,-25.00
2026-10-12,Rowan,Shared dinner reimbursement,120.00
2026-10-13,Harbor Books,Guidebook,-25.00

You can paste this CSV into a plain-text file or a checker: it has a header, three transaction rows and one signed Amount column. For YNAB's documented mapping, Amount supplies both Inflow and Outflow. The file's net movement is $70.00: -25.00 + 120.00 - 25.00. But the two genuinely new transactions total $95.00: 120.00 - 25.00. The existing $25 purchase should not become another outflow simply because it appears in the download again.

Now suppose two separate receipts show two real $25 purchases on the same day. Their combined outflow is $50, not $25. A checker may flag the pair, but date and amount alone cannot decide whether both happened. Nor can it know which transaction YNAB remembers from a deleted import. Keep both source rows until that question is resolved.

Use only the checker that answers your remaining question

A readable native CSV can go straight to YNAB's preview. These free tools are optional inspection steps, not a required conversion pipeline or a YNAB certification.

1. If columns or characters are broken, open CSV format repair and inspect the cells after choosing the source separator and, for a file, encoding. The tool doesn't normalize dates or amounts, and it blocks export on broken quotes rather than guessing. For its protected export, mark Amount as numeric with the correct number convention so valid negative amounts aren't treated as formula-like text. Review every reported protection change before using the output. A semicolon alone isn't a reason to repair the file: YNAB's September release note says semicolon-separated CSVs are supported.
2. If you can't tell what the signs mean, the debit/credit converter lets you review money-in, money-out and net totals while leaving dates uninterpreted. Confirm the direction against a real transaction before changing anything. You don't need to create two columns merely for YNAB, because its native single-Amount mapping already handles that layout.
3. For overlapping exports, the duplicate finder needs both the earlier source file and the incoming file. Give them the same account alias and currency, map Date, Payee as description and Amount, and confirm the date and number conventions. The tool starts by keeping every row, so review its candidates against the source before selecting any exclusion.

To explore the fictional overlap, compare the three-row CSV above with a second pasted table containing the same header and just its October 11 row. A day tolerance of zero exposes the repeated Cedar Supplies candidate while retaining both originals for review. This comparison represents source-file overlap only: the tool does not connect to YNAB, inspect its register or know its deleted-import or reconciliation history. Don't upload the combined review file as though every retained row were new.

Retry once you can explain what should change

A retry is easier to review when you've kept the original download and noted the target account, file date range, transaction count, signed total and exact warning. Before confirming it, compare a known inflow, a known outflow and the earliest date in the preview, then count which rows are genuinely new, already present or still unresolved. A successful upload doesn't mean the balance is right: inspect the resulting register and reconcile it to the bank.

For a few deleted imports, manual entry may be simpler after checking they really are missing. For unexplained skips, use the support contact in the YNAB guide with the warning and your findings. Don't post a real statement in a public forum to demonstrate the error.

YNAB also documents replacing an account to reset this import history. That procedure moves transactions and deletes the old account, so it is not a harmless retry. Prefer support before taking that route and establish a recovery plan first. The same guide warns that exporting a YNAB plan is one-way: you cannot re-import the plan, so an export alone is not a restorable backup.

If your bank supplies the missing period as CSV, use that native export. If only PDF statements remain, manual entry may suit a short gap; AnyStatement can convert a PDF statement to CSV for a longer one, with rows linked to their source PDF lines for review. Conversion is a separate upload, not a fix for YNAB's remembered imports or date boundaries, and it does not guarantee acceptance.

What we checked

We opened YNAB's File-Based Import guide (updated September 22, 2026), CSV formatting overview (August 13, 2026), September 14 release note, transaction-entry guide (July 10, 2026) and matching guide (September 28, 2026) on October 18, 2026. They are linked beside the rules above. We parsed the fictional CSV and recomputed its amounts with Python Decimal, including the $70 file total and $95 genuinely new movement. We did not import it into a live YNAB plan or test a bank connection. These checks establish the example's arithmetic, not complete account history, ledger reconciliation or document authenticity.