Everything about a yearly subscription is designed to be forgettable. You pay once, it works, and eleven months pass in which no part of the transaction requires any attention at all. That is the point of paying annually, and it is also why the records get lost.
They get lost quietly, too. An inbox gets cleared. A phone is replaced. An email address stops being the one you use. None of it feels like destroying evidence at the time, because nothing has gone wrong and there is nothing to have evidence about.
Why any of this is worth two minutes
Because of what a support desk or a bank actually needs when something does go wrong. Neither of them can act on a description. Both of them work by looking a transaction up, and looking it up requires the identifiers you were sent at the time and have most likely deleted since.
The gap between having those identifiers and not having them is not subtle. With them, a payment problem is one message and usually one working day. Without them, the first exchange is a set of questions establishing which payment is being discussed, and every round of that adds a day. The complete list of what a desk needs in order to answer immediately is in what to send support so a payment problem is solved in one message — this piece is about having it available a year later rather than an hour later.
The seven records worth keeping
Seven, and no more. Anything else generated by a subscription purchase is noise and can be deleted without consequence.
| Record | What it proves | When you will want it |
|---|---|---|
| Transaction reference | Which payment you mean | Any support or dispute question |
| Amount, date and currency | What was actually taken | Duplicate charges, surcharge queries |
| Order confirmation | What you were sold | Disagreement about plan or term |
| Terms as they stood that day | The bargain you agreed to | A clause changing mid-term |
| Stated end date | How long access runs | Renewal timing, early expiry |
| Support thread | That a problem was raised, and when | Escalation, or a late dispute |
| Credentials | Access itself | A new device, a reinstall |
Six of those seven arrive in the same few minutes after payment. The seventh — the support thread — accumulates later, and it is the one most often left in a messaging app that eventually gets cleared.
That last one is worth a sentence on its own, because people underrate it. A support thread is not useful for its content. It is useful because it carries dates, and dates establish that a problem was raised on a particular day rather than invented later. If a service degrades in month six and you mention it then, that thread is the difference between "it stopped working at some point" and "it stopped working on the fourteenth, and here is where I said so". Export it, or screenshot it, before the app decides to tidy itself up.
The transaction reference, and why it is the one
If only one item on the list survives, make it this. Everything else can be reconstructed with effort; the reference is what makes reconstruction unnecessary.
It is the string a payment carries through the system, and it is what allows a seller, a processor or a bank to find one specific transaction among thousands with the same amount on the same day. Without it, identifying your payment is a search. With it, it is a lookup.
Every route has its own version of it, and they are not interchangeable. A card payment carries an authorisation code and a longer scheme reference. A wallet payment has a transaction ID inside the wallet's own activity list, which is what any claim through that wallet will be indexed by. A cryptocurrency payment has a transaction hash, which is the strongest of the three — it is public, permanent and provable by anyone — and also the one most often not saved, because the payment felt finished the moment it confirmed. Whichever route you used, the reference lives on that route and nowhere else.
People routinely think they have saved it when they have not. A screenshot of a banking app's summary list shows a merchant name, a date and an amount, and none of those is a reference. The reference lives in the transaction detail view, one tap deeper, and in the confirmation the seller sent. It is worth checking now, on a payment you have already made, whether you could produce one in under a minute.
A useful sanity check: pick any subscription you pay for annually and try to find its transaction reference right now. Most people cannot, and discovering that on a quiet afternoon is considerably better than discovering it during the week a payment has gone wrong.
Snapshotting what you agreed to
Two pages are worth saving as they looked on the day you paid, rather than bookmarking.
The terms. Live pages show the current version. If a clause changes six months into a paid term, the version you agreed to no longer exists anywhere you can reach. A dated PDF or screenshot is the only copy, and the six clauses actually worth checking in it are set out in reading a subscription's terms before the money moves.
The price and plan page. Same reasoning, different use. This is what settles a question about which tier you bought and at what figure. Ours is published permanently on the pricing page at $69, $97 and $137 a year for one, two and three simultaneous screens, which means it can be checked against a public record rather than against anyone's memory — but not every seller publishes, and against one who does not, your snapshot is the record.
Both take fifteen seconds using the print-to-PDF function in any browser. Name the files with the date and the seller, because a folder of files called "document" is functionally the same as no folder.
How long to keep it — and why thirteen months
Thirteen months from the payment date. The extra month is not arbitrary.
A yearly subscription generates almost no questions during its term and a cluster of them immediately after. Did it renew on its own. Has an amount gone out again. What was the end date, exactly. Was last year's figure the same as the one being quoted now. Every one of those questions is answered by the previous year's records, and every one of them arrives in the weeks after the anniversary — the point at which a twelve-month retention habit has just deleted them.
There is a payments reason as well. Dispute windows on card networks run for months rather than weeks and can extend well past the point most people assume everything is closed, particularly where the complaint is about a service that stopped part-way through a term. What those windows actually cover is in chargebacks explained: what a card network will and will not reverse. Records that outlive the window are useful; records that expire inside it are a self-inflicted problem.
Where to put it
One folder, in something that syncs, not in the mailbox the confirmations arrived in.
The mailbox is the default because it requires no decision, and it is the weakest option available. Addresses get abandoned when a job changes or a provider is switched. Mailboxes fill up and start refusing mail. Bulk archiving moves things somewhere that is technically searchable and practically gone. And in a shared household, records in one person's inbox are records the other person cannot reach — a problem examined in paying from a shared or family account.
Naming matters more than structure. A file called "receipt" tells you nothing in a year; a file called "2026-08 pay-iptv 2-screen expires 2027-08" answers three questions from the folder listing alone, without opening anything. The test of a filing system is not how tidy it looks but whether the version of you who has forgotten it exists can still find one document in fifteen seconds.
A folder per year, named for the year, with a file per subscription inside it, is enough structure for anybody. It survives a change of email address, a new phone, and the person who set it up forgetting the system entirely, which are the three things a filing arrangement actually has to survive.
What not to keep, and what never to store
The list of things to discard is longer than the list to save, and discarding them is what stops the folder becoming unusable.
Delete marketing mail, delivery notifications, "your subscription is active" reminders and anything else generated automatically that contains no reference number. None of it proves anything and all of it makes the seven records harder to find.
Never store, in any folder: a full card number, a security code, a photograph of a card, or the sign-in details for online banking. None of these has any role in resolving a subscription question — the last four digits plus the reference identify a payment completely — and storing them creates exposure with no corresponding benefit. It is also worth internalising as a signal in the other direction: no legitimate seller asks for any of them, and one that does has told you something, as described in what a seller legitimately needs to know about you.
Credentials for the subscription itself are a separate case. They belong in a password manager rather than in the document folder, because the folder is optimised for being easy to find and a sign-in should not be.
The two-minute version
For anyone who will not build a system, here is the version that captures most of the value.
On the day you pay: create a folder named with the year and the seller. Drop in the confirmation email, a screenshot of the transaction detail showing the reference, and a print-to-PDF of the terms. Write the end date in the folder name. Stop there.
That is under two minutes and it covers five of the seven records. The support thread can be added later if there ever is one, and the credentials live elsewhere by design. Everything about our own confirmations — what should be in one, and what to do if none arrives — is in the receipt you should get, and what to do when none arrives, and if yours has gone missing at any point in the term, the desk can reissue it against the amount and date.
