Кодирование счетов с помощью AI до смены ERP системы

Почему кодирование счетов становится ручной работой

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

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

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

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

Источник проблемы часто уже, чем кажется. Команды иногда винят ERP, потому что кодирование происходит там. Но многие проблемы возникают раньше. План счетов может быть слишком широким. Описания поставщиков — непоследовательными. Некоторые правила живут только в голове одного человека.

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

Что AI должен делать в первую очередь

Начните с узкой задачи. Первая роль AI — не перерабатывать весь финансовый процесс. Он должен читать каждую строку счета и предлагать те же решения по кодированию, которые команда делает вручную.

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

Полная переделка звучит красиво, но она всё замедляет. Новые правила согласования, логика платежей и изменения в ERP вовлекают больше людей, больше рисков и больше встреч. Для первого пилота оставьте в покое согласования и платежи. Пусть AI работает только над узкой частью, которая создает самую повторяющуюся работу.

Лучше всего начинать с повторяющихся счетов от известных поставщиков. У них есть шаблоны. Формулировки могут немного меняться, но один и тот же поставщик часто выставляет счета за одни и те же услуги, использует тот же налог и попадает в один и тот же центр затрат из месяца в месяц.

Разумная первая область:

• классифицировать строковые позиции от короткого списка известных поставщиков
• предлагать код счета, центр затрат и налоговый код
• показывать показатель уверенности для каждого предложения
• отправлять позиции с низкой уверенностью на проверку человеку

Это дает финансам безопасную тестовую среду. ERP остается на месте. Цепочка согласований остается. Выплата остается. Вы выясняете, справится ли модель с повторяющейся частью, прежде чем давать ей доступ к чему‑то более чувствительному.

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

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

Выберите пилот, которым финансы смогут управлять

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

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

История важна так же, как формат. Выбирайте поставщиков, по которым у вас уже есть приличная история прошлых кодировок. Тогда команде проще сравнивать, где модель помогает, а где ошибается.

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

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

Пропустите странные кейсы на первом этапе. Кредит‑ноты, разбитые счета, единоразовые проектные расходы и длинные счета, распределяемые по нескольким отделам — это потом. Такие случаи важны, но они могут скрыть, работает ли вообще классификация строк.

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

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

Установите пороги уверенности до rollout

Пилот рушится, когда каждой строке дают одинаковое обращение. На практике правила по порогам часто важнее самой модели.

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

Простой стартовый вариант выглядит так:

• 0.95 и выше: принять и дальше использовать
• 0.75–0.94: отправить на проверку человеком
• ниже 0.75: оставить ручное кодирование

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

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

Многим командам лучше всего подходит простой раздел ролей. AP проверяет данные поставщика и дубликаты. Владельцы бюджетов рассматривают неясные расходы. Закупки правят сопоставление позиций поставщика, когда описания съезжают. Контролёр решает налоговые и политические спорные случаи.

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

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

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

Запустите пилот по шагам

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

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

Затем очистите очевидные проблемы в данных. Удалите дубли, объедините разбитые выгрузки и исправьте метки, которые всем известны как ошибочные. Если история показывает, что одна и та же покупка разными разами была отнесена к разным счетам из‑за старых ошибок, модель «выучит» эту путаницу.

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

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

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

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

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

Простой пример на одном поставщике

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

Предположим, в месяц от этого поставщика пришли четыре счета с общим количеством 120 строк. Большинство из них знакомы. Модель читает "A4 copy paper, 5 boxes" и кодирует как канцелярские товары с уверенностью 0.98. Она читает "24-inch monitor" и ставит это в компьютерное оборудование с 0.96. "Wireless keyboard" получает 0.94.

Эти обычные строки переходят в черновую партию с минимальным трением. Финансы сохраняют контроль, но никому не приходится вводить одно и то же решение 40 раз. Быстрая проверка заменяет посрочную работу со строками.

Потом появляется необычная позиция: "On-site assembly service for 12 sit-stand desks." Поставщик обычно продаёт товары, а не услуги, поэтому модель колеблется. Уверенность падает до 0.61, что ниже порога проверки. Система отправляет строку человеку, который выбирает правильный код и продолжает работу.

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

Через месяц финансы могут измерить результат простыми цифрами:

• 120 всего строк
• 93 закодированы выше высокого порога уверенности
• 19 отправлены в очередь быстрой проверки
• 8 направлены на полное ручное кодирование
• примерно 3 часа сэкономлено за месяц

Математика проста. Если ручное кодирование занимает около 90 секунд на строку, 120 строк — это примерно три часа. Если команда проверяет только низко‑ и средне‑уверенные строки и батч‑проверяет остальные, тот же месяц может занять 20–30 минут. Это дает финансам ясный тест без изменения ERP.

Ошибки, которые портят тест

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

Одна распространённая ошибка — смешивание слишком многих поставщиков в первом раунде. Каждый поставщик по‑разному маркирует товары, по‑разному строит таблицы и по‑своему работает с налогами. Начните с одного‑двух поставщиков с одинаковыми счетами каждый месяц. Это даст модели честный шанс.

Ещё одна проблема — считать балл уверенности одобрением. Модель может быть уверена на 94% и всё равно ошибиться в коде, налоге или центре затрат. Установите правила проверки до того, как кто‑то увидит результаты. Например: автопринятие только при очень высоких оценках, средние — на ревью, низкие — ручное введение. Без структуры люди спорят об отдельных фактах вместо того, чтобы смотреть, экономит ли пилот время.

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

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

Ещё плохой выбор — начать со счетов, которые меняют формат каждую неделю. Некоторые поставщики присылают чистые PDF один месяц, сканы в следующем, а потом кредит‑ноты в другом макете. Оставьте их на потом. Сначала используйте стабильные документы, а затем добавляйте «грязные».

Маленькая скучная выборка лучше широкой хаотичной. Если пилот работает в чистых условиях, расширяйте. Если не работает — большой тест только скроет проблему.

Проверьте базовые вещи перед расширением

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

Используйте короткую табличку показателей и обсуждайте её с теми, кто утверждает, исправляет и постит счета. Если сотрудники AP всё ещё тратят столько же времени на очистку строк, пилот не готов к расширению.

Смотрите на время ревью на уровне строк. Если раньше ревьюеру нужно было 90 секунд на строку, а теперь 25 — это реальная экономия. Если снижение времени происходит только на простых строках, зафиксируйте это тоже.

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

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

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

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

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

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

Что делать дальше

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

В первом раунде зафиксируйте четыре вещи: область, цель успеха, правило проверки и правило остановки. Практически это значит: назвать поставщиков в зоне, установить цель (например, 85% правильных кодов выше согласованного порога), решить, кто обрабатывает низко‑уверенные строки и как быстро, и согласовать, когда приостановить добавление объёма и заняться исправлением ошибок.

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

Если результаты смешанные — остановитесь и разберите промахи. Ищите закономерности. Один поставщик может использовать расплывчатые описания, один центр затрат путают с другим, или налоговые строки ломают модель. Сначала исправьте эти вопросы. Цель пилота по смене ERP не в том, чтобы сразу менять систему, а в том, чтобы доказать: автоматизация финансов экономит время, не создавая работу по очистке.

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

Некоторые команды могут спланировать это самостоятельно. Другим полезен внешний взгляд, который удержит пилот узким и практичным. Oleg Sotnikov, через oleg.is, консультирует компании по AI‑первым продуктам и проектам автоматизации — такой взгляд может помочь финансам протестировать кодирование счетов и пороги уверенности, не скатившись преждевременно в масштабную замену системы.