Случаи из практики №7. Исправления «вназад»

Как бороться с исправлениями задним числом?

В славные студенческие годы веселая компания часто подшучивала над известной песней Клячкина «Не гляди на зад, не гляди»… Действительно, стоит ли оглядываться назад? Прошел отчетный период, закрыт месяц, квартал. Сдана и представлена руководству вся финансовая отчетность – и PL и BS.

Как вдруг – «бац и вторая смена»… Бухгалтерия добавила/изменила/удалила проводку. Финансовый результат поплыл.  Теперь – расшифровка строки уже утвержденного отчета по 1С дает совсем другие суммы.

Знакомая ситуация?

Наверное, любой практикующий финансист набил себе кучу шишек, борясь с такими сюрпризами. Не помогает и закрытие периодов от исправления. Любой главный бухгалтер потребует оставить для себя лазейку. Особо ответственные сотрудники могут вносить исправления. И аргументы со стороны бухгалтерии железобетонные – при обнаружении ошибки ту же декларацию по НДС надо формировать заново и пересдавать.

Конечно, теме обеспечения принципа непрерывности можно посвятить серию материалов, вызвав ожесточенные споры как сторонников, так и противников железобетонного закрытия периода. Но это тот самый случай, когда лучше обойтись без теории и обзора различных подходов – просто привести реально работающий пример живого проекта.

В крупном холдинге управленческая отчетность формируется по технологии DataWarehouse. Ежедневно ночью все первичные операции выгружаются из первичных учетных систем (в данном проекте для одних юридических лиц это Axapta, для других – 1С, есть еще дополнительные источники первички) и преобразуются в учетные транзакции.

По науке данный процесс называется ETL, а учетные транзакции формируют так называемую шину данных – ESB. Вся управленческая отчетность строится по транзакциям ESB.

Технология обеспечения непрерывности PL

В регламент вносится процедура закрытия отчетного периода, включающая
— технологический контроль учетной информации и выполнения всех процедур
— утверждение основных ведомостей для четкого определения зон ответственности
— после окончания всех проверок и отмашки с мест (утверждения ведомостей)
все транзакции ESB фиксируются – сохраняются в отдельных таблицах,
независимых от источников первичных данных (Axapta, 1C).

При ежедневной загрузке транзакции, относящиеся к закрытым периодам удаляются из ESB (убираются в резерв) и заменяются на сохраненные проводки.

Такая технология гарантирует, что результат закрытых периодов зафиксирован – как бы не изменились проводки 1С задним числом в учет пойдут не новые хозяйственные операции, а утвержденные и сохраненные транзакции.

Контролируем «исправления вназад»

Периодически, в соответствии с регламентом или по потребности, формируется отчет по закрытым периодам. Сравниваются результаты текущих транзакций, убранных в резерв, и сохраненных – принятых к учету.

Если бухгалтерия что-то изменила «вназад», в ведомости возникнет разница. Детализируя это расхождение до даты, статьи учета ЦФО и документа, можно быстро выявить какие именно транзакции были изменены.

Определив причину изменений, финансист получает основание для принятия решений по каждому конкретному случаю.

Что делать с расхождениями?

Итак, мы четко выявили транзакции, приведшие к расхождению. Какое решение в каждом случае должен принять сотрудник финансовой службы. Поднимем конкретную статистику

Примерно 55 % расхождений является технической ошибкой. Бухгалтер может ошибиться в дате документа или случайно исправить аналитический признак, используемый для преобразования проводки в транзакцию управленческого учета. В таких случаях правильным является управленческая отчетность – утвержденные данные. В бухгалтерию направляется уведомление для исправления в 1С (или Axapta) первичной операции.

Около 25 % изменений не являются существенными для целей управленческого учета. Обычно подобные случаи связаны с перераспределением бухгалтерских регистров и/или субконто, приводящих к формальным расхождениям, некритичным для управленческой отчетности. Чаще всего финансисты мирятся с подобным «люфтом», отмечая эти расхождения как незначимые.

Порядка 15 % изменений заметно влияют на результаты общей отчетности. Но эти изменения не требуют переделки уже принятых отчетов. Расхождения отражаются ручными сторнировочными транзакциями первого числа открытого периода.

В особых случаях 5% выявленные расхождения связаны с принципиальными изменениями отчетности прошлых периодов. Эти крайние случае требуют переделки ранее сформированной и сданной отчетности. Снимается закрытие прошедшего периода. Проводится регламент проверки и формирования всей управленческой отчетности. Период закрывается заново.

Следует отметить, что в холдинге налажен контроль исполнения регламента. Необходимость разбираться с исправлениями задним числом возникает нечасто. Первый вариант – не чаще одного раза в месяц. Сторнировочные проводки приходится вводить пару раз в год. Полное переформирование пакета управленческой отчетности является исключительным случаем и поводом серьезного разбора полетов с финансовым директором.

Наверное, не всем подобная технология покажется идеальной. Финансистов возмутит возможность коррекции, хоть и в особых случаях, уже закрытых периодов. Кому-то может показаться процедура проверки и внесения изменений слишком сложной и требующей избыточных ресурсов.

Но, как бы то ни было, среди десятков учетных проектов данная технология наиболее адекватно решает поставленный в заголовке вопрос – оперативно и достаточно надежно контролирует исправления «вназад».

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *