Разделение обязанностей (SoD)

Разделение обязанностей (SoD): как защитить финансы, ускорить согласования и убрать «серые зоны» в учёте

Разделение обязанностей (SoD, Segregation of Duties) — это принцип внутреннего контроля, который не позволяет одному человеку замкнуть на себе весь цикл критичной операции: создать → согласовать → исполнить → отразить в учёте. На практике это означает простую вещь: если кто-то может и “придумать” платеж, и сам его “одобрить”, и сам же “отправить”, система уязвима — даже если у вас честная команда и высокий уровень доверия.

В управленческом контуре SoD нужен не “для галочки аудитору”, а чтобы финансовая дисциплина была воспроизводимой: процессы работали одинаково в разные смены, в разных филиалах и при смене сотрудников. Когда разделение обязанностей (SoD) внедрено правильно, вы получаете меньше ошибок, меньше конфликтов, больше прозрачности и быстрее закрываете период — потому что решения фиксируются в маршруте, а не в переписке.

Что именно защищает разделение обязанностей (SoD)

У любого процесса есть два слоя риска: ошибка (не туда отнесли, забыли приложить, перепутали реквизиты) и злоупотребление (обход лимитов, “подмена” контрагента, платеж без основания, корректировка выручки задним числом). Разделение обязанностей (SoD) снижает оба типа рисков, потому что включает “вторую пару глаз” там, где цена ошибки максимальна.

Важно: SoD — это не обязательно “четыре человека на одну кнопку”. Это набор правил, который зависит от размера бизнеса, зрелости процессов и критичности операций. Где-то достаточно разнести роли в системе и включить лимиты. Где-то нужен полноценный контроль мастер-данных (контрагентов, реквизитов, номенклатуры), отдельная роль казначейства и запрет на совмещение функций закрытия периода.

Где SoD ломается чаще всего

Почти всегда проблема начинается не с “плохих людей”, а с “удобных обходных путей”: срочные платежи, авралы, отсутствие формализованного бюджета, согласования в мессенджере, права доступа “на всякий случай”, общие логины, ручные правки справочников. В какой-то момент команда привыкает, что правила гибкие — и это становится нормой. Затем появляются необъяснимые перерасходы, разрывы в логике ответственности и спорные ситуации: “кто разрешил?”, “почему так классифицировано?”, “почему это прошло без подтверждения?”.

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

Типовые SoD-конфликты, которые реально приводят к потерям

Ниже — примеры, которые стоит искать в любой компании (и в отеле/ресторане/производстве/строительстве они встречаются одинаково часто):

• Один сотрудник может создать контрагента или изменить его реквизиты и затем сформировать платеж этому контрагенту.
• Один сотрудник может создать счет/заявку и сам же согласовать её “по лимитам”.
• Тот, кто формирует платежи, одновременно является подписантом в банке или имеет доступ к токену/ЭЦП.
• Сотрудник может подтвердить приемку (оказание услуги/поставку) и затем провести оплату без независимой проверки.
• Один человек может создавать и редактировать справочники (номенклатуру, ставки, статьи, проекты) и отражать операции в учете.
• Есть роль, которая может делать ручные проводки и одновременно закрывать период или “подчищать хвосты” без журнала причин.
• В продажах/кассе один и тот же пользователь может делать скидки/void/refund и корректировать основания (причины, комментарии) задним числом.
• В зарплате один человек может вести табель, рассчитывать начисления и выгружать реестр на выплату без независимой сверки.

Если вы узнали у себя хотя бы два пункта — разделение обязанностей (SoD) у вас либо не задано, либо задано “на бумаге”, но не закреплено в системе.

Базовая модель SoD: кто что делает в процессе

Удобно мыслить не “должностями”, а действиями и точками контроля. В любом денежном процессе есть как минимум роли: инициатор (кто создает потребность), контролер (кто проверяет основание и корректность), утверждающий (владелец бюджета/ЦФО), казначей (кто управляет платежным календарем и отправкой), учет (кто отражает и закрывает период), администратор данных (кто отвечает за справочники).

Ниже — упрощенный пример распределения ролей. Это не “единственно правильная” схема, но хороший ориентир для старта.

Суть разделения обязанностей (SoD) в том, что критические комбинации запрещены. Например, “админ реквизитов + платежи” почти всегда красный флаг. “Ручные проводки + закрытие периода” — тоже.

Как внедрить разделение обязанностей (SoD) без паралича процессов

Самая частая ошибка — пытаться “сразу сделать идеально” и наложить столько правил, что бизнес начнет искать обходы. SoD должен быть управляемым компромиссом: вначале закрываем самые дорогие риски (платежи, реквизиты, ручные корректировки), затем расширяем.

Практичный путь внедрения обычно выглядит так:

• Описать ключевые контуры: закупки и счета, платежи и казначейство, зарплата, выручка/скидки/возвраты, справочники и изменения данных, закрытие периода.
• Выявить “точки денег” и “точки данных”: где создается обязательство, где меняются реквизиты/цены/статьи, где операция становится необратимой (подпись, отправка в банк, закрытие периода).
• Сформировать матрицу конфликтов: какие сочетания прав недопустимы (и какие допустимы только при компенсирующих контролях).
• Встроить маршруты согласований по правилам: сумма, ЦФО, проект/объект, тип затрат, контрагент, срочность, наличие бюджета.
• Закрепить контроль мастер-данных: изменения реквизитов и ключевых справочников должны иметь отдельный процесс и аудит-след.
• Настроить мониторинг и регулярный пересмотр: права доступа “разъезжаются” со временем — это нормально, если вы их регулярно чистите и проверяете.

Обратите внимание: разделение обязанностей (SoD) — это не только про “кто согласовал”. Это про то, чтобы права доступа и логика маршрутов не позволяли пользователю сделать запрещенную комбинацию “по умолчанию”.

Если людей мало: как жить с SoD в небольших командах

В малом бизнесе неизбежно возникают совмещения. Но даже тогда разделение обязанностей (SoD) можно сделать работающим через “компенсирующие контроли”. Принцип простой: если вы не можете разнести роли по людям, разнесите их по уровням подтверждения, лимитам, банковским полномочиям и журналам изменений.

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

Почему SoD разваливается в “Excel + мессенджер” и как система должна помогать

Когда процесс живет в таблицах и чатах, правила почти невозможно удержать: согласования не воспроизводимы, причины решений теряются, файлы не совпадают, а роли смешиваются “по ситуации”. В результате контроль превращается в реактивную проверку постфактум: “почему так вышло?” вместо “не могло пройти иначе”.

Чтобы разделение обязанностей (SoD) было стабильным, инструмент должен поддерживать три вещи: RBAC (роли/права), workflow (маршруты согласования) и audit trail (аудит-след). Тогда SoD перестает быть “регламентом на бумаге” и становится частью ежедневной работы: кто инициировал, кто проверил, кто утвердил, на каком основании, в рамках какого бюджета и по каким лимитам.

Разделение обязанностей (SoD) в управленческом контуре: что важно именно для эффективности

Многие воспринимают SoD как “замедление”. На деле правильный SoD ускоряет работу, потому что убирает хаос и споры. Если правила понятны, маршруты автоматизированы, а лимиты прозрачны, люди тратят меньше времени на переписки и “пробивание” решений через знакомых.

Ключевой эффект для управленческого учета — восстановление ответственности: расходы утверждаются владельцем ЦФО, платежи попадают в календарь, перерасход виден до факта оплаты, а классификация и изменения фиксируются. Это особенно заметно при масштабировании: больше объектов, больше менеджеров, больше закупок — но тот же уровень контроля.

Мини-чек-лист: как быстро понять, что SoD нужно усиливать

• Можно ли одним аккаунтом создать/изменить контрагента и затем провести ему платеж?
• Есть ли операции, которые проходят без формального подтверждения (особенно срочные/ручные)?
• Можно ли делать ручные корректировки в учете без видимой причины и истории изменений?
• Разнесены ли права на “создать” и “утвердить” хотя бы для платежей, скидок/возвратов и master data?
• Есть ли понятные лимиты и маршруты согласований по сумме и ответственности (ЦФО/проект/объект)?
• Можно ли за 2 минуты ответить на вопрос “кто разрешил и почему” по любому спорному платежу?

Если на часть вопросов ответ “нет” или “не уверен” — разделение обязанностей (SoD) у вас, скорее всего, держится на личной дисциплине отдельных сотрудников, а не на системе.

SoD как “скелет” финансовой управляемости

Разделение обязанностей (SoD) — это про то, чтобы бизнес мог работать предсказуемо: без героизма, без ручных договоренностей и без опасных “универсальных” доступов. Начинать лучше всего с контуров, где риск максимален: платежи, реквизиты, ручные корректировки, скидки/возвраты, закрытие периода. Дальше — расширять правила и автоматизировать маршруты так, чтобы контроль был встроен в процесс, а не стоял рядом с ним.

Если вы хотите внедрить разделение обязанностей (SoD) в управленческом контуре так, чтобы это ускоряло работу, а не тормозило её, используйте программные продукты Финоко: в системе проще закрепить роли и права, настроить маршруты согласований по лимитам и ответственности, связать решения с бюджетом и сохранить аудит-след изменений. Это делает контроль устойчивым, прозрачным и масштабируемым — без “Excel-клея” и бесконечных согласований в чатах.