How to move your history from Wallet
Wallet exports a clean, well-formed file, and almost all of it moves across without trouble. There is one honest exception, and it is better to know about it before you import than to go looking for missing money afterwards.
How to bring it in
- 1. Export your history from Wallet. Either the CSV or the XLS works.
- 2. Open Money Talks, go to Settings and tap Import Data.
- 3. Choose Wallet from the list of apps.
- 4. Pick the file you exported.
- 5. Read the preview. Transfers are listed as skipped on purpose, with their dates, so you can note them before you confirm.
- 6. Confirm, then add the transfers by hand.
The file you need
Wallet exports a CSV or an XLS file. The CSV is semicolon-separated.
You have the right file if its first line looks like this:
account;category;currency;amount;ref_currency_amount;type;payment_type;note;date;transfer;payee;labelsAmounts are always positive here. The type column is what says whether a row is income or an expense.
Frequently asked questions
Why are my Wallet transfers not imported?
Because the export does not say where the money went. Wallet writes each half of a transfer as its own row with a transfer flag set to true, and each row names only the account it belongs to. There is no shared id, and on a cross-currency transfer the two amounts differ, so even matching by date and amount would not reliably find the pair. Money Talks refuses to guess and tells you which rows they were.
So what do I do with them?
The preview lists them with their dates and amounts before you confirm anything, so take a note of that list. After the import, add each transfer once in Money Talks. For most people this is a handful of rows: rent moved to a joint account, a top-up of a travel card. It is a few minutes of work, and it is work you only do once.
Does everything else come across?
Income and expenses, dates, categories and subcategories, the account name, the currency of each row, and your note. Where a row has no note, the payee is used instead. Labels and the payment type are left behind. Wallet writes amounts as positive numbers with the direction in a separate type column, which Money Talks reads correctly, so nothing arrives with the wrong sign.
My file uses semicolons instead of commas. Is that a problem?
No. Wallet's CSV is semicolon-separated and Money Talks expects that. Do not convert it in a spreadsheet first: re-saving a CSV usually rewrites the dates into your system format, which creates a problem that was not there before.
What comes across from Wallet by BudgetBakers
- Every income and expense with its date and note
- Categories, including the ones Wallet writes as Category, Subcategory in a single field
- The currency on each row, so a multi-currency history stays multi-currency
- The account each transaction came from
- The payee, on rows where you left the note empty
What does not come across
- Transfers between your own accounts - Wallet marks them with a transfer flag but writes each half as its own row naming only its own account, with nothing shared to link the two. Pairing them would mean guessing, so Money Talks lists them in the preview instead. See below for what to do about it.
- Labels and the payment type - Money Talks has no tags, and it records how you paid on the account rather than on each row, so the payment_type column is left behind.
- The payee, when the row also has a note - Wallet writes both, and a transaction carries one line of text. The note wins because you typed it about this purchase; the payee fills in when the note is empty.
- The reference-currency amount - Wallet writes a second copy of each amount converted into the currency your app was set to. Money Talks converts to your base currency itself from the original amount, so the copy is not needed.
- Your accounts themselves - Each transaction remembers the account name it came from, and the preview lists the names it found. Money Talks does not recreate the accounts or their balances.
What comes across, in one sentence
Income, expenses, dates, categories, subcategories, account names, the currency of every row, and the note you wrote. For most Wallet users that is the file.
Two smaller columns do not make the trip. Labels have no home in Money Talks, and the payment type is a property of the account here rather than of each transaction. The payee is used as the transaction’s text when you left the note empty, so it is only lost on rows that have both.
The exception: transfers
Wallet has a transfer column that says true or false. That tells you a row
is part of a move between two of your own accounts. It does not tell you which
two.
Each half of the transfer is its own row, and each row names only the account it belongs to. There is no id shared between them and no column pointing at the other side. The information about where the money went is not hidden in the file. It was never written to it.
You might think the halves could be matched by date and amount. Sometimes they can. But a transfer between accounts in two currencies has different amounts on each side by definition, and two transfers of the same size on the same day are common enough that the matching would be wrong rather than merely incomplete.
A wrong pairing is worse than none. It invents a movement between two accounts that never exchanged money, and it does so silently, which means you find out months later when a balance refuses to reconcile.
So Money Talks does not guess. It marks those rows as skipped on purpose, counts them, and shows them to you in the preview with their dates before you confirm anything.
What to do about them
Note the list in the preview, import the rest, then add the transfers by hand.
In practice this is usually a short list. Transfers tend to be recurring and deliberate: moving money to savings, topping up a travel card, settling with a partner. Most people have a handful of patterns rather than hundreds of one-off moves.
This is the honest state of a Wallet migration today. If your history is mostly transfers, it is worth knowing that before you start rather than after.
A note on cleaning the file first
The export is semicolon-separated, which surprises people who open it in a spreadsheet and see one column. The temptation is to fix it and save it again.
Resist it. Re-saving a CSV rewrites the dates into whatever format your computer prefers, and a file that would have imported cleanly now needs its dates repaired. Import the file exactly as Wallet produced it.