20 миллионов рублей, которые лежали в мусорной корзине

Как языковая модель нашла деньги там, где бухгалтерия давно махнула рукой

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

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

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

Почему это не задача для классического компьютерного зрения

Первая мысль, которая приходит в голову любому, кто далёк от практики: «Ну это же просто OCR плюс регулярные выражения». Найти на фото слово «ИНН», взять цифры после него, найти «СУММА НДС», взять сумму рядом. Задача на выходные для одного разработчика.

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

• чеки фотографируют как попало - перевёрнутыми, под углом, вверх ногами, в тени, с бликом от вспышки;

• у каждой сети свой формат чека, а таких сетей - сотни, от федеральных ритейлеров до столовой в посёлке за Полярным кругом;

• термопечать выцветает, и часть цифр читается только «по смыслу», а не по факту напечатанных пикселей;

• слово «ИНН» на чеке может встречаться два раза - для продавца и для оператора фискальных данных, и алгоритм по regex не отличит одно от другого;

• итоговая сумма НДС может быть указана одной строкой, а может быть размазана по позициям и её нужно посчитать самому, сверяя с математикой чека.

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

Что происходит внутри модели, когда она смотрит на чек

Мы прогнали задачу через LLM и сохранили её ход рассуждений. То, что там написано, - лучший аргумент в пользу подхода, чем любая презентация.

Вот чек, сфотографированный сразу с двух сторон - один нормально, второй перевёрнутым. Классический OCR просто не распознает перевёрнутый текст без отдельного шага «поворот + повторное распознавание», зашитого заранее. Модель делает это сама, как сделал бы человек:

«Левый чек перевернут и его читать сложно, но он тоже содержит информацию... Перевернув мысленно: видно "ООО АНЭФСЭН ГРУПП" в самом низу (который сверху на перевернутом чеке)... Значит, оба чека относятся к одному и тому же поставщику».

Это не распознавание символов. Это рассуждение о содержании - модель сопоставила два изображения по смыслу и сделала вывод, а не просто вернула то, что смогла прочитать.

Дальше - эпизод, который стоит показывать каждому финансовому директору, сомневающемуся в надёжности ИИ. Модель не просто нашла строку «СУММА НДС», она сама себя перепроверила арифметикой:

«Если Total = Price + Tax, то Price = Total / 1.2... 177.00 / 1.2 = 147.5. Tax = 147.5 * 0.20 = 29.5... Расчёт НДС по каждой позиции: Item 1: 35.00, VAT = 35 / 1.2 * 0.2 = 5.83... Total VAT sum: ~29.49. Чек явно указывает СУММА НДС 20% = 29.49».

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

Третий эпизод показывает, как модель работает с неоднозначной инструкцией человека. Заказчик написал: «Номер чека находится после "ФН:"» - но на реальном чеке рядом стоят несколько похожих подписей: ФН, ФД, РН ККТ, ОГРН, и не всегда очевидно, что именно имел в виду человек, писавший промпт. Вот как модель разбирает эту неоднозначность, не останавливаясь и не выбрасывая ошибку:

«В Российских чеках: "ФН" = Фискальный Номер... "ФДН" = Фискальный Документ Номер... Прочитаю инструкцию буквально: значение после "ФН:" - это "2656561331"... Итоговый JSON структурирован по этому правилу».

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

Четвёртый эпизод - пожалуй, самый ценный для бизнес-задачи, потому что именно он превращает LLM из «читалки текста» в инструмент, которому можно доверить деньги. Реальный чек из супермаркета сфотографирован так, что правый край обрезан - видна только часть суммы НДС: «115...». Классический OCR на этом месте просто вернул бы пустое поле или мусор, потому что физически этих пикселей на фото нет. Модель поступает иначе - она реконструирует недостающие копейки через математику всего чека:

«Вижу строку СУММА НДС 20%. Справа: =115... (последние цифры обрезаны, но видно 115). Посчитаем итог. Товары: Контейнер =15.00, Апельсины =148.68, Спагетти =28.00, Гуляш =150.00, Суп гуляш =43.00, Напиток =12.00, Хлеб =6.00, Кофе =290.00... 15 + 148.68 + 28 + 150 + 43 + 12 + 6 + 290 = 692.68. Посчитаем НДС 20% от 692.68: 692.68 * 0.2 / 1.2 = 115.446. Видно 115. Значит сумма НДС 20% это 115.45 (округлено)».

Модель не гадает и не додумывает случайную цифру - она складывает все позиции чека, получает итоговую сумму, от которой аналитически выводит точную сумму НДС, и только после этого сверяет результат с тем обрывком «115», который физически виден на фото. Совпадение подтверждает гипотезу. Это ровно та работа, которую делает опытный бухгалтер, когда часть чека выцвела или обрезана при сканировании: он не потому угадывает 115.45, а не 115.23, что «повезло», а потому что знает - сумма НДС обязана биться с суммой позиций. У модели это встроено в саму логику, а не является отдельной функцией, которую нужно было бы отдельно программировать под каждый случай обрезанного скана.

Пятый эпизод - из чека такси, и он показывает другой тип аккуратности, критичный именно для возмещения НДС: умение не приписать НДС там, где его нет, и не перепутать ИНН посредника с ИНН реального поставщика услуги. На чеке одновременно присутствуют два разных ИНН - платформы-агрегатора и фактического перевозчика, а в строке «ИТОГО без НДС» явно указано, что налог не выделен:

«На чеке два ИНН: 7704340310 (в шапке, ООО "Яндекс.Такси") и 8602171978 (в строке "ИНН Поставщика"). ...Поставщиком услуги перевозки, скорее всего, выступает не платформа, а конкретный перевозчик... "ИТОГО без НДС 422.00" подтверждает, что налог не начислен. Сумма НДС: 0.00, ставка: 0».

Для задачи возмещения НДС это не менее важный навык, чем находить сумму там, где она есть. Ошибочно «нарисованный» НДС там, где его нет, - это не бухгалтерская мелочь, а прямой риск доначислений и штрафов при налоговой проверке. Жёсткий парсер, заточенный на паттерн «нашёл цифры рядом со словом НДС - вернул их», в подобной ситуации либо вернёт пустоту, либо, что хуже, спутает ИНН посредника с ИНН реального поставщика. Модель же явно рассуждает о структуре сделки - кто на самом деле оказал услугу - и соответственно решает, что возмещать нечего, вместо того чтобы создать в учёте фиктивное основание для вычета.

Честно о слабых местах

Хорошая продающая история - это ещё и честная история. В тех же логах видно, как модель иногда «зацикливается»: на одном из чеков с плохо читаемой строкой она несколько десятков раз подряд повторила одну и ту же фразу «Текст: "СТАВКА НДС 10% ... 31.81"», не двигаясь дальше в рассуждении. Для продакшн-системы это реальный риск, который нельзя замалчивать.

Именно поэтому production-контур строился не как «одна модель - один ответ», а как конвейер с защитными механизмами:

• ограничение на длину рассуждения и таймаут с автоматическим повтором запроса при зацикливании;

• встроенная арифметическая проверка результата модели отдельным детерминированным пересчётом (тот самый трюк с делением суммы на 1.2, который модель делает сама, дублируется вовне как контрольная сумма);

• пороги уверенности: если сумма НДС по чеку слишком большая или структура выбивается из типовой, документ уходит на ручную проверку, а не в автоматическое возмещение;

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

С этими контурами модель перестаёт быть «магическим чёрным ящиком» и становится тем, чем и должна быть - быстрым и умным первым звеном в процессе, за которым стоит контроль.

Почему это выигрывает у алгоритмического подхода в деньгах, а не только в теории

Если бы заказчик пошёл по пути классического CV и NLP-парсинга, ему пришлось бы:

1. Собрать датасет размеченных чеков по каждому формату кассы и сети - это месяцы работы разметчиков.

2. Написать и поддерживать сотни правил-регулярок, которые ломаются при любом обновлении формата чека у любого из тысяч поставщиков.

3. Отдельно решать задачу поворота, бликов, обрезки изображений - это отдельные ML-модели, каждая со своим циклом обучения.

4. И всё равно не получить встроенной самопроверки: классический пайплайн находит цифры, но не проверяет, что они логически согласованы друг с другом.

LLM снимает пункты 1–4 одним универсальным механизмом понимания текста и контекста, который не нужно переобучать под каждый новый формат чека - только направлять правильным промптом и обвязывать контролем качества.

В переводе на деньги: там, где классический подход означал долгий и дорогой ИТ-проект с неопределённым результатом, LLM-подход дал рабочий прототип за недели, а не за кварталы - и открыл дорогу к тем самым 20 миллионам рублей НДС, которые компания раньше просто не пыталась достать, потому что путь к ним стоил дороже самих денег.

Вывод

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

И иногда за этим внимательным чтением стоят вполне реальные 20 миллионов рублей.

Наша компания готова помочь вам автоматизировать учет и бизнес-процессы. Свяжитесь с нами для получения подробной информации по телефону +7(495) 989-22-16 или электронной почте sales@rg-spc.ru.