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

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

Три документа отвечают на разные вопросы
Заказ показывает, что и по каким условиям компания согласовала приобрести. Приёмка показывает, что фактически получено и принято. Счёт сообщает, что поставщик просит оплатить. Совпадение итоговых сумм не означает совпадения состава, количества или оснований. Поэтому полезна сверка на уровне строк и связанных партий.
В документации Dynamics 365 описана трёхсторонняя сверка: счёт сопоставляют с заказом и сведениями о приёмке, применяя согласованные правила. Ссылка показывает сам подход, покупать Dynamics для него не нужно. Его ограниченный вариант можно реализовать поверх текущего учёта, если нужные данные доступны.
При этом не всякая оплата требует предварительной приёмки. Аванс, этапный платёж, аренда и услуги имеют собственные основания. Для них нельзя механически применять правило «товар не получен, платить нельзя». В карточке указывают тип обязательства, этап и согласованный порядок. Первая версия может охватывать только обычные поставки с оплатой после приёмки.
Где взять данные, если уже работают 1С и Excel
Сначала проверьте, есть ли заказ, поступление и расчёты в существующей конфигурации. 1С:ERP поддерживает управление взаиморасчётами по объектам расчётов. Создание второго самостоятельного учёта оплат может добавить расхождения вместо контроля. Дополнительному сервису достаточно подтверждённых данных и ссылки на исходный документ.
Если снабжение ведёт заказ в Excel, а склад принимает товар в 1С, нужен устойчивый номер заказа и соответствие строк. Название файла и фамилия снабженца для этого недостаточны. В пилоте допустима загрузка согласованных выгрузок: важно зафиксировать время, период, организацию и автора. Отсутствующая выгрузка приёмки показывается как недостаток данных. Доказательством того, что поставки не было, она не служит.
До подключения обсуждают, кто исправляет каждую ошибку. Поставщик уточняет свой документ, снабженец подтверждает изменение заказа, склад корректирует сведения о приёмке, бухгалтерия проверяет расчёты. Сервис собирает очередь расхождений и историю, но не переписывает документы за эти подразделения.
Как устроено распознавание счетов с ИИ
Распознавание счетов с ИИ начинается с оригинального файла. На выходе нужны поставщик, организация‑покупатель, номер и дата, валюта, налоговые сведения, строки, единицы, количества, цены и итог. Каждое критическое значение должно открываться рядом с источником. Если файл содержит несколько счетов или приложения, их разделение проверяют до сравнения.
Документация AI Builder описывает извлечение полей счёта, распознанного текста и номера страницы. Оценка уверенности помогает распределять проверку, но не доказывает правильность суммы. Конкретную модель выбирают по вашим форматам, языку, условиям обработки и доступности. Наличие функции в документации иностранной платформы не означает, что она подходит вашей компании.
ИИ также предлагает соответствие строк: «кабель силовой» в счёте и конкретный артикул в заказе. Если характеристик недостаточно, строка остаётся несопоставленной. Сходство названия не подтверждает марку, сечение, исполнение или допустимость замены. Техническую эквивалентность подтверждает компетентный сотрудник.
Что проверяют правила после распознавания
Сверка счёта и заказа включает организацию, валюту, артикул, характеристики, единицу, цену, количество и согласованные дополнительные расходы. Отдельно проверяют арифметику строк и итог. Условия налогов и округлений берут из документов и настроек компании. Предположения модели здесь не используются.
Следующий уровень связывает количество со сведениями о приёмке и предыдущими документами по этой поставке. Если из ста единиц принято шестьдесят, новый счёт на оставшиеся сорок нельзя считать повторным только из‑за одинакового заказа. И наоборот, два разных PDF могут относиться к одному обязательству. Сервис должен показывать историю частичных поставок и уже рассмотренных счетов.
Допуски на округления задают отдельно от разрешения изменить цену. Расхождение в копейку и незапланированное увеличение тарифа имеют разные причины. Универсальный процент, при котором «всё автоматически нормально», опасен для дорогих позиций. Даже небольшое относительное отклонение может быть существенной суммой.
Учебный пример с частичной приёмкой
Заказ содержит 100 единиц по 1 000 рублей, всего 100 000 рублей. Для простоты все суммы в примере приведены на одной налоговой основе, без доставки. Первая партия содержит 60 единиц, но две повреждены и не приняты. Подтверждённая приёмка составляет 58 единиц. Поставщик выставляет счёт на 60 единиц по 1 050 рублей, итого 63 000 рублей.
Сервис показывает два независимых расхождения. Цена выросла на 50 рублей за единицу относительно заказа. Количество к оплате превышает подтверждённую приёмку на две единицы, если для этой поставки действует оплата принятого товара. Стоимость 58 принятых единиц по согласованной цене равна 58 000 рублей. Разница со счётом составляет 5 000 рублей: 3 000 из‑за цены по всем 60 строковым единицам и 2 000 из‑за двух непринятых единиц по базовой цене.
Это разложение объясняет расхождение, но не устанавливает сумму платежа автоматически. Могло существовать согласованное изменение цены или иной порядок расчётов. Ответственный прикладывает основание либо запрашивает исправленный счёт. После решения система хранит исходный документ, подтверждённую версию и автора решения.
Как искать возможные дубли
Первый уровень проверки сравнивает файл целиком: повторная загрузка одинакового вложения не должна создавать новую карточку. Второй сопоставляет поставщика, организацию, номер, дату, валюту и сумму. Третий показывает похожие документы, у которых номер записан по‑разному или изменена дата. Такие совпадения только кандидаты на проверку, дубль ещё не доказан.
Исправленный счёт может иметь тот же номер, но другой состав. Его связывают с предыдущей версией, удалять его нельзя. Регулярные услуги могут давать одинаковые суммы каждый месяц; период здесь принципиален. Счёт и документ приёмки также не являются двумя отдельными обязательствами только потому, что оба содержат стоимость.
Автоматизация проверки счетов снижает риск пропуска таких ситуаций при правильных данных, но не гарантирует защиту от мошенничества. Смена банковских реквизитов требует отдельной проверки по принятому в компании порядку. Сопоставление строк и уверенное распознавание не подтверждают подлинность отправителя или основания платежа.
Как выглядит рабочее место согласующего
Сотрудник открывает список документов, ожидающих решения. В карточке рядом стоят исходный счёт, строки заказа и подтверждённая приёмка. Причины выделены конкретно: «не найден заказ», «единица не сопоставлена», «цена отличается», «похоже на предыдущую версию». Вместо общей красной плашки есть действие и ответственный.
Решения могут быть такими: запросить уточнение, принять подтверждённое изменение, направить на дополнительное согласование, отметить документ как заменённый. Причина и вложение сохраняются в журнале. Состояние «проверено» не равно «оплачено». Факт оплаты поступает из согласованного источника и связывается с обязательством, чтобы повторное рассмотрение не запустило второй платёж.
Перед передачей на оплату проверяют, не изменились ли заказ или приёмка после согласования. Если исходная версия стала другой, результаты сравнения устарели. Система заново показывает расхождения, зелёный статус от вчерашней версии не сохраняется.
Как ограничить первую версию
Начните с одной организации, одной валюты и понятной категории закупок. Включите несколько поставщиков с повторяющимися форматами документов. Первая версия может готовить реестр расхождений и согласованный файл для дальнейшей работы, не создавая платёжных поручений и не проводя документы в учёте.
Проверка должна включать частичную поставку, исправленный счёт, дубль вложения, другую единицу, дополнительную доставку и отсутствующую приёмку. Считайте время полного рассмотрения, количество неверных тревог и пропущенных известных расхождений. Демонстрация на одном чистом PDF не проверяет работу процесса.
Для обсуждения такого продукта подготовьте обезличенный комплект: заказ, счёт, приёмку и пример исправления. TRIKE поможет спроектировать проверяемый маршрут и небольшой кабинет согласования, который дополняет действующие системы.
Смежные разборы: Сравнение предложений поставщиков с ИИ для строительного снабжения; Подготовка данных к автоматизации: справочники без путаницы.
Частые вопросы
Можно ли автоматически оплачивать совпавшие счета?
Совпадение данных само по себе не даёт права на платёж. Сначала нужно проверить основания, доступы, актуальность документов и правила компании. В первом запуске полезнее ограничиться подготовкой результата сверки для сотрудника.
Что делать, если нет структурированного заказа?
Можно начать с утверждённой таблицы с номером заказа, строками, единицами и ценами. Если договорённости остаются только в звонках, сначала потребуется фиксировать их. ИИ не восстановит достоверные условия из отсутствующих документов.



