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

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

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

Какую задачу решает этот процесс

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

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

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

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

Какие данные и правила подготовить

Сначала нужно описать не экран будущего решения, а входные данные, их владельцев и условия остановки. Для каждого поля стоит определить источник, ответственного и обязательность.

«Обязательное» означает, что без значения строку нельзя передать дальше по принятому маршруту. «Условное» поле требуется только при заранее описанном условии. «Неизвестное» — это состояние значения, а не повод заполнить его наиболее вероятным вариантом.

Короткий синтетический образец без клиентских данных:

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

Как собрать чеки без повторного ввода

Учебная последовательность выглядит так:

1. Система получает файл и присваивает ему идентификатор.
2. Сохраняет исходный файл без замены и связывает его с сотрудником, поездкой или отчётом.
3. OCR выделяет доступные реквизиты: дату, продавца, сумму, валюту и другие предусмотренные поля.
4. Проверка отмечает нечитаемые области, пропуски и возможные дубли.
5. Строка либо продолжает маршрут, либо попадает в очередь уточнений.

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

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

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

Что проверять до передачи бухгалтеру

До передачи строки бухгалтеру система или назначенный сотрудник последовательно проверяет:

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

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

Каждая неудачная проверка должна давать понятный результат. Например: «валюта не читается — запросить более чёткий оригинал у сотрудника» или «найдена строка с тем же идентификатором оригинала — передать пару на проверку». Формулировка «ошибка документа» без причины не помогает исправить отчёт.

Если на изображении цифра похожа одновременно на 3 и 8, система не выбирает более вероятный вариант. Она оставляет сумму неизвестной и запрашивает уточнение. То же правило действует при расхождении валюты, даты или продавца.

Как согласовать и закрыть отчёт

Решение руководителя и бухгалтерская проверка — разные этапы.

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

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

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

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

Учебный пример: путь от входных данных до результата

Ниже — синтетический пример, а не клиентский кейс и не результат живого теста. Все обозначения, участники и суммы условны.

Сотрудник прислал три читаемых оригинала: A на 1 200 рублей, B на 800 рублей и C на 500 рублей. Файл C поступил повторно как C-2. Кроме того, в очереди есть чек D, на котором сумма не читается.

Известные суммы до проверки дублей: 1 200 + 800 + 500 + 500 = 3 000 рублей. Повтор C-2 на 500 рублей исключается. Подтверждённая арифметическая сумма читаемых уникальных чеков составляет 3 000 − 500 = 2 500 рублей. Чек D в итог не входит: его сумму нельзя угадывать.

Промежуточное решение состоит из двух частей. Строки A, B и C готовы к следующему этапу. C-2 остаётся связанной с C в истории, но не увеличивает сумму. D находится в спорной очереди с причиной «сумма не читается».

Результат примера — 2 500 рублей по трём уникальным читаемым чекам и отдельный запрос более качественного оригинала D. Если сотрудник пришлёт новую версию D, её нужно связать с прежней строкой и проверить заново. До этого сумма D остаётся неизвестной.

Как проверить результат перед запуском

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

Перед запуском стоит также проверить, что:

• каждый результат OCR можно сопоставить с исходным файлом;
• один оригинал не создаёт два подтверждённых расхода;
• неизвестные значения остаются неизвестными;
• спорная строка получает причину и ответственного;
• решение руководителя не подменяет бухгалтерскую проверку;
• изменение правила заставляет повторить затронутые сценарии.

Успех на одном наборе не доказывает работу во всех условиях. Состав приёмочных примеров, допустимые отклонения и условия остановки нужно закрепить до запуска.

Что согласовать для внедрения

Сначала следует определить границу между готовым инструментом и собственной интеграцией. Готовый инструмент может поддерживать загрузку документов, распознавание или маршруты, но конкретные возможности нельзя считать доступными заранее. Для выбранного решения отдельно проверяют тариф, права, API, форматы файлов, хранение оригиналов и доступные действия.

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

Switch On AI разрабатывает ИИ-помощников, ботов и интеграции под конкретную операцию после проверки данных и API. Для этого сценария предметом проекта может стать очередь проверенных расходов с оригиналами чеков и спорными строками. Правила бухгалтерского, юридического, кадрового и отраслевого учёта задаёт и проверяет специалист заказчика.

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

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