Автоматическая сверка банковской выписки с заявками на оплату

Заявка на оплату отвечает на вопрос, что компания собиралась заплатить, кому, когда и по какой статье. Банковская выписка показывает фактическое движение по счёту. Между этими событиями находятся согласование, подготовка платёжного поручения, подпись, исполнение банком, комиссия, возврат и возможное исправление реквизитов. Ручная сверка соединяет их по назначению платежа и памяти сотрудников; автоматическая использует устойчивые идентификаторы и формальные правила.

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

Какие документы участвуют в сверке

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

Заявка на оплату

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

Платёжное поручение

Поручение может формироваться в 1С, казначейской системе или интернет-банке. Оно получает собственный номер и банковский статус. Одна заявка иногда создаёт несколько поручений, например при частичной оплате. Бывает и обратная связь: один платёж покрывает несколько согласованных заявок. Модель должна поддерживать обе ситуации.

Операция банковской выписки

Выписка содержит фактическую дату, сумму, направление, реквизиты сторон, назначение и идентификатор операции банка. При работе через API учитывают постраничную выдачу, часовой пояс, доступный период истории и возможное изменение статуса. Документация T‑Bank, например, описывает получение операций за период и курсор для следующей порции данных.

Способы получать выписку

Прямой обмен с банком

API банка или технология 1С:ДиректБанк позволяют получать операции без ручной загрузки файла. У такого подключения есть регламент доступа, набор поддерживаемых счетов, лимиты и правила обновления токенов. Интеграция должна показывать дату последнего успешного запроса и полноту прочитанного периода.

Файл из клиент-банка

Файловый обмен остаётся рабочим вариантом, когда API отсутствует или подключение ещё согласуется. Система принимает файл, проверяет формат, счёт и период, исключает повторную загрузку и сохраняет исходный экземпляр. Имя файла не подходит как защита от дублей: надёжнее считать хеш содержимого и уникальность банковских операций.

Несколько банков и юридических лиц

Каждый источник приводит операции к общей модели, сохраняя исходные поля. Счёт однозначно связывается с юридическим лицом и валютой. Внутренние переводы между своими счетами отмечают парой связанных движений, чтобы оборот не попадал в расходы и поступления дважды.

Как строятся правила сопоставления

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

Точные совпадения

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

Допустимые отклонения

Часть расхождений объясняется процессом: банковская комиссия, оплата несколькими траншами, курсовая разница, дата следующего рабочего дня. Для них задают прозрачные правила и пороги. Правило содержит основание и владельца; скрытая корректировка суммы в отчёте затрудняет последующую проверку.

Неоднозначные совпадения

Когда ID отсутствует, система может подобрать кандидатов по ИНН, сумме, номеру счёта и тексту назначения. Автоматическое закрытие разрешают лишь при одном уверенном кандидате. Несколько вариантов попадают в очередь ручного выбора, а принятое решение сохраняется вместе с автором.

Что происходит после найденного совпадения

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

1. Интеграция получает новую порцию выписки и нормализует поля.
2. Система проверяет уникальность операции банка.
3. Правила ищут точную связь с заявкой или платёжным поручением.
4. Совпавшая заявка закрывается с фактическими реквизитами.
5. Неоднозначная операция получает код причины и ответственного.
6. Контрольный отчёт сравнивает начальный и конечный остаток с банком.

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

Очередь исключений превращает сверку в рабочий процесс

Исключение должно объяснять, что именно требует внимания. Формулировка «не совпало» заставляет сотрудника заново исследовать весь платёж. Полезнее коды: операция без заявки, сумма выше согласованной, изменились реквизиты, найдено несколько заявок, платёж возвращён, выписка неполная, внутренний перевод без пары.

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

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

Доступ к выпискам и платёжным данным выдаётся сервисной учётной записи с минимально необходимыми правами. Секреты хранятся вне исходного кода и журналов. В логах достаточно технического ID, времени, статуса и кода ошибки; полные реквизиты и назначения платежей выводят только пользователям с соответствующей ролью.

Мониторинг контролирует свежесть каждого счёта, непрерывность периода и число операций. Если загрузка остановилась, отчёт показывает последнюю успешную дату, а не пустой день. Итог за период проверяется по остаткам: начальный остаток плюс поступления минус списания должен дать конечный остаток с учётом формата банка.

Как проверить внедрение

Для приёмки готовят обезличенный набор операций: точное совпадение, частичная оплата, два платежа по одной заявке, один платёж по нескольким заявкам, комиссия, внутренний перевод, возврат, дубль файла и неизвестная операция. Ожидаемый результат фиксируют заранее.

• повторная загрузка того же периода не меняет количество операций и связей;
• все страницы API прочитаны, курсор и границы периода сохранены;
• остатки и обороты совпадают с контрольной выпиской;
• согласованная сумма не изменяется без нового решения;
• спорные строки имеют причину, владельца и историю действий;
• остановка источника создаёт заметное предупреждение;
• роли ограничивают просмотр счетов и банковских реквизитов.

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

Что подготовить для проекта

Понадобятся перечень банков и счетов, образец выписки, форма заявки, статусы согласования, правила частичных платежей, список внутренних счетов и несколько примеров спорных операций. По ним определяется способ подключения и объём правил. Если прямого API пока нет, автоматическую логику можно отладить на контролируемой файловой загрузке, а затем заменить источник без изменения модели сверки.

Удобный итог для финансовой команды — список исполненных заявок с фактом банка, очередь понятных исключений и отчёт о свежести данных. Руководитель видит, какая часть платежей прошла по согласованному процессу и где возникло отклонение.

Источники

1. T‑Bank Dev Portal — счета и выписки.
2. T‑Bank Dev Portal — метод получения выписки.
3. 1С — API взаимодействия с банком по технологии DirectBank.
4. 1С:Предприятие — механизмы интеграции.
5. Банк России — открытые API финансового рынка.
6. Pyrus — форма и маршрут согласования счёта на оплату.