Превращаем бухгалтера группы компаний в data-инженера

Меня зовут Андрей Бирюков. Я эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу книги. Сбор первичных документов из 1С, SAP и ERP из разных юридических лиц традиционно является серьезной головной болью ^[1] бухгалтерии.

В этой статье мы поговорим о том, как с помощью low-code платформ можно автоматизировать ^[2] данный процесс и сформируем гайд по построению подобного пайплайна.

Две реальности одной отчетности

Типичная история из жизни. Финансовый директор холдинга из 12 юрлиц просит консолидированный баланс по МСФО на утро следующего дня. В каждой «дочке» — своя версия 1С или SAP. Три компании работают в Legacy-системах без API. Бухгалтеры по очереди выгружают ОСВ в Excel, сводят их в одну «сводную» книгу, правят формулы, ищут расхождения в курсах и внутригрупповых оборотах.

К полуночи обнаруживается ошибка ^[3] в элиминировании инвестиций. Конечно, можно во всем обвинить бухгалтеров, сводивших отчетность, но на самом деле это не проблема квалификации, а архитектурный предел ручной консолидации.

И здесь для решения проблемы нам необходимо перестать просить бухгалтера быть супер-пользователем Excel и начать превращать его в data-инженера на low-code инструментах. Да, звучит немного странно, но на самом деле здесь нет ничего особо сложного.

Проблема: учетные системы не дружат, а бизнес требует прозрачности

Классический подход к автоматизации консолидации предполагает либо покупку дорогой EPM-системы (Oracle Hyperion, SAP BPC), либо точечную разработку костылей скриптов на Python или SQL. При этом, оба варианта не являются оптимальными и создают определенные барьеры.

Так, для финансиста возникает проблема взаимодействия: бухгалтер не пишет код, разработчик не знает ПБУ/МСФО. Кроме того, любое изменение требует много времени, например добавление нового аналитического разреза означает переписывание интеграции, что может занять несколько месяцев. В итоге, мы можем получить черный ящик, та как при расхождении данных невозможно понять, на каком шаге произошла ошибка.

Здесь нам на помощь приходят Low-code ETL-платформы (Apache NiFi, Airbyte, отечественные «потоковые конструкторы» вроде Visiology ETL или Loginom). Они предоставляют визуальный интерфейс сборки пайплайнов, где бухгалтер сам выстраивает маршрут данных — от оборотно-сальдовой ведомости до готового пакета МСФО.

Далее мы рассмотрим основные шаги построения пайплайна для формирования отчетности.

Этап 1. Аудит и подготовка данных

Шаг 1.1. Составьте реестр источников данных

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

Что указываем по каждому юрлицу:

• Название и ИНН

• Тип учетной системы (1С:Бухгалтерия 8, SAP Business One, Oracle, самописная ERP)

• Есть ли у этой системы API, ODBC-драйвер или возможность выгрузки в CSV/Excel

• План счетов (РСБУ, МСФО, управленческий, налоговый).

• Функциональная валюта (рубли, евро, тенге, доллары).

Промежуточный результат: 

Файл-реестр из 5–20 строк (по числу юрлиц), где каждое имеет четкий «паспорт» для подключения.

Шаг 1.2. Спроектируйте единую модель консолидации

Здесь мы на бумаге (или в документе) описываем, как именно должны выглядеть итоговые отчеты после автоматизации. Так как ETL-пайплайн не может работать без целевой модели данных, бухгалтер должен заранее решить, в какие статьи МСФО превратятся счета 60.01, 62.02 и 91.02 из разных систем. Это предотвращает хаос и двойное толкование цифр.

Что фиксируем:

• Унифицированный план статей МСФО (пример: Выручка, Себестоимость, Административные расходы, Кредиторская задолженность, Займы полученные).

• Список счетов из источников и их маппинг на эти статьи.

• Перечень внутригрупповых оборотов, которые надо исключить: взаимные продажи (выручка / себестоимость), займы, проценты, дивиденды.

• Правила пересчета валют: по какому курсу (на дату операции или на дату отчета), какой источник курсов (ЦБ РФ или внутренний справочник).

Промежуточный результат: 

Техническое задание на 2–3 страницы, которое поймет и бухгалтер, и человек, настраивающий ETL (часто это один и тот же человек).

Шаг 1.3. Выберите low-code ETL-платформу

А на этом шаге нам необходимо определиться с low-code системой, которую мы хотим использовать. Для этого, мы сравниваем 2–3 доступных инструмента по критериям для финансиста. Классические ETL (на Python или Talend) требуют навыков разработчика. Low-code платформы дают визуальный интерфейс, где бухгалтер сам перетаскивает блоки. Но важно понимать, что неправильный выбор приведет к тому, что вы все равно наймете программиста.

Критерии выбора:

• Визуальный конструктор без SQL – бухгалтер строит граф из блоков «Соединение», «Фильтр», «Калькулятор», а не пишет JOIN и WHERE.

• Готовые коннекторы к 1С и SAP – иначе вы потратите недели на настройку доступа через ODBC.

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

• Версионность – можно вернуться к правилу элиминирования, которое работало в прошлом квартале, и сравнить с текущим.

• Лицензия с помесячной оплатой – для пилота не покупаем годовую подписку.

Промежуточный результат: 

Выбран инструмент (например, Loginom или Visiology ETL) с установленной пробной версией.

Этап 2. Сборка ETL-пайплайна

На этом этапе все действия выполняются бухгалтером-аналитиком в визуальном интерфейсе выбранной платформы и никакой код не пишется.

Шаг 2.1. Извлечение данных (Extract) из первой учетной системы

Перетаскиваем на холст блок «Коннектор» и указываем параметры подключения к 1С (сервер, база, логин). Этот блок отвечает за чтение данных прямо из учетной системы в память ^[4] ETL-платформы. Бухгалтер не выгружает в Excel вручную – система делает это автоматически по расписанию.

Что настраиваем:

• Выбираем тип объектов: «Обороты по счетам (дебет/кредит) за период», «Сальдо на начало и конец периода», «Аналитика по контрагентам и договорам».

• Указываем период (например, текущий месяц или последний закрытый квартал).

Результат шага: 

Сырые данные из первой базы (скажем, 10 тысяч строк оборотов) появляются внутри пайплайна и готовы к обработке.

Шаг 2.2. Унификация плана счетов (первая трансформация)

На этом шаге мы добавляем блок «Справочник соответствий» (Map/Transform) и связываем исходные счета из 1С с целевыми статьями МСФО. В разных системах один и тот же экономический смысл зашит в разные номера счетов. В 1С счет 60.01 – «Расчеты с поставщиками в рублях», в SAP это может быть 2000. Без унификации вы получите в отчете две разные строки по одному и тому же виду задолженности.

Пример настройки:

• 60.01 (1С) → «Кредиторская задолженность поставщикам» (МСФО)

• 62.01 (1С) → «Дебиторская задолженность покупателей» (МСФО)

• 90.01.1 (1С) → «Выручка от реализации» (МСФО)

Результат шага: 

Все проводки из источника размечены метками единого справочника. Теперь их можно складывать с данными из SAP или 1С.

Шаг 2.3. Автоматический валютный пересчет (вторая трансформация)

Теперь мы вставляем блок «Калькулятор» и создаем правило: Сумма в рублях = Сумма в валюте × Курс на дату операции. В группе компаний часто есть юрлица с функциональной валютой, отличной от валюты консолидированной отчетности (например, казахстанское юрлицо ведет учет в тенге, а головная компания отчитывается в рублях). Без автоматического пересчета бухгалтеру пришлось бы вручную умножать тысячи строк.

Что указываем:

• Источник курсов (обычно API ЦБ РФ или загруженный файл курсов за месяц).

• Правило округления (до двух знаков после запятой).

• Дату, на которую берется курс (дата проводки, а не дата отчета – это важно для МСФО).

Результат шага: 

Все суммы приведены к единой валюте консолидации. Ни одного ручного умножения.

Шаг 2.4. Элиминирование внутригрупповых оборотов (третья трансформация)

Здесь мы добавляем блок «Фильтр с исключениями» или «Conditional split» и загружаем список ИНН всех юрлиц группы. Создаем правило: если контрагент в проводке принадлежит этому списку – исключить такую проводку из консолидированного отчета.

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

Какие счета обрабатываем обязательно:

• 90 «Выручка» (исключаем продажи внутри группы)

• 60 «Закупки» / 20 «Основное производство» (исключаем себестоимость внутригрупповых покупок)

• 66/67 «Займы» (исключаем займы между своими юрлицами)

• 76 «Проценты по займам» (исключаем начисленные проценты)

Результат шага: 

В итоговом отчете остаются только операции с внешними контрагентами. Сальдо внутригрупповых расчетов обнулено.

Шаг 2.5. Настройка автоматического контроля (проверка перед загрузкой)

Настройка нашего пайплайна близится к завершению. Нам остается добавить блок «Ассерт» (проверка условия) и задать правило: Сумма всех дебетовых оборотов по консолидированным данным должна равняться сумме всех кредитовых оборотов с точностью до 0,01 рубля.

После всех трансформаций (маппинг, валютный пересчет, элиминирование) легко случайно нарушить баланс. Например, исключить выручку, но забыть исключить себестоимость. Блок-проверка остановит пайплайн и выдаст ошибку до того, как неверный отчет попадет к руководству.

Дополнительные проверки (по желанию):

• «Сальдо по расчетам с каждым контрагентом группы равно нулю» (проверяет полноту элиминирования).

• «Сумма амортизации за месяц положительная» (ловит ошибки переноса данных). 

Результат шага: 

Пайплан либо проходит проверку и идет к загрузке, либо останавливается с понятным сообщением: «Нарушен баланс по счету 62 после элиминирования».

Шаг 2.6. Загрузка (Load) в консолидационную модель или хранилище

В заключении мы добавляем блок «Выгрузка» и указываем целевую систему – это может быть:

• Отдельная таблица в финансовом хранилище (например, PostgreSQL).

• Готовая форма отчета в той же low-code платформе.

• Выгрузка в Excel-файл с заранее сверстанными листами «Баланс», «ОПиУ», «ДДС».

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

Что настраиваем:

• Режим загрузки: «полная перезапись» (каждый месяц целиком) или «добавление новых строк».

• Расписание: запускать пайплайн каждое первое число месяца в 3:00 ночи.

Результат шага: 

Готовый консолидированный пакет МСФО формируется автоматически, без участия человека.

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

Этап 3. Эксплуатация и поддержка

Шаг 3.1. Обучите одного бухгалтера на роль «смотрящего за пайплайном»

Теперь нам нужно назначить ответственного, который может добавить новое юрлицо в маппинг и изменить курс валюты, если ЦБ изменил правила. 

Наш Low-code ETL не требует поддержки программиста только в том случае, если в финансовом отделе есть человек с правами редактировать пайплайн. Без этого любые изменения (добавили новую ERP «дочки») снова потребуют вмешательство ИТ. 

Шаг 3.2. Ведите журнал изменений правил трансформации

Внутри платформы (или в отдельном документе) записываем каждое изменение: дата, кто изменил, какое правило (например, «добавили элиминирование процентов по займам между юрлицами А и Б»).

Когда через полгода возникнет расхождение в отчете, вы сможете отследить, какое именно изменение привело к ошибке. Без журнала вы будете перебирать все правила наугад.

Шаг 3.3. Настройте алерты о сбоях

В настройках пайплайна указываем e-mail или Telegram-бот, куда будут приходить сообщения: «Ошибка: не удалось подключиться к 1С юрлица 3. Проверьте сервер».

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

Что получили в итоге

В заключении давайте посмотрим, что вы должны были сделать, чтобы внедрение пайплайна можно было считать успешным.

В начале мы составили реестр юрлиц с типами учетных систем, затем спроектировали единую модель статей МСФО и правила элиминирования. Определились с low-code ETL-платформой с визуальным конструктором и настроили блоки: Extract, маппинг счетов, валютный пересчет, элиминирование, проверка баланса, Load.

Ваш пайплайн запускается по расписанию без участия бухгалтера. Также назначен ответственный за поддержку из числа финансистов и настроены алерты об ошибках.

После этого бухгалтер перестает быть «копипастером» в Excel и становится data-инженером, который управляет логикой ^[5] финансовых данных.

Перед тем как превращать бухгалтера в data-инженера, полезно разобраться и в соседних задачах: как выстраивать финансовые модели, которым можно доверять, и как убирать из них ручные ошибки. Для этого подойдут бесплатные уроки ниже. Они пройдут в формате живого общения с экспертами: можно посмотреть, как решаются практические задачи, задать вопросы и оценить подход к обучению ^[6].

• 3 июня в 20:00. «От хаоса к контролю: как построить финансовую модель, которой можно верить». Записаться ^[7]

• 17 июня в 20:00. «Как убрать „человеческий фактор“ из финансовых моделей: от расчёта NPV до сложных систем оплаты труда». Записаться ^[8]

Полный список бесплатных уроков июня смотрите в дайджесте. ^[9]