Хранение бухгалтерских данных: сроки и требования

MAATRIX

Бухгалтер говорит «эти документы надо хранить N лет», а вы отвечаете за сервер, на котором крутится 1С или другая учётная система, и должны как-то это N лет обеспечить технически. Разберём, почему нельзя полагаться на одно универсальное правило для всех документов, и что конкретно нужно сделать с инфраструктурой, чтобы данные дожили до конца срока хранения в читаемом виде. Сразу оговорка: это обзорный материал про технические следствия требований к хранению, а не юридическая консультация. Точные минимальные сроки хранения для каждой категории документов, применимые к вашей организации, форме налогообложения и юрисдикции, нужно уточнять у бухгалтера или аудитора — законодательство меняется, и в разных ситуациях (проверка, банкротство, судебный спор) сроки могут отличаться от общих. Мы не приводим здесь конкретных цифр «хранить N лет» именно поэтому: с такими деталями легко ошибиться, а ошибка в этой теме стоит дороже, чем в большинстве технических вопросов.

Почему нет единого срока хранения

Первая ошибка, которую делают технические специалисты (да и не только они) — искать «один срок хранения бухгалтерских данных», чтобы настроить по нему единую политику ретенции в бэкапах и в учётной системе. Такого единого срока не существует, потому что закон по-разному регулирует разные категории документов:

• Первичные учётные документы — накладные, акты, счета-фактуры, кассовые документы. Это основа для проводок и налоговой базы.
• Регистры бухгалтерского учёта и бухгалтерская (финансовая) отчётность — оборотно-сальдовые ведомости, книги учёта, годовые балансы.
• Налоговая отчётность и документы, подтверждающие исчисление налогов — декларации, документы для налоговых вычетов, документы, обосновывающие убытки прошлых периодов (если убытки переносятся на будущее, документы по ним нередко нужно хранить дольше стандартного срока).
• Кадровые документы, связанные с расчётом зарплаты — расчётные листки, документы о трудовом стаже, кадровые приказы. У них исторически действуют отдельные, часто более длинные сроки хранения, не совпадающие со сроками для первичной «бухгалтерки».

Для каждой категории законодательство устанавливает определённые минимальные сроки хранения, которые нужно уточнять применительно к конкретному виду документа — и делать это лучше не по памяти или по статье в интернете (включая эту), а по актуальной консультации с бухгалтером, который следит за изменениями норм. Практический вывод для технической стороны: если вы настраиваете политику хранения в 1С, в архиве документов или в бэкап-системе, не ставьте «одно число лет для всего». Разделите данные по категориям хотя бы логически (первичка / отчётность / кадры-зарплата) и для каждой заведите свой срок, полученный от бухгалтера, а не выведенный технарём самостоятельно.

Что означает «хранить» применительно к серверу

Когда бухгалтер говорит «документы нужно хранить N лет», для инфраструктуры это разворачивается в три разных технических требования, и их легко перепутать или выполнить только частично:

1. Данные физически не должны пропасть — ни из-за отказа диска, ни из-за случайного удаления, ни из-за атаки шифровальщика. Это про надёжность хранения и бэкапы.
2. Данные должны оставаться доступными и читаемыми — не просто «файл лежит на диске», а его можно открыть и получить из него смысл, спустя годы, даже если формат файла или версия программы за это время сменились.
3. Данные не должны быть удалены раньше срока — ни вручную по ошибке, ни автоматикой (скриптом очистки, политикой ретенции в бэкап-системе, автоматическим архивированием), которая не в курсе, что для этой категории данных действует более длинный минимальный срок хранения.

Дальше — по каждому пункту отдельно, потому что типичные грабли для них разные.

Сохранность: резервное копирование бухгалтерских данных — это отдельная категория

Учётная система (1С, SQL-база бухгалтерского софта, файловый архив первички со сканами) обычно крутится на том же сервере, что и остальная инфраструктура компании. Соблазн — включить её в общую политику бэкапов «по умолчанию»: например, хранить снапшоты 30 или 90 дней и перезаписывать старые.

Для бухгалтерских данных это не годится. Если налоговая проверка приходит за периоды 3-летней (или иной) давности, а ваша ротация бэкапов держит глубину в 90 дней, то по сути у вас нет резервной копии данных за проверяемый период — есть только единственная живая копия в проде, и если она повреждена, восстанавливать нечего. Мы разбирали эту проблему шире в статье про экономию на бэкапах и её реальную цену — там она рассмотрена с общей технической стороны; здесь важно, что для бухгалтерских данных ошибка с бэкапами создаёт не только техническую, но и юридическую проблему: отсутствие первичных документов или регистров учёта за период, который по закону ещё должен храниться, — это не «жалко, восстановим из другого места», а потенциальные претензии при проверке.

Практические выводы для настройки:

• Заведите для бухгалтерской базы/архива отдельную политику бэкапов с ретенцией, которая покрывает весь требуемый срок хранения для соответствующей категории документов, а не общий дефолт инфраструктуры.
• Проверяйте бэкапы восстановлением, а не только фактом, что задача бэкапа отработала «успешно» в логе. Битый архив, который никто не пытался развернуть, обнаруживается обычно в худший момент — во время проверки.
• Держите хотя бы одну копию бэкапа физически в другом месте (другой сервер, другой дата-центр, объектное хранилище), а не только на соседнем диске той же машины — риски one point of failure (отказ RAID-контроллера, шифровальщик, ошибка администратора) касаются в равной степени и продовых данных, и бэкапов, если они рядом.
• Если бухгалтерская база большая (годы истории, вложения-сканы), учитывайте это в расчёте места и в стоимости хранения на годы вперёд — ориентировочно можно прикинуть через статью про стоимость хранения терабайта на длительный срок, но конкретные цифры под ваш объём данных и выбранную схему бэкапов (полные/инкрементальные, сколько копий) лучше посчитать отдельно — они сильно зависят от реального объёма и глубины хранения.

Доступность и читаемость: риск устаревания формата важнее, чем кажется

Второй пункт — то, что часто упускают, потому что кажется абстрактным, пока не столкнёшься лично. Резервная копия базы 1С восьмилетней давности «есть», файл физически цел — но:

• Формат базы данных мог смениться между версиями программы, и старый архив не открывается текущей версией без конвертации.
• Лицензия на старую версию софта, под которой архив создавался, может быть недоступна (программа снята с продажи, изменилась схема лицензирования).
• Сканы первичных документов в устаревших форматах изображений/контейнеров могут потребовать специфичного ПО для просмотра, которого через несколько лет уже нет под рукой.
• Экспорт в текстовый/архивный формат (например, выгрузка в XML для обмена данными бухучёта) в момент создания архива был актуальной версией схемы, а через несколько лет схема тоже могла измениться.

Технически это решается не разово, а процессом:

• При смене учётной системы или крупном обновлении версии — не просто «выгрузить и забыть» старые данные, а заранее продумать миграцию архивных данных в формат, который останется читаемым и после смены системы (либо мигрировать сами данные, либо параллельно с миграцией сохранить рабочую копию старой системы специально для чтения архива).
• Хранить рядом с самими данными документацию о том, чем и как их открыть (версия ПО, формат, при необходимости — экспортный дамп в универсальном формате вроде CSV/XML в дополнение к нативному формату базы).
• Периодически (не после каждого обновления, но хотя бы раз в несколько лет) проверять, что архив за прошлые периоды действительно открывается текущими средствами, а не только «лежит на диске».

Это тот случай, где недорогая профилактика (лишний экспорт в нейтральный формат, тестовое открытие архива раз в год) на порядок дешевле, чем разбираться постфактум, чем открыть базу пятилетней давности, когда документы срочно нужны для проверки.

Защита от преждевременного удаления: явная и неявная

Третий риск — самый обидный, потому что рукотворный. Данные удаляются раньше положенного срока не потому что кто-то сознательно решил их не хранить, а потому что автоматика об этом требовании не знала:

• Скрипт очистки старых логов и временных файлов на сервере, написанный «для порядка», случайно захватывает и каталог с архивными выгрузками бухгалтерии, потому что тот лежит рядом и подходит под маску find /data -mtime +365 -delete.
• Политика ретенции в бэкап-системе или в объектном хранилище с автоматическим удалением по возрасту (S3 lifecycle-правило, аналог в другом хранилище) настроена по общему шаблону инфраструктуры и не учитывает, что бухгалтерский бакет должен жить дольше.
• Сотрудник, наводящий порядок на файловом сервере, удаляет «старую и явно не нужную» папку с архивом за давние периоды, не подозревая о требовании хранения.
• Смена сервера или миграция на новую инфраструктуру, при которой «неиспользуемые», по мнению того, кто переносит данные, старые файлы решили не переносить, чтобы не тащить лишнее.

Что делает эту категорию рисков управляемой:

• Физически или логически отделить каталоги/базы с бухгалтерскими данными от общего дерева, которое чистят автоматические скрипты — например, отдельный раздел, отдельный бакет, явный список исключений в любом скрипте очистки.
• В любом скрипте автоматической очистки старых данных явно исключать пути, где лежат бухгалтерские архивы, и явно комментировать в коде скрипта, почему они исключены — чтобы следующий администратор не «улучшил» скрипт, убрав исключение.
• При настройке lifecycle-правил в объектном хранилище или ретенции в бэкап-системе — сверять срок с требованием для конкретной категории данных, а не с дефолтом, который подходит для остальной инфраструктуры.
• Держать документально (хотя бы в внутреннем регламенте) список: какие данные, где физически лежат, какой минимальный срок хранения для них действует по консультации бухгалтера, кто отвечает за то, чтобы их не удалили раньше срока.

Организационная сторона: кто отвечает за срок хранения

Техническая настройка бэкапов и защита от удаления решают проблему только если кто-то заранее сказал, на какой срок настраивать. Разумное разделение ответственности:

Если этого разделения нет и каждый считает, что сроком хранения «занимается кто-то другой», типичный итог — либо переплата за бесконечное хранение всего подряд «на всякий случай», либо реальный риск не найти нужный документ при проверке. Прозрачный список категорий данных и сроков, согласованный один раз и обновляемый по мере изменения законодательства, снимает оба риска.

Частые вопросы