Which date a record belongs to

An invoice dated 28 March, for goods delivered 2 April, ordered on the 19th, paid on the 11th, and photographed by you in May. Five dates, all real, all printed somewhere or recorded by something, and the file has to go in one place.

The question of which date a record “is” comes up constantly and gets answered by accident — usually by whichever date the filing tool noticed first. Answering it deliberately is a ten-minute decision that prevents a recurring class of confusion.

The dates in play

Order date. When it was agreed. Present on confirmations and quotes, absent from most receipts.

Invoice or receipt date. When the document was issued. Usually the most prominent date on the paper, which is why it becomes the default.

Payment date. When money moved. This is the date your statement knows, and therefore the date any reconciliation works from.

Delivery or service date. When you actually got the thing, or when the work was done. Frequently the date that matters most substantively and frequently printed nowhere.

Period covered. For anything recurring or ongoing — a service month, a cover period, a subscription cycle. Not a date at all but a span, which is why it fits the model badly.

Capture date. When you photographed or filed it. Carries no meaning about the transaction whatsoever and is nonetheless what a photo library sorts by.

For a till receipt paid in cash, most of these collapse into one and the question doesn’t arise. For anything invoiced, delivered, or subscribed, they don’t.

Where the ambiguity actually bites

Anything near a period boundary. A transaction that straddles the end of a year or a quarter sits in one period or another depending on which date you use, and the two answers are both defensible. This is the case where getting it wrong is visible.

Reconciliation. Your statement is organised by payment date and your files by invoice date. Matching them means accepting an offset of days to weeks, and near a boundary the two sources disagree about which period a transaction is in at all.

Retrieval. Someone asks for “the March invoices”. If you filed by payment date and they mean invoice date, you produce a set with the wrong edges — right in the middle, wrong at both ends.

Sorting by the wrong date entirely. A folder of receipt photographs sorted by capture date is sorted by when you got round to it, which is a fact about you and not about the records. Restores and copies then reset even that — see what happens to metadata.

The practice

Choose one filing date and use it for everything. Consistency is worth much more than correctness here, because a consistent scheme with a known offset is navigable and a mixed scheme isn’t. Invoice or receipt date is the usual choice: it’s printed on the document, it doesn’t require looking anything up, and it’s the date the other party would use if asked.

Put it in the filename, year first. 2026-03-28 sorts as text, is unambiguous across every date convention on earth, and survives copying. This is the single most useful convention in the whole of personal recordkeeping and it costs nothing — finding it again covers the rest of the naming scheme.

Never rely on the file’s own date. It’s the capture date at best and the restore date at worst.

Record the other dates where they differ materially. Delivery date for anything where delivery matters, payment date where it’s far from the invoice date, period covered for anything ongoing. A short note in the file or in the filename. You are not trying to encode all five; you are trying to make sure none of them is lost.

Expect and accept the reconciliation offset. Filing by invoice date means your files and your statement disagree by the payment lag. Fine, as long as you know which way. The problem is only ever an unknown offset.

Note the ambiguity for boundary cases explicitly. Where a transaction straddles a period boundary and the choice of date changes which side it falls on, write that down rather than resolving it silently. The resolution is a rules question — see below — and the note is what lets someone else answer it.

Keep or bin

KEEP OR BIN — dates on a record

  · One filing date, applied consistently,
    year-first in the filename
                    → KEEP. Consistency beats
                      correctness for retrieval.

  · A note of the delivery or service date
    where it differs
                    → KEEP. Often the substantively
                      important one and printed
                      nowhere.

  · Period covered, for anything ongoing
                    → KEEP. A span, not a date, and
                      it needs saying explicitly.

  · The photo's capture date as the
    record's date
                    → NOT THE DATE. It records when
                      you got round to it.

  · Filesystem "date modified" after a
    restore or copy
                    → BIN as evidence. It's the date
                      of the copy.

  · Dates written as `03/04/26`
                    → BIN the format. Ambiguous
                      between conventions and
                      unsortable as text.

  · Which date governs which period for any
    filing obligation
                    → ASK LOCALLY. Timing rules vary
                      by jurisdiction, by record type,
                      and by accounting basis.

The one thing worth writing down once

If you keep records for anything ongoing, add a single line to whatever notes accompany your archive: “records are filed by ___ date.”

That sentence answers the question for anyone who ever looks — an adviser, a partner, you in four years — and it takes the offset from an unknown to a known. Unknown offsets are what make a reconciliation feel impossible; known ones just make it slightly annoying.

It matters more than usual in a two-person system, where the failure is that each person filed by a different date and neither realised — see records two people share.

Where dates genuinely can’t be recovered

Two cases common in a backlog. A faded receipt whose date has gone — the top of a thermal slip fades no more slowly than the rest, and it’s where the date usually is. A matching statement line will supply the payment date, which is not the receipt date but is defensible provided you note where it came from. An undated document — some receipts, most handwritten ones, and a surprising number of small invoices. Date it from a corroborating source and say so, which is the record-versus-inference distinction from reconstructing a year you didn’t record. An inferred date is fine; an inferred date presented as printed is not.

What this doesn’t settle

Which date any obligation runs from. Whether records are treated on the date of invoice, payment, or delivery. How period boundaries are resolved. Whether an inferred date is acceptable where the printed one has faded. What accounting basis you are on, which is often the thing that decides all of the above.

Every one of those varies by jurisdiction, and several vary by choices you or your adviser have made. Ask your tax authority or an adviser. What this page settles is the filing question, which no authority addresses and which decides whether you can find the document at all.