Move From YNAB to Pocket Runway

Pocket Runway imports a YNAB plan export: your accounts, your full transaction history, your categories, payees and memos. It is a file migration. Pocket Runway never connects to your YNAB account, makes no API call to YNAB, and never asks for your YNAB password.

This page covers what comes across, what deliberately does not, and what to check before you finish setting up.

Import my YNAB data

1. What the import supports

Every account in the export, with a balance rebuilt from its transaction history
Your full transaction history, as far back as the export goes
Categories and category groups, kept on each transaction
Payees and memos
Transfers as transfers, rather than as a spend on one account and income on the other
A paycheck candidate, detected from your deposit history and proposed for you to confirm

Two places to start it: during onboarding, as an alternative to setting everything up by hand, or later from the Transactions page if you have already set up an account and want to bring history in.

2. How to export from YNAB

Open YNAB on the web at app.ynab.com.
Click your plan name in the top-left corner.
Choose Export plan.
YNAB downloads two CSV files. Upload both.

YNAB's own help pages are the authority on their export, and the option may move: search YNAB's help centre for "export" if the steps above do not match what you see.

3. Which files to select

The export gives you two CSVs, both of which are needed:

The register (the file ending -Register.csv) holds your transactions.
The plan, or budget, file (ending -Plan.csv) is how your categories are read, including categories with no transactions in them, and how the pair of files is checked to be from the same export.

A YNAB 4 register is also accepted.

The uploaded files are never stored. They are read, and the figures are re-derived from them again when you confirm, which is why you upload them once and confirm in the same sitting.

4. What Pocket Runway imports, in detail

Accounts. The export carries an account name but not its type, so the type is inferred from the name and from the rebuilt balance, and then shown to you to confirm or change before anything is written. An unrecognised name is deliberately treated as a tracked, non-spendable account rather than guessed as checking: guessing wrong there would put a whole balance into your safe-to-spend figure.

Transactions. Every register row becomes a transaction with its date, amount, payee and memo. Your categories come across on the rows themselves in the form Group: Category, which is what lets Spend Trends and the category breakdowns group your migrated history the way you had it organised.

Transfers. A YNAB transfer is two rows, one on each account. They are paired by date, amount to the cent and both account names, and exactly one becomes a Pocket Runway transfer, recorded on the account the money left. A leg whose partner is missing from the export is kept as a transfer anyway and reported in the count, since that is the classification that invents neither income nor spending.

5. What Pocket Runway deliberately does not create

No recurring bills. Nothing is guessed from your transaction history. YNAB's targets, which are the thing that would actually answer the question, are not in the export, and a guessed bill lands directly in your safe-to-spend number. You enter your bills in the next step of onboarding exactly as anyone else does.
No sinking funds or savings goals. Same reason.
No paycheck. A paycheck candidate is detected and proposed, but the import never creates a pay schedule on its own. Confirming it in onboarding is what creates it.
No budget history. YNAB's monthly assigned, activity and available figures describe a monthly envelope model. Pocket Runway plans by pay period and has no envelope table, so those columns are read to tell an active category from a dormant one and then dropped. Forcing them into a runway figure would be inventing a number.
Nothing about your YNAB account. Only the files you upload are read.

6. How balances are reconstructed

YNAB's export does not contain account balances, so each account's balance is rebuilt by adding up its register: the opening balance row plus the net of every transaction after it.

That rebuilt figure is written as the account's balance directly, and the imported transactions themselves are inserted without moving it. That matters: an import that wrote an opening balance, then a history, then a correcting adjustment is exactly how an importer doubles someone's money. After the write, the import re-reads everything it just created and checks every balance to the cent, and if anything disagrees the whole import is rolled back rather than half-applied.

7. How liabilities are handled

YNAB reports a credit card you owe $500 on as a balance of -500. Pocket Runway stores debt as a positive balance on an account marked as a liability, because that is what the payoff reserve and the debt tracking read.

So a liability's sign is flipped once on the way in. An overpaid card, where you are in credit, becomes a negative liability, which is correct.

8. Transfers, refunds and recent inflows

Three kinds of row are left out of the ledger on purpose, and the count of each is always reported rather than being silent:

YNAB's synthetic starting balance rows, which are already inside the rebuilt balance.
The mirror leg of each transfer, since one leg is the transaction and the other would be a duplicate.
Inflows and transfers from roughly the last month, including refunds recorded as inflows.

That last one needs explaining. Your account balance already reflects a deposit from last week. If that deposit were also added as income to your current pay period, it would be counted twice: once inside the balance and once as funding. The same is true of an ad-hoc transfer. Spending does not have this problem, because the engine adds in-period spending back to reach the period's opening cash and then subtracts it again, so it nets out wherever the period boundary falls.

The cut-off is 31 days, which is the longest a Pocket Runway pay period can be, so anything older than that provably cannot fall inside your current period whatever pay schedule you confirm.

Rows dated in the future are also left out, because a scheduled transaction has not happened and importing one would let money you have not spent reduce your safe-to-spend figure.

9. How paycheck detection works

Deposits are grouped by payee and account, and a candidate has to clear four independent tests: at least three occurrences, a regular gap between them, a stable amount, and recency. Transfers, starting-balance rows and outflows are excluded outright, and there is a minimum amount so that interest credits do not register as a salary.

Cadences recognised are weekly, biweekly, semi-monthly, monthly and irregular. Semi-monthly is separated from biweekly by looking at which days of the month the deposits fall on rather than by the gap between them, because twice-monthly gaps alternate around 15 days and sit inside the biweekly range. A gap test alone reads a twice-monthly schedule as biweekly, and every pay period boundary after that is wrong.

Only a high-confidence candidate with a clear cadence is proposed. Lower-confidence ones are listed but never preselected, and when nothing is proposed, onboarding asks when you get paid exactly as it does for someone with no import. The detection is deterministic, not a model call: it decides what you are shown as your paycheck, so it has to give the same answer every time.

10. What to review before finishing onboarding

Account types. Check the checking, savings, credit card and tracking labels. Anything marked as spendable feeds your safe-to-spend figure.
Which account is your primary spending account. This is the one the daily number is calculated against.
The detected paycheck. Confirm the amount, the date and the cadence, or enter them yourself.
Your bills. Nothing was imported here, so this is where your plan is actually built.
Anything flagged. An account whose type could not be inferred, an unpaired transfer, or a register with ambiguous dates is reported on the review screen rather than quietly resolved.
A cash account. A YNAB "Cash" account maps to a spendable type, which is right for a wallet, but it does mean its balance counts toward what is safe to spend.

11. What to expect on day one

Your history is there and your plan is new. Transactions, categories, payees and balances come across; bills, funds and goals are things you enter. Expect the first session to include real setup work.

Trends need Pocket Runway pay periods. Spend Trends and the pay-period comparisons are built on pay periods, and your first one begins when you finish onboarding. Your imported history is present and searchable immediately, but the period-over-period views have nothing to compare until you have completed a cycle or two.

The daily number will move as you add bills. A figure calculated before your bills are entered is calculated against nothing reserved. That is expected, not an error.

Importing the same export twice is refused. The files are fingerprinted by content rather than by filename, so re-uploading the same export is blocked by the database rather than by a disabled button.

12. Troubleshooting common export problems

Only one file downloaded. Both are needed. Re-run Export plan and check your downloads folder, and unzip the archive if your browser saved it as one.

The upload was refused as the wrong kind of file. The files are sorted by their column headers rather than by their names, so renaming will not help but re-exporting will. Make sure you exported the plan rather than a single account's transactions.

Dates look wrong. A register where every date is ambiguous, like 03/04, is read month-first, which is YNAB's US default, and you are warned. A register written two contradictory ways is refused rather than guessed.

An account came in with the wrong type. Change it on the review step before confirming. That is what the step is for.

The import failed partway. It cannot. The whole write is a single database transaction with a full verification at the end, so a failure leaves nothing behind and you can retry.

13. What changes when you move from category budgeting to paycheck budgeting

This is the real adjustment, and it is worth understanding before you decide.

YNAB asks: what job does every dollar have? You assign your balance across categories, and the categories are where the thinking lives. It is a complete and coherent system, and for people who want to direct every dollar deliberately it works very well.

Pocket Runway asks: what can I safely spend before the next paycheck? Instead of allocating a balance across categories, each pay period reserves only the bills, transfers and savings that fall before your next paycheck, and turns what is left into one daily figure. Money for a bill three weeks out is simply not part of this period.

What that means in practice:

There are no envelopes to refill. Nothing goes red for being overspent in a category, because the plan is not built from categories. Your imported categories are kept on transactions and used for reporting, not for budgeting.
The month stops being the unit. A three-paycheck month is another pay period rather than an anomaly, and a bill landing on the wrong side of a payday is visible as a property of that period.
There is less to maintain and less to steer. One daily number is easier to live with day to day. If the thing you valued about YNAB was the deliberate allocation of every dollar, that is a real trade, and it is the one to think about.

YNAB is a good product and this is a difference in model, not a ranking. Pocket Runway vs. YNAB sets the two side by side in more detail.

Import my YNAB data

This page is general educational information, not financial advice. YNAB is a product of You Need A Budget LLC and is not affiliated with Pocket Runway. Export steps are as they were when this page was written and may change; YNAB's own help pages are the authority on their software.