How to keep your records so that you do not lose them along with your phone

Four ways to lose your records

• The phone is gone: drowned, stolen, smashed so badly it will not turn on. If the records lived only in it, they are gone with it. This is the most common case, and it does not depend on the app.
• The app stopped working: the developer shut it down, or an update broke it, or your phone model is no longer supported. The records are inside, but there is nothing to get them out with.
• You forgot the sign-in code. If the records are protected by a code and there is no other way in, they are intact but out of reach — which for you is the same as lost.
• You deleted them yourself. You were clearing out old things, tapped the wrong thing, “cleaned out” an account that was still needed. The most annoying case, because nobody but you is to blame.

Rule one: a copy you keep yourself

1. 1Once a month make a backup — a file that holds all your records. In most tracking apps that button is in the settings; if there is none, that is a reason to wonder why.
2. 2Keep the file somewhere other than the same phone. The cloud, a computer, an email to yourself — any place that will outlive the phone. A copy on the same phone as the app is not a copy.
3. 3If the file is protected by a password, write the password down somewhere you will find it a year from now. A copy that cannot be opened is not a copy.
4. 4Once every six months check that the file opens. The best check is to restore the records from it on a second device, or in the same app after reinstalling it. A copy that has never once been restored is a hope, not a copy.
5. 5Make the copy on the same day every time — say, the first of the month, together with your review of the month. A copy made “when I remember” gets made once, and it will be missing precisely in the month it is needed.

Rule two: an export that opens anywhere

A backup is a file for that same app: it will restore everything from it exactly as it was, but opening it with anything else is usually not possible. So a second file is needed — an export in the form of an ordinary table, which any spreadsheet program on any computer will open. That is your insurance in case the app disappears for good.

The difference between them is simple: the export is for reading, the copy is for restoring. From the table you will see all your entries with dates, amounts and categories and can move them anywhere you like, but it will not keep the settings, the receipt photos and everything else that does not fit into rows. The copy keeps everything, but only for “its own” app.

An export is worth doing less often than a copy — once every six months or once a year is quite enough. What matters is that it exists, and that you have opened it at least once and made sure it really holds your records, not an empty table with headers.

Rule three: the recovery code, not on the phone

If your records are protected so that nobody can read them without your code, that is good exactly as long as you have the code. Lose the code and you have lost the records, and here nobody can help, not even the developer: the whole point of the protection is that nobody but you can read them.

So the recovery code, the password to the copy, the second way of signing in — all of it has to be kept where it will outlive the phone. A sheet of paper among your documents. A password manager, if you use one. A note in your parents’ safe. Anything except the notes on the very phone the app is on: the phone will disappear together with them.

And write it down at once, when you receive it, not “later”. A recovery code is shown once, when you create it, and at that very moment it seems it will never be needed. It will be needed when the phone is already gone.

Who can read your records

This question is worth putting to any app you trust with your money, and the answers vary a great deal. “The data is stored on a server” means the developer stores it, and if they want to, or if there is a break-in, it can be read. “The data is encrypted” can mean the same thing: locked, but the key is with the developer, and they read it when they need to.

An honest answer looks like this: the records are locked with a key that only you have, and the server stores them in a form it cannot itself read. Then even the developer, even on request, will see only a string of characters. The price of that is rule three: if you lose the key, nobody will give it back to you.

A simple way to check that you are being told the truth: ask what happens if you forget your code. If the answer is “we will restore it” — then it can be read without you. If it is “the records will be lost, so keep the code safe” — that is the very answer that means only you can read them.

Deleting: what can be brought back, and what cannot

An accidentally deleted entry is the most common loss, and it is the easiest to insure against: in a good app what is deleted goes into a bin and stays there for a while, say a month, before disappearing for good. Noticed the loss a week later — brought it back. So before clearing out old things, it is worth knowing whether the app has a bin and how long it holds things.

Deleting the account is another matter. That is for ever: the records on the server, the records on the phone, everything. Before it, it makes sense to make both a copy and an export — just in case a year from now you need to look up what the rent cost that year. A year from now it will be nowhere.

And one more way of “deleting” that people do not think of: switching off the transfer of records between devices, if it was on. That may remove the copy from the server or from the second phone, and what looked like “just a setting” turns out to be a deletion. Before any switch with the word “data” on it, it is worth reading what exactly it does.

Example: the phone drowned, the records stayed

Iryna had kept records for a year and a half, made a copy on the first of every month and kept it in the cloud, with the recovery code on paper inside her passport. In August the phone fell into a lake. She bought a new one a week later, installed the app, signed in with the recovery code, downloaded the copy from the cloud, entered its password — and saw everything as it had been on the twenty-eighth of July.

The lines for the last ten days were gone — between the copy and the lake. She restored them from the card statement in half an hour; the cash for those days she recorded as one amount and did not try to remember. The loss: half an hour and ten days of approximation. Without the copy the loss would have been a year and a half.

One lesson she took away: a copy once a month means up to ten days of approximation in the worst case. Now she makes it twice a month, and it is still less than a minute. The export to a table she did once, as a check, and it still sits in the same cloud next to the copies — for a case she hopes will never come.

A check every six months

• Restore the latest copy on another device or after reinstalling the app. If everything is in place — the copy works. If not — you found out at a time when it costs nothing yet.
• Open the export in a spreadsheet and look at a random month. Dates, amounts, categories — all there? Empty columns are a reason to make the export again.
• Find your recovery code where you kept it and make sure it is legible. Paper fades, password managers change owners, the note in the safe gets lost.
• Check whether the place the copy lives in has changed. A cloud drive you stopped paying for deletes files without warning.
• In FinLad a backup is a single file with a password you choose, made without an internet connection and available on every plan, including the free one. Export to a table is there separately. The records are stored so that only their owner can read them — which is exactly why the recovery code in the app is shown once and has to be kept safe. What is deleted sits in the bin for thirty days; deleting the account is for ever, and the app says so before doing it.