How to get your data out of a budgeting app
Export is the difference between a service and a trap. What a real export contains, what to test before you commit years of entries, and the specific ways a CSV gets corrupted on the way between two apps.
The moment to think about leaving a budgeting app is before you join it, which is exactly when nobody does. Three years later you have several thousand entries, a category scheme you have refined, and a household that has learned to use it — and the app raises its price, changes owners, drops the feature you relied on, or simply shuts down. What you can do at that point is decided entirely by a design decision somebody made long before you arrived.
Small apps close constantly and larger ones get bought and repositioned. The relevant question is not whether an app is trustworthy but whether it is survivable, and the answer is almost entirely a question about export.
What "export" should mean
The word is loose enough to be nearly meaningless. Several things get called export and only one is any use.
A summary export gives you monthly totals per category. That is a report, not your data — you can read it, you cannot rebuild anything from it. A partial export gives you rows but drops the note, the sub-category, the member or the time, and every dropped field is work that does not survive the move. A PDF is not an export at all; it is a picture of your data.
A real export is every row, with every field, in a format that other software can read. The test is simple and it is the only test worth running: take the export and put it back into the same app, into an empty account, and see whether you get the same ledger. If the round trip does not close — if the sub-categories flatten, the notes truncate, the member disappears, the times reset to midnight — then the export is lossy, and a lossy export is lock-in wearing the costume of an open door. It looks like you can leave. You can leave with most of it.
The sub-category is where this most often goes wrong, and it is worth checking specifically. Many apps export a single "category" column because it is tidier, which quietly discards the second level of a scheme you may have spent a year building. That level is the whole reason you can tell groceries from takeaway, or the annual insurance from the monthly one. Export it or lose it.
What to check before you commit years of entries
- Is export free? If moving your own records out requires a subscription, the subscription is not paying for a feature, it is paying for the removal of an obstacle that was placed there deliberately. This is the single most informative thing you can learn about an app’s intentions.
- Is it the whole ledger or a summary? Ask for a sample export, or make one on day one with three test entries and read the file.
- Is it a format anything can read? CSV is unglamorous and universal. A proprietary backup file that only that app can open is a backup, not a portable copy — useful against losing your phone, useless against losing the company.
- Does it include who spent it? In a household ledger this is a real field with real meaning, and an export that drops it turns a two-person book into an anonymous one.
- Does it include the note, and can you export without asking anyone? Notes are where the reasons live, and a support ticket with a thirty-day wait is friction that exists for a reason.
- Does the same app import that format back? One that cannot never expected anyone to arrive from elsewhere.
The unglamorous mess of actually moving between apps
Suppose you have your CSV. The move is still not trivial, because CSV is a family of loosely related conventions rather than a standard, and a household ledger manages to hit almost every ambiguity in it.
Character encoding
A file that opens perfectly in one place and appears as a wall of question marks in another is almost always an encoding mismatch. Exports from Chinese-language software are frequently GB18030 rather than UTF-8. A reader that assumes UTF-8 and gets GB18030 does not fail loudly; it produces text-shaped garbage, and importing it anyway permanently corrupts every note and category name. An importer has to detect this rather than assume, which is why Fambook decodes both.
Numbers that are not numbers
Thousands separators are the usual culprit — an amount exported as 1,234.50 contains a comma, in a comma-separated file, and a naive parser turns one column into two and one amount into twelve. Currency symbols, non-breaking spaces used as separators, and a comma used as the decimal mark in much of Europe all produce their own versions of the same problem. A careful importer strips these and tells you what it did.
Notes containing real line breaks
This is the one that catches most homemade scripts. People write multi-line notes — a shopping list, an explanation, an address — and a correctly written CSV preserves those line breaks inside quoted fields. Any tool that reads the file by splitting on newlines will therefore shred every such row into fragments and either fail or, worse, import the fragments as separate broken entries. The file must be parsed as CSV, with quoting understood, not treated as a list of lines.
The refund that says it is an expense
A very common real-world inconsistency: a row has a type column saying "expense" and an amount of minus twenty, because it is a refund and the exporting app represented it by negating the amount rather than changing the type. Import it literally and you have recorded a negative expense, which will do something unpredictable to your totals depending on how the receiving app handles the sign. The correct behaviour is to notice the disagreement, flip the row to the type the amount implies, and tell you how many rows were flipped so you can check. Fambook does this and reports the count.
Importing the same file twice
You will. It is the most common way an import goes wrong, and it usually happens because the first attempt appeared to fail. Without de-duplication you now have every entry twice and a month that reads as double what you spent. A per-row fingerprint — date, time, amount, type and note taken together — catches the repeats, which is how Fambook handles it. Rows that genuinely cannot be used should be skipped with a stated reason and the physical line number, so you can go and look at line 412 rather than being told that "some rows failed".
Portability as a right, and the limits of it
In the European Union, Article 20 of the GDPR gives people a right to receive personal data they have provided to a service in a structured, commonly used and machine-readable format, and in some cases to have it transmitted directly to another service. The United Kingdom retains an equivalent provision, and comparable rules exist in a number of other jurisdictions, with California and Brazil among the more frequently cited. Where such a right applies, it is a genuine backstop and worth knowing you have.
Two honest caveats. The first is that whether any of this covers your particular situation depends on where you live and where the service operates, and that is a question for someone qualified rather than for a budgeting guide. The second is more practical and applies everywhere: a right to receive your data is only as valuable as the format it arrives in. A company can comply with a portability request by sending a large, technically machine-readable file whose structure is undocumented and whose relationship to what you see in the app is unclear, and you will have exercised your right and gained very little. The legal right sets a floor; a well-designed export is what actually gets you out.
Fambook’s position
CSV export and CSV import are both free, deliberately. Export produces one row per entry with type, amount, category, sub-category, note, member, place, date and time, with the sub-category included specifically so that a round trip does not flatten a level of your scheme. Import handles the mess described above — both encodings, column guessing, thousands separators, notes with line breaks, sign-and-type disagreements with a count of what it flipped, unusable rows skipped with a reason and a line number, and duplicate detection by fingerprint.
The reasoning is not generosity. Export is how a person leaves with their own records, and charging for the exit converts years of somebody’s work into leverage over them.
What to do regardless of which app you use
- Export on day one, before you have anything to lose, and read the file. You are checking that it exists, that it opens, and that the fields you care about are in it.
- Export every few months and keep the raw files, not just the latest one. An export from two years ago is the only surviving copy of how you categorised things two years ago.
- Before switching apps, run the round trip: export, import into the new app, compare one month’s totals. If they disagree, find out why before moving the rest.
Frequently asked questions
What should a proper export contain?
Every row and every field you can see in the app: type, amount, category and sub-category, note, who spent it, place, date and time. The test is the round trip — export, import into an empty account, and check you get the same ledger. If anything flattens or disappears, the export is lossy and leaving will cost you part of your records.
Why is my exported CSV full of strange characters?
Almost always a character encoding mismatch. Exports from Chinese-language software are often GB18030 rather than UTF-8, and a reader that assumes UTF-8 produces garbage rather than an error. Open the file specifying the right encoding, or use an importer that detects both, and do not import a file that already looks corrupted.
I imported the same file twice. What now?
You have every entry duplicated and a month reading roughly double. An importer that fingerprints each row by date, time, amount, type and note will skip the repeats on the second pass, which is how Fambook handles it. If yours does not, the fix is usually to delete the imported batch and start again from a clean state rather than to weed out duplicates by hand.
Does the GDPR guarantee I can move my data to another app?
Article 20 gives a right to receive personal data you provided in a structured, commonly used, machine-readable format, and the UK and several other jurisdictions have comparable rules. Whether it applies to your situation depends on where you and the service are, which is a question for someone qualified. In practice the right sets a floor: what determines whether the move is actually possible is how usable the file is.
Is export free in Fambook?
Yes, and so is import, deliberately. Export is how you leave with your own records, so putting it behind a subscription would be charging for the exit rather than for a feature. The subscription covers things that save typing, such as voice, photo and AI-assisted entry, repeating entries, and households larger than two people.
How often should I export a backup?
Every few months, and keep the old files rather than overwriting one. It costs a minute and covers three separate risks at once: the app shutting down, something going wrong with your account, and your own accidental deletion. Old exports are also the only record of how you used to categorise things.
Try it for one month
Fambook gives a household one shared ledger: anyone can add an entry in seconds, every entry says who spent it, and the month adds up in one place instead of two. Records with no signal and syncs afterwards. Recording, categories, budgets, statistics, CSV import and export, sync and sharing for two people are free — the subscription only buys you less typing.