Подрядчики и акты выполненных работ: как ИИ убирает ручную сверку

# Подрядчики и акты выполненных работ: как ИИ убирает ручную сверку

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

Почему сверка актов растягивается на недели

Главная причина не в лени, а в том, что у каждого этапа свой ответственный и свой носитель. Смета живёт в почте, объёмы фиксирует прораб в блокноте, акт присылает подрядчик в мессенджер, счёт приходит отдельно. Когда всё это нужно свести, данные не совпадают, и начинается переписка.

Вторая причина это расхождение по объёмам. Подрядчик закрывает больше, чем принято на объекте, или меньше, чем заказано. Если приёмка не фиксируется на месте, спор решается уже по бумагам, когда доказать что-то сложно.

Смета, лимиты и заявки на работы

Порядок начинается с заявки. Не с телефонного звонка, а с фиксированного запроса: объект, вид работ, объём, срок, ставка. Заявка попадает в общий список, и по ней видно, кто отвечает и на какой стадии она находится.

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

по объекту заведён бюджет и лимит по видам работ;

заявка ссылается на смету и не превышает лимит без отдельного согласования;

каждая позиция имеет объём в понятных единицах: метры, часы, штуки;

изменение объёмов проходит через правку заявки, а не задним числом.

Когда лимит и факт рядом, вопрос "почему в акте больше" решается на месте, а не в переписке через месяц.

Приёмка работ на объекте

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

фото или отметка по каждой выполненной позиции;

фактический объём и отклонение от сметы;

замечания, которые нужно устранить до закрытия;

подпись или подтверждение ответственного на объекте.

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

Акты, счета и сверка

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

Отдельно стоит держать календарь закрытия. По каждому подрядчику видно: работы приняты, акт получен, счёт сверен, оплата запланирована. Если акт не пришёл к сроку, это видно заранее. Цены и тарифы на такую схему описаны на странице тариф.

Как это ведёт ИИ

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

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

Что покажет эффект

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

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

Частые ошибки

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