Data Archiving Best Practices: Readable in 2031

An accountant asks for one invoice. Number 2024-0416, from the job system you retired in March. The archive is where you left it, a 6.2 GB ZIP on the office file server, copied there the week the subscription lapsed. It opens on the first try.

Inside are 41 CSV files, a folder called attachments holding 4,812 files with names like att_9f3c21b0.bin, and nothing anywhere that says which invoice any of those 4,812 files belongs to.

Nothing failed. No disk rotted, no bit flipped, the download was not truncated. The export was complete and unusable at the same time, which are not opposites. That is what most five-year-old archives turn out to be, and the reason rarely varies: the export was judged on whether it downloaded rather than on whether a stranger could retrieve one named record from it without the software that made it.

The rule that turns "we cannot open it" into "you destroyed it"

Revenue Procedure 97-22 governs keeping books and records in what it calls an electronic storage system. Section 4.01(9) contains the sentence that belongs at the top of every archive folder:

"Electronically stored books and records that are contained in an electronic storage system with respect to which the taxpayer ceases to maintain the hardware and the software necessary to satisfy the conditions of this revenue procedure will be deemed destroyed by the taxpayer, unless the electronically stored books and records remain available to the Service in conformity with this revenue procedure."

Deemed destroyed. Not degraded, not inconvenient (IRS, Rev. Proc. 97-22, read 29 August 2026).

This is not a dusty citation. Publication 583, revised December 2024, still sends small business owners to it by name, and compresses the standard into one line: the electronic storage system "must index, store, preserve, retrieve, and reproduce the electronically stored books and records in legible format" (IRS Publication 583, read 29 August 2026).

Two further clauses matter to anyone whose archive is really a login. Section 3.03 says that using a third party such as a service bureau "does not relieve the taxpayer of the responsibilities described in this revenue procedure." And 4.01(7) says the storage system "must not be subject, in whole or in part, to any agreement (such as a contract or license) that would limit or restrict the Service's access to and use of the electronic storage system," naming personnel, hardware, software, files, indexes and documentation in the same breath. A cancelled account is exactly such a restriction, arriving on the vendor's schedule rather than yours.

Whether a particular pile of exports counts as books and records is a question for your accountant. What the retention obligation attaches to, and for how long, has its own clocks and its own page. This one starts a step later: the files are yours, and the job is keeping them openable.

Seven properties, listed by people who lose this argument professionally

Federal agencies are required to write down what a record must retain. 36 CFR 1236.10 lists the controls needed for records in electronic information systems, and the list works better as an archive specification than anything a vendor help centre publishes.

Text read from the eCFR issue of 36 CFR Part 1236 on 29 August 2026. Part 1236 binds federal agencies. It does not bind your company. It is still the cheapest specification available, and the last three rows name what exports drop. Content survives almost any dump. Context and structure — which record links to which, which file belongs to which invoice — are the parts you add by hand, because no export button has ever been graded on them.

The companion section is blunter about time. 36 CFR 1236.14 requires migration whenever records "must be maintained and used beyond the life of the information system in which the records are originally created or captured," including "any necessary conversion of storage media to provide compatibility with current hardware and software" and "maintaining a link between records and their metadata through conversion or migration." The life of the system, not the life of the business. Five years is comfortably longer than the life of most systems.

Preferred, acceptable, and whatever the application happened to write

NARA publishes the table it uses to decide whether a transferred file is durable enough to accept. For born-digital textual data the preferred formats are ASCII, Unicode text in UTF-8 or UTF-16, OpenDocument Text, PDF/A-1 (ISO 19005-1:2005) and PDF/A-2 (ISO 19005-2:2011). Ordinary PDF versions 1.0 to 1.7, DOCX and legacy DOC are listed only as acceptable. For structured data the preferred list runs CSV, ODS, ASCII, JSON, XML 1.1 and SIARD, with XLSX and XLS once again merely acceptable (NARA Appendix A: Tables of File Formats, read 29 August 2026).

One instruction on that page costs nothing and gets skipped everywhere: "Agencies must identify the character encoding method used with each text file." Encoding is invisible until the day a supplier name comes back with a black diamond in the middle of it, and by then nobody remembers what wrote the file.

The PDF line needs a correction the same page supplies elsewhere. Saving a report as PDF is not the same as producing PDF/A, and the difference is usually fonts. NARA's rules for PDF case files require that all PDF files "must have all fonts, including the base 14 fonts, embedded within them," a requirement met "by embedding subsets of all fonts used in the document, or by saving as a PDF/A-3 or PDF/A-4f file." A PDF that references a font it does not carry renders differently on a machine that lacks that font, which is precisely the machine that will open your archive in 2031.

Practical version: keep the vendor's native file where one exists, because it is the only exact copy of the original books. Then add an open-format rendering of the same material, because the native file stays readable only for as long as somebody licenses the application that wrote it.

The file that explains the other files

NARA's general requirements for structured data contain the sentence that would have rescued the archive at the top of this page: structured data "must be transferred together with any associated files necessary to verify the validity of the data, e.g., DTDs, schemas, and data dictionaries."

The same section offers three details worth stealing outright. On delimiters: "The pipe or caret are recommended delimiters because they are not commonly found in free text fields." On shape: "A record should not contain nested repeating groups of data items," which is the formal way of saying that the twelve columns called Comment in your export are a symptom rather than a feature, a point covered from the export side in which exports keep your structure. And on fixed-width text, if you go that way, files "must be accompanied by complete documentation of the record lengths and field widths."

So every archive gets a plain-text README, written while the account is still open, naming:

• the source system, its plan tier and any version the interface shows, plus the date and time zone the export ran in
• the character encoding, the delimiter, the date format (ISO 8601, or it will be ambiguous in three countries), the currency and the number formatting
• one line per column per file, saying what the column means and which columns are identifiers
• what the export is known to omit, in the vendor's own words, with the URL and the date you read it

The column that goes missing most often is the record ID, because the default view did not show it and nobody added it before hitting export. It is also the one column you cannot regenerate afterwards, and without it the attachments folder can never be joined back to anything. Add the ID field to the view first, export second.

Attachments become files, and the index becomes a record in its own right

Rev. Proc. 97-22 defines an indexing system in terms anyone can implement: a system that "permits the identification and retrieval for viewing or reproducing of relevant books and records," whose worked example is "assigning each electronically stored document a unique identification number and maintaining a separate database that contains descriptions of all electronically stored books and records along with their identification numbers." It adds that the requirement is met "if the indexing system is functionally comparable to a reasonable hardcopy filing system." A spreadsheet clears that bar.

NARA's case-file rules show what such an index looks like once somebody has to accept it. Every PDF collection must arrive with an external index, in Excel or CSV, sharing the name of the file it describes, carrying mandatory fields for file name, creation date, modified date, access restrictions, and a Message Digest field defined as "The MD5 Checksum value of the embedded file."

Build the same thing, one row per attachment: source record ID, invoice or job number, original file name, the name it is stored under, byte size, SHA-256, and the date it was created in the old system. That single CSV turns a folder of opaque blobs back into evidence. Almost nobody produces it, because on export day the links still work and the problem is invisible.

A manifest is what separates an archive from a folder

RFC 8493 documents BagIt, the packaging convention the Library of Congress and a long list of repositories use for exactly this purpose. It is short, it is Informational rather than a standard, and you can implement it by hand.

A bag is a directory containing data/ with the payload, a bagit.txt of exactly two lines declaring the version and the tag-file encoding, and at least one manifest-<algorithm>.txt mapping every payload file to a checksum, in which "every payload manifest MUST list every payload file name exactly once." Optional metadata goes in bag-info.txt, including Bagging-Date, External-Description and Payload-Oxum, the octet and file count "intended for the purpose of quickly detecting incomplete bags before performing checksum validation." From version 1.0, tools "MUST support the SHA-256 and SHA-512 algorithms" (RFC 8493, IETF, read 29 August 2026).

The two definitions in section 3 are the entire argument. A bag is complete when every file listed in every manifest is present. It is valid only when, on top of that, "every checksum in every payload manifest and tag manifest has been successfully verified against the contents of the corresponding file." Complete is what you get by copying a folder. Valid is what you get by checking it, and the gap between those two words is where silent corruption lives for four years.

Two copies, two media, one morning a year

Rev. Proc. 97-22 leaves storage practice to the taxpayer — "a business decision that is solely within the discretion of the taxpayer" — then lists what such practices "may include": labelling stored records, "providing a secure storage environment, creating back-up copies, selecting an off-site storage location, retaining hardcopies of books or records that are illegible or that cannot be accurately or completely transferred," and "testing to confirm records integrity."

Testing is the item everyone reads past. Publication 583 explains why it is not optional in spirit: "The IRS may test your electronic storage system, including the equipment used, indexing methodology, software and retrieval capabilities." Somebody else may run your restore before you ever do.

Put a date in the calendar, once a year, and spend forty minutes on it:

1. Verify the manifest. A mismatch or a missing file found now is found while a second copy still exists.
2. Pick three items — the oldest record, the newest, and one attachment — and open them on a machine that has never had the vendor's application installed. That machine is the honest test.
3. Open one PDF on a computer without your font library and see whether it still looks like the document.
4. Copy the archive forward onto current media instead of trusting any one disk's shelf life, which is what 36 CFR 1236.14(b)(2) means by converting storage media for compatibility with current hardware.
5. Add a dated line to the README saying what you checked and what failed. Next year's version of you is the auditor here.

An archive that needs someone's password belongs to someone else

The last failure mode is the one that looks like success. The data is fine. It lives in an account.

Google's Takeout documentation states that "Your archive expires in about 7 days" and that "We only allow each archive to be downloaded 5 times; after that, please request another archive" (Google Account Help, checked 29 August 2026). Notion says of its export link, "This link will expire after 7 days," and closes off the obvious recovery route with "You can't instantly recreate your workspace by reuploading your exported workspace content" (Notion Help Center, checked 29 August 2026). Seven days is a delivery window. It is not storage.

Microsoft's subscription lifecycle article is the sharpest of the three because it prices delay. A business subscription moves Active, Expired, Disabled, Deleted, and "for most offers, in most countries and regions" those middle stages run 30 days and 90 days. During Disabled, "Data is accessible to admins only." Then the sentence that ends the plan: "Any customer data that you leave behind might be deleted after 90 days and will be deleted no later than 180 days after cancellation." And, for anyone tidying up a bill, "If you explicitly delete a subscription, it skips the Expired and Disabled statuses and SharePoint Online data and content, including OneDrive, is immediately deleted" (Microsoft Learn, article dated 8 June 2026, checked 29 August 2026). The button that stops the charges can be the button that removes the archive.

Which is why the test for a finished archive is a sentence rather than a checklist. Hand the drive to somebody who has never used the old system, name one record, and watch whether they can put it in front of you. If they need a password, a licence, a support ticket or your memory of which folder means what, the archive is not finished — and the cheapest hour to fix that is while the subscription is still running, alongside the other things worth capturing before you cancel.

---

Verified against NARA, IRS, eCFR, IETF, Google, Notion and Microsoft documentation on 29 August 2026. Format guidance from NARA Appendix A: Tables of File Formats; regulation text from the eCFR issue of 36 CFR Part 1236 as of 27 August 2026; IRS wording from Rev. Proc. 97-22 and Publication 583 (Rev. December 2024); packaging conventions from RFC 8493. Two of those sources bind federal agencies and none of them binds a small company. They are quoted because they are the only detailed, dated, public answers to a question no vendor answers anywhere. Google, Notion and Microsoft are here on the same footing and no other: each one prints its own expiry clock, which is the only reason a clock can be quoted at all, and printing it counts in a vendor's favour rather than against it. Format profiles gain parts, and help centres get rewritten without a changelog. So the quoted sentence is the claim, and the date beside it marks the edge of what this page knows. Anything that has moved since belongs on the contact page, and the page returns with a new reading date.