Organising receipts so you can find them years later

Almost everyone stores receipts. The box exists, the drawer is full, the folder on the laptop has four hundred photographs in it. Storage is not the problem and it never was.

The requirement is retrieval under a specific and awkward condition: somebody names one transaction, possibly years old, described in terms that do not match how you filed it, and you have to produce the document for it. A query does not arrive as show me the receipt filed under transport in March. It arrives as a payment of eighteen thousand rupees left this account on the fourteenth of August, what was it for.

That framing settles most of the design questions. The system has to let you go from a bank line to a document, because that is the direction the question comes from. It has to work for whoever is looking, which may not be you, and may be at a time when you are unavailable. And it has to survive the interval, which is measured in years rather than months.

Judged that way, a chronological pile is better than it looks, since it maps directly onto a bank statement, and an elaborate category tree is worse than it looks, because it requires the searcher to guess which category the filer chose.

The retention period is longer than most owners assume, and it is set by more than one law at once, so the effective answer is the longest of them.

Under GST, section 36 of the CGST Act requires a registered person to retain the books and records until the expiry of seventy-two months from the due date of furnishing the annual return for the year they relate to. Seventy-two months is six years measured from that due date, which is later than the end of the year itself, so the real horizon is longer than six years from the transaction.

Under income-tax law, Rule 6F prescribes retention for six years from the end of the relevant assessment year for the professions it covers, and the reassessment provisions in section 149 determine how far back an assessment can be reopened, which is the reason a longer horizon can matter. That window has been amended more than once, so the current text is the only reliable source for it and any number quoted from an article may already be stale.

Other obligations sit on top depending on your business: company law, labour and provident fund records, and contractual or sector requirements each have their own periods. The practical conclusion is to pick a single retention horizon comfortably beyond the longest one that applies to you, confirm it with your accountant once, and apply it to everything rather than trying to run different clocks for different documents.

The honest answer for most Indian small businesses is digital as the working copy and physical retention for what must be kept, with the split decided deliberately rather than by drift.

Physical originals have one clear advantage: nothing depends on a device, an account or a file format continuing to exist. They have serious disadvantages that people underestimate. Thermal paper receipts, which is most of them, fade, and a blank slip is not a document. Paper is destroyed by water and by relocation. And a physical archive is searchable only in the order it was filed, so a mis-filed document is functionally lost.

Digital copies solve retrieval and fading and introduce their own failure modes. A single copy on one phone is one broken phone away from nothing. Photographs of receipts are useless if the fields are illegible, and the fields that get cut off are consistently the ones that matter: the GSTIN, the tax breakup, the invoice number, the date.

Whether a scan satisfies a particular retention obligation, and in what form, is a question worth asking your accountant rather than assuming, because it varies by the type of record and the law imposing it. The rule that holds regardless is redundancy: any archive existing in exactly one place is not an archive, and the moment to discover that is not when it is asked for.

The traditional argument is between filing chronologically and filing by expense category, and it is the wrong argument, because a single physical ordering cannot serve both.

Chronological filing wins on the query that actually arrives. Questions come from bank statements and from periods, both of which are ordered by date, and month-by-month folders let you go from a date to a small stack. It loses when the question is what did we spend on transport this year, which requires reading everything.

Category filing wins on analysis and loses on retrieval, because the searcher has to reproduce the filer's classification decision, and if two people file, they will not classify identically.

The resolution is to stop treating the physical order as the index. File chronologically, because dates are unambiguous and require no judgement, and let the categorisation live in the books, where each entry carries its head, its date and its amount. Then category analysis is a query against the ledger rather than a search through paper, and retrieval is a lookup by date.

What makes this work is a reference connecting the two: a number written on the document that also appears against the ledger entry. Any consistent scheme is fine. Without that link, the ledger and the archive are two collections that describe the same events and cannot be joined, which is exactly the state that makes a year-old query expensive.

The belief that you will recall what a payment was for is the single most common cause of undocumented expenses, and it fails for reasons that have nothing to do with carelessness.

It fails because of volume. A business doing thirty transactions a month generates hundreds a year, and they are individually unmemorable by design; the memorable ones are already documented because they were significant. It fails because of time, and the relevant interval is not until filing but until somebody asks, which may be years. It fails because of personnel: the person who knew is not necessarily the person answering, and may have left. And it fails because reconstruction feels like recall. Looking at a bank line for a familiar supplier and concluding it must have been the usual monthly order produces an answer that is plausible, unverifiable and sometimes wrong, and nothing distinguishes it from a memory.

The cost is concentrated and predictable. An unsupported expense is one a cautious preparer excludes, which raises taxable profit. A purchase invoice that cannot be produced puts the input tax credit claimed on it at risk. Both are losses that arrive with no notice attached, because a return that omits a deduction is perfectly valid.

The practical countermeasure is not a better memory or a better filing cabinet. It is writing the purpose on the document at the moment it is received, in enough words that a stranger could understand it, because that is who will be reading it.

A good archive means that when a document exists, you can produce it quickly, in a legible state, years later. That is the whole of what it promises, and it is worth having.

It does not create documents. The most disciplined system in the world contains nothing for a cash purchase where no receipt was taken, and that gap is invisible from inside the archive: a folder does not know what is not in it. The only thing that detects a missing document is comparison against an independent record, which is what bank reconciliation does for anything that went through a bank and what nothing does for cash.

It does not establish that a document is genuine or that the expense qualifies. A filed invoice proves a payment was made against a stated description. Whether the expenditure is deductible, whether the credit is admissible, and whether the classification is right are separate questions decided by law and by facts, and no amount of organisation touches them.

This is where any document management tool sits too, and the distinction is worth being exact about. Software can store, index, make searchable, extract fields, and reconcile a set of documents against a set of ledger entries to tell you precisely which entries have nothing attached. That last capability is genuinely valuable, because it converts an unknown gap into a list. What it cannot do is produce the receipt that was never taken, or tell you that the transaction it describes never happened.