В договоре три суммы. Почему мы не стали выбирать платёж за пользователя

Самый неприятный этап оплаты счёта иногда начинается уже после того, как поставщик всё оформил. Документ открыт на телефоне, реквизиты есть, QR нет. Остаётся переносить длинный расчётный счёт, БИК, получателя и назначение в банк.

Мы развиваем «Витрину QR» и сделали для этой задачи инструмент: документ → найденные реквизиты → сверка → QR для платежа по реквизитам. Затем попробовали тот же маршрут на договоре. Именно здесь стало понятно, почему полезная автоматизация должна уметь останавливаться.

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

Для открытого примера мы взяли вымышленные условия: услуги стоят 48 600 ₽, аванс — 50%, отдельное обслуживание — 5 000 ₽ в месяц. Если сейчас нужен аванс, сумма составит 24 300 ₽. Общая цена и ежемесячный платёж от этого не исчезают: это другие варианты с другим смыслом. Реальные документы клиентов в демонстрацию не попали.

Поэтому результат разбора договора — несколько кандидатов на сумму, а не обещание угадать намерение плательщика. Пользователь выбирает вариант и видит, откуда он взялся. Для рассчитанного аванса раскрываются формула и фрагменты условий. Если общая цена неоднозначна, программа не предлагает процентный аванс.

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

Данные можно исправить. После изменения формы прежний QR скрывается до новой сверки. Это небольшая деталь интерфейса, но без неё легко сохранить код, подготовленный для старой суммы.

Подготовленный QR можно сохранить изображением или на листе А4. Перевод выполняется и подтверждается в банковском приложении. Это платёж по реквизитам, не подключение эквайринга или СБП. Поддержка формата и заполнение конкретных полей зависят от банка, приложения и типа счёта. Демонстрация показывает создание QR; реального перевода денег мы не выполняли.

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

Проверить маршрут можно без своего документа. В инструменте есть пример счёта и пример договора: выберите аванс 24 300 ₽, раскройте «Из чего получился аванс», затем сверьте форму. Учебные реквизиты вымышлены, оплачивать их нельзя.

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

Автор — команда «Витрины QR», разработчики описанного инструмента. Работающая версия и пример проверены 20 октября 2026 года. Схемы авторские; примеры вымышленные.

Попробовать на вымышленном примере:

Открыть счёт и договор с авансом в «Витрине QR»

Материал по теме в нашем Дзене: разбор счёта и договора с инфографикой

Короткие видео: QR из счёта и аванс из договора.