Привет, Хабр! Меня зовут Андрей Бирюков. Я эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу книги. Сбор первичных документов из 1С, SAP и ERP из разных юридических лиц традиционно является серьезной головной болью бухгалтерии.
В этой статье мы поговорим о том, как с помощью low-code платформ можно автоматизировать данный процесс и сформируем гайд по построению подобного пайплайна.
Две реальности одной отчетности
Типичная история из жизни. Финансовый директор холдинга из 12 юрлиц просит консолидированный баланс по МСФО на утро следующего дня. В каждой «дочке» — своя версия 1С или SAP. Три компании работают в Legacy-системах без API. Бухгалтеры по очереди выгружают ОСВ в Excel, сводят их в одну «сводную» книгу, правят формулы, ищут расхождения в курсах и внутригрупповых оборотах.
К полуночи обнаруживается ошибка в элиминировании инвестиций. Конечно, можно во всем обвинить бухгалтеров, сводивших отчетность, но на самом деле это не проблема квалификации, а архитектурный предел ручной консолидации.

И здесь для решения проблемы нам необходимо перестать просить бухгалтера быть супер-пользователем 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С (сервер, база, логин). Этот блок отвечает за чтение данных прямо из учетной системы в память 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-инженером, который управляет логикой финансовых данных.

Перед тем как превращать бухгалтера в data-инженера, полезно разобраться и в соседних задачах: как выстраивать финансовые модели, которым можно доверять, и как убирать из них ручные ошибки. Для этого подойдут бесплатные уроки ниже. Они пройдут в формате живого общения с экспертами: можно посмотреть, как решаются практические задачи, задать вопросы и оценить подход к обучению.
3 июня в 20:00. «От хаоса к контролю: как построить финансовую модель, которой можно верить». Записаться
17 июня в 20:00. «Как убрать „человеческий фактор“ из финансовых моделей: от расчёта NPV до сложных систем оплаты труда». Записаться
Полный список бесплатных уроков июня смотрите в дайджесте.