Содержание
Как бороться с исправлениями задним числом?
В славные студенческие годы веселая компания часто подшучивала над известной песней Клячкина «Не гляди на зад, не гляди»… Действительно, стоит ли оглядываться назад? Прошел отчетный период, закрыт месяц, квартал. Сдана и представлена руководству вся финансовая отчетность – и PL и BS.
Как вдруг – «бац и вторая смена»… Бухгалтерия добавила/изменила/удалила проводку. Финансовый результат поплыл. Теперь – расшифровка строки уже утвержденного отчета по 1С дает совсем другие суммы.
Знакомая ситуация?
Наверное, любой практикующий финансист набил себе кучу шишек, борясь с такими сюрпризами. Не помогает и закрытие периодов от исправления. Любой главный бухгалтер потребует оставить для себя лазейку. Особо ответственные сотрудники могут вносить исправления. И аргументы со стороны бухгалтерии железобетонные – при обнаружении ошибки ту же декларацию по НДС надо формировать заново и пересдавать.
Конечно, теме обеспечения принципа непрерывности можно посвятить серию материалов, вызвав ожесточенные споры как сторонников, так и противников железобетонного закрытия периода. Но это тот самый случай, когда лучше обойтись без теории и обзора различных подходов – просто привести реально работающий пример живого проекта.
В крупном холдинге управленческая отчетность формируется по технологии DataWarehouse. Ежедневно ночью все первичные операции выгружаются из первичных учетных систем (в данном проекте для одних юридических лиц это Axapta, для других – 1С, есть еще дополнительные источники первички) и преобразуются в учетные транзакции.
По науке данный процесс называется ETL, а учетные транзакции формируют так называемую шину данных – ESB. Вся управленческая отчетность строится по транзакциям ESB.
Технология обеспечения непрерывности PL
В регламент вносится процедура закрытия отчетного периода, включающая
– технологический контроль учетной информации и выполнения всех процедур
– утверждение основных ведомостей для четкого определения зон ответственности
– после окончания всех проверок и отмашки с мест (утверждения ведомостей)
все транзакции ESB фиксируются – сохраняются в отдельных таблицах,
независимых от источников первичных данных (Axapta, 1C).
При ежедневной загрузке транзакции, относящиеся к закрытым периодам удаляются из ESB (убираются в резерв) и заменяются на сохраненные проводки.
Такая технология гарантирует, что результат закрытых периодов зафиксирован – как бы не изменились проводки 1С задним числом в учет пойдут не новые хозяйственные операции, а утвержденные и сохраненные транзакции.
Контролируем «исправления вназад»
Периодически, в соответствии с регламентом или по потребности, формируется отчет по закрытым периодам. Сравниваются результаты текущих транзакций, убранных в резерв, и сохраненных – принятых к учету.
Если бухгалтерия что-то изменила «вназад», в ведомости возникнет разница. Детализируя это расхождение до даты, статьи учета ЦФО и документа, можно быстро выявить какие именно транзакции были изменены.
Определив причину изменений, финансист получает основание для принятия решений по каждому конкретному случаю.
Что делать с расхождениями?
Итак, мы четко выявили транзакции, приведшие к расхождению. Какое решение в каждом случае должен принять сотрудник финансовой службы. Поднимем конкретную статистику
Примерно 55 % расхождений является технической ошибкой. Бухгалтер может ошибиться в дате документа или случайно исправить аналитический признак, используемый для преобразования проводки в транзакцию управленческого учета. В таких случаях правильным является управленческая отчетность – утвержденные данные. В бухгалтерию направляется уведомление для исправления в 1С (или Axapta) первичной операции.
Около 25 % изменений не являются существенными для целей управленческого учета. Обычно подобные случаи связаны с перераспределением бухгалтерских регистров и/или субконто, приводящих к формальным расхождениям, некритичным для управленческой отчетности. Чаще всего финансисты мирятся с подобным «люфтом», отмечая эти расхождения как незначимые.
Порядка 15 % изменений заметно влияют на результаты общей отчетности. Но эти изменения не требуют переделки уже принятых отчетов. Расхождения отражаются ручными сторнировочными транзакциями первого числа открытого периода.
В особых случаях 5% выявленные расхождения связаны с принципиальными изменениями отчетности прошлых периодов. Эти крайние случае требуют переделки ранее сформированной и сданной отчетности. Снимается закрытие прошедшего периода. Проводится регламент проверки и формирования всей управленческой отчетности. Период закрывается заново.
Следует отметить, что в холдинге налажен контроль исполнения регламента. Необходимость разбираться с исправлениями задним числом возникает нечасто. Первый вариант – не чаще одного раза в месяц. Сторнировочные проводки приходится вводить пару раз в год. Полное переформирование пакета управленческой отчетности является исключительным случаем и поводом серьезного разбора полетов с финансовым директором.
Наверное, не всем подобная технология покажется идеальной. Финансистов возмутит возможность коррекции, хоть и в особых случаях, уже закрытых периодов. Кому-то может показаться процедура проверки и внесения изменений слишком сложной и требующей избыточных ресурсов.
Но, как бы то ни было, среди десятков учетных проектов данная технология наиболее адекватно решает поставленный в заголовке вопрос – оперативно и достаточно надежно контролирует исправления «вназад».
