Как языковая модель нашла деньги там, где бухгалтерия давно махнула рукой
Дело не в лени и не в недосмотре. Дело в арифметике самого процесса. Возместить НДС из чека — значит вручную найти на нем поставщика, его ИНН, сумму НДС, ставку, номер и дату, сверить это с требованиями налоговой и завести в учетную систему. Один чек — несколько минут работы человека. Десятки тысяч чеков в год — это отдельный штат бухгалтеров, зарплата которых съест значительную часть той суммы, которую они же и должны возместить. Проще списать. Так компания годами платила больше налога, чем должна была, просто потому, что путь к своим же деньгам стоил дороже, чем сами деньги.
Когда мы посчитали потенциал, получилось около 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-парсинга, ему пришлось бы:
Собрать датасет размеченных чеков по каждому формату кассы и сети — это месяцы работы разметчиков.
Написать и поддерживать сотни правил-регулярок, которые ломаются при любом обновлении формата чека у любого из тысяч поставщиков.
Отдельно решать задачу поворота, бликов, обрезки изображений — это отдельные ML-модели, каждая со своим циклом обучения.
И все равно не получить встроенной самопроверки: классический пайплайн находит цифры, но не проверяет, что они логически согласованы друг с другом.
LLM снимает пункты 1–4 одним универсальным механизмом понимания текста и контекста, который не нужно переобучать под каждый новый формат чека — только направлять правильным промптом и обвязывать контролем качества.
В переводе на деньги: там, где классический подход означал долгий и дорогой ИТ-проект с неопределенным результатом, LLM-подход дал рабочий прототип за недели, а не за кварталы — и открыл дорогу к тем самым 20 миллионам рублей НДС, которые компания раньше просто не пыталась достать, потому что путь к ним стоил дороже самих денег.
Получите дорожную карту по внедрению 1С разработанную для вашей компании бесплатно!
Экспресс-обследование компании с дальнейшей разработкой пошагового внедрения системы 1С
Вывод
Самые интересные бизнес-задачи для LLM — это не «напиши текст» и не «ответь на вопрос». Это задачи, где раньше стоял барьер из тысяч частных случаев, слишком дорогих для ручной обработки и слишком разнородных для жесткого алгоритма. Чек с перевернутой фотографией, размытая цифра, неоднозначная инструкция человека — для классического кода это исключения, требующие отдельной строчки правил. Для модели, умеющей рассуждать, — это просто еще один чек, который нужно прочитать внимательно.
И иногда за этим внимательным чтением стоят вполне реальные 20 миллионов рублей.
Наша компания готова помочь вам автоматизировать учет и бизнес-процессы. Свяжитесь с нами для получения подробной информации по телефону +7(495) 154-30-66 или электронной почте sales@rg-spc.ru.
Реклама: ООО «РГ-Софт Проект Консалтинг», ИНН 7736229025, erid: 2W5zFHGazgH
Комментарии
4а могли бы просто уйти от наличных и подотчетов
а вы и в суд за нас пойдете?