When the bundled software owns your scans

Scanners are usually sold with software, and the software usually offers to organise your scans for you. That offer is more consequential than it looks, because “organise” often means storing the images inside a library the application controls rather than as ordinary files in a folder you chose. Years later that distinction decides whether your archive is a folder you can open or a database you need a dead application to read.

Two ways an application can store a scan

As files. The application writes an ordinary image or document file to a location on disk, in a widely readable format, with a name. It may also keep an index for searching, but the index is a convenience and the files are the truth. Delete the application and the scans are still there.

As a library. The application keeps the images inside its own container — a database file, or a folder of pieces named by identifier — along with the categories, notes and extracted amounts you have added. The application is the only thing that knows how the pieces relate. Delete it and you have a directory of opaque data.

Both are legitimate designs and the library approach genuinely enables things files cannot do easily. The problem is that the choice is often made for you at install time, is not presented as a choice, and only becomes visible when you need the scans somewhere else.

How to find out which you have

Look on disk, not in the application. Find where the software says it stores data, open that location, and see what is there. If you find images with recognisable names that open in anything, you have files. If you find one large file with an unfamiliar extension, or a folder of items named by long identifiers, you have a library.

Then try the harder test: open one scan without the application running. Not export, not print — navigate to it and open it with something else. If you cannot, the application is load-bearing in your archive, and every risk to the application is a risk to the records.

What goes wrong, and when

The failure is never sudden. It arrives as one of these, and usually late.

• The application stops running. It was not updated for a new operating system, or the vendor discontinued it. This is the same problem that strands the hardware, described in the driver is the part that expires — except that here it takes the existing archive with it, not just the ability to make new scans.
• The application requires an account, and the account lapses. Some desktop software checks in. When the service behind it ends, the local library can become unreadable even though the data is on your own disk.
• A version upgrade will not read old libraries. This has a long history in this product category, and it is worth checking before upgrading rather than after.
• You want the scans somewhere else. A different tool, a different computer, an accountant. Suddenly the export function’s quality is the only thing that matters, and you find out what it actually produces.
• Someone else needs the archive. A partner, a successor, a colleague — anyone who does not have the application installed and configured.

Export is not a backup

The distinction matters. A backup of a library is a copy of something you still need the application to read; if the application is the problem, the backup inherits it. An export is a conversion into a form that does not need the application at all.

So the question to ask of any bundled software is not “can I back it up” but “what exactly does the export produce, and can I read it with nothing else installed?” Try it. Export a handful of items and examine the result. Are the images at full quality or re-encoded smaller? Do the file names mean anything? Are the notes, categories and amounts you typed included, or only the pictures? Is there any record of which scan corresponds to which entry?

A frequent and unwelcome answer is that the images come out fine and everything you added — the categorisation, the notes on why a spend happened — does not. That data was often the more valuable half.

Watch also for re-encoding on the way out, since exporting through a lossy step degrades the image a second time, for reasons in compression and scan quality.

The arrangement worth aiming for

Let the device or software write ordinary files to a folder you chose, and let anything clever be an additional layer on top. If a tool wants to index, categorise, or extract amounts from your scans, that is welcome, as long as the underlying images remain readable without it. Then the tool is replaceable and the archive is not.

Practically, on a new setup: find the storage setting before the first batch, point it at a location you control, and confirm by looking at the folder afterwards. Retrofitting this decision after several years of scans is possible but it is a migration project rather than a setting.

This is the same principle that applies to where a wireless scanner sends its output, and to any service that stores your documents on your behalf — see wireless scanning: where the file actually goes. In each case the question is whether you end up holding readable documents or an account with someone.

Run the export test annually

The only reliable check is periodic and cheap. Once a year, export a sample from whatever holds your scans and open the result on a machine with none of that software installed. If it works, you are fine for another year. If it does not, you have found out while the application still runs, which is the only time the problem is fixable.

Do the same check before any major version upgrade, and immediately if you hear the software is being discontinued — at that point the export function is a limited-time offer.

What form records must take, whether an exported copy is adequate, and how long anything has to be kept are not questions about software architecture. They vary by country and by the kind of entity keeping the records, so put them to your own tax authority or an accountant in your jurisdiction rather than inferring an answer from what your application happens to export.