Finding it again

Nine thousand files. Somewhere in them is the invoice for the thing that broke, from a supplier whose name you half remember, from a year you’re not certain about. Search is no help, because the file is called IMG_4471.HEIC and nothing inside it is text.

This is the failure that survives every other fix. You captured it. You backed it up. It’s in three places. And it takes forty minutes to find, which for practical purposes is the same as not having it.

Storage is solved, retrieval isn’t

Worth stating plainly, because the tooling conversation is entirely about the first one. Capacity is free. Sync is reliable. Backups are automatic. None of that touches retrieval, and retrieval is the only part you actually experience.

Retrieval has two routes, and a system should support both because they fail in different circumstances.

Search, when you know something specific — a vendor name, an amount, a word. Fails when you don’t know it, when the record contains no text, or when the term is too common.

Browse, when you know roughly where in the structure it should be. Fails when the structure is deep, inconsistent, or was designed by someone with different assumptions from present you.

The practical goal is that any record can be found either way, in under a minute, in three years.

The filename does the work

Nearly all of it, and this is the single highest-leverage habit in the subject.

A filename is text. It’s searchable by every operating system and every service, it survives being moved, copied, emailed and re-uploaded, it doesn’t depend on any application’s metadata, and it’s visible while browsing. Nothing else about a file has all those properties.

A convention that works, in order:

YYYY-MM-DD first. ISO date order means alphabetical sorting is chronological sorting, everywhere, for free. This is why the date goes first and why the format is not negotiable — 14-03-2026 sorts by day of month, which is useless.

Vendor next. The name you’d actually search for, not the legal entity on the receipt. If the slip says “NWTS Holdings Ltd” and you know them as Northwest Tools, write Northwest Tools. Consistency matters more than accuracy here: pick one spelling per vendor and never vary it.

Amount. Optional, and more useful than it sounds when reconciling against a statement.

What it was for. The field that was never on the paper. Two or three words. This is the part that makes the file findable by the question you’ll actually be asking, which is never “what did I buy on 14 March” and always “where’s the thing for the studio monitor”.

So: 2026-03-14 Northwest Tools 48.60 studio monitor cable.pdf

Long, ugly, and findable by date, by vendor, by amount and by purpose. Filenames are not for looking at.

Flat beats deep

The instinct is to build a folder tree: year, then category, then vendor. It’s tidy for about four months.

Deep hierarchies fail for a specific reason: every filing decision is a chance to be inconsistent, and the categories drift. Is a train ticket to see a client “travel” or “clients”? You decided one way in January and the other way in September, and now the record exists in a folder you won’t think to look in. The more levels, the more decisions, the more drift.

The alternative that survives: one folder per period, flat inside. No categories, no vendor subfolders. Everything from a period in one place, sorted by date because the filenames sort that way, with categorisation carried in the filename text where search can reach it.

This also aligns with disposal by cohort: one folder is one retention unit, and there’s no risk of a long-hold record hiding three levels down in a year you’re about to delete.

The exception, and it’s the same exception as everywhere: long-hold records — assets, property, loans, employment — live in their own permanent place outside the period folders.

Keep or bin

KEEP OR BIN — a retrieval system

  · ISO-dated filenames with vendor and
    purpose
                    → KEEP. Does most of the work
                      alone.

  · One flat folder per period
                    → KEEP. Fewer decisions, less
                      drift, aligns with disposal.

  · Deep category hierarchy
                    → BIN it. Categories drift and
                      every level is a chance to
                      misfile.

  · Tags or labels inside one application
                    → useful, but NOT PORTABLE. They
                      don't survive export. Never let
                      them be the only structure.

  · A spreadsheet index alongside the files
                    → KEEP if you'll maintain it. Most
                      people won't; the filenames are
                      the maintainable version.

  · Extracted text search on scanned images
                    → helpful, unreliable on faded
                      thermal print. Don't rely on it
                      as the only route.

  · Whether your naming or structure satisfies
    any requirement you're subject to
                    → ASK LOCALLY. Rules on record
                      form and accessibility vary.

Consistency beats optimality

Any convention applied every time outperforms the best convention applied sometimes.

Which has a practical consequence: choose something you’ll do at capture, one-handed, in a car park, in about fifteen seconds. If the convention requires a lookup, a decision, or opening a second application, it will be skipped exactly when you’re busiest — and the records from busy periods are the ones you most need.

If you’re renaming on a phone immediately after photographing something, the realistic version is date-vendor-purpose and no amount. That’s fine. A slightly worse convention you actually follow is a much better system.

Fixing an existing pile

Don’t do it all. The pile is large, the effort is unbounded, and the attempt is how people conclude that organising records is impossible.

Two moves that are worth it and nothing else:

Start the convention from today. Everything new gets named properly. This costs nothing extra and the new stuff is what you’ll be searching for most often.

Rename backwards only when you touch something. If you go into the pile to find a record, rename that one before you leave. Over a year the frequently-needed records — which are a small fraction — get fixed, and the rest stay as they are, which is exactly proportional to how much anyone cares.

The remainder of the pile can sit in a folder called unsorted-pre-2026 forever. It’s still there, it’s still within whatever retention applies, and it costs nothing. Bulk retroactive organisation is a project that competes with the habit that would actually fix things, and the habit wins.

What this doesn’t settle

Whether any particular structure, filename or format satisfies a requirement you’re subject to. Some regimes have rules about how records must be kept and how readily they must be producible on request; those vary by jurisdiction and by what you do.

This page is about being able to find things, which is a precondition for producing them and useful regardless of what any rule says. Whether your arrangement meets an obligation is a question for your tax authority or an adviser.