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

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

Ключевые выводы

Зафиксируйте версию таксономии, определения, исключения и правила сопоставления.

Храните исходную идентичность поставщика отдельно от проверенной канонической записи.

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

Требуйте доказательства, допустимый код или статус исключения.

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

Сверяйте количество строк, валюты и суммы до и после классификации.

Как классифицировать закупочные расходы с помощью ИИ ответственно?

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

Материал	Назначение	Полномочия
Снимок расходов	Исходные операции и суммы	Финансовая или закупочная система
Таксономия	Допустимые категории	Владелец категории
Предложение сопоставления	Код с доказательством	Процесс с участием ИИ
Решение проверки	Принять, изменить или отклонить	Уполномоченный проверяющий
Анализ	Агрегировать утверждённые сопоставления	Контролируемая отчётность

UNSPSC — один из вариантов. Министерство торговли США описывает уровни segment, family, class и commodity, а CanadaBuys — ту же восьмизначную четырехуровневую модель.［1］［3］ Организация может применять локальную или смешанную схему, но модель не должна незаметно смешивать несколько систем.

Какие таксономия и доказательства нужны заранее?

Шаг 1. Зафиксируйте источник и таксономию

Составьте заголовок классификации:

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

Управление категориями использует структуру для анализа расходов и разработки стратегии.［2］ Это не значит, что каждой транзакции нужен самый детальный код. Выбирайте уровень, который подтверждают доказательства и решение: широкий обоснованный класс лучше выдуманного товарного кода. Не перезаписывайте исходные поля категории. Добавляйте новые поля предложенной и проверенной категории, чтобы можно было сравнить старое и новое сопоставление, воспроизвести отчет и отменить неверное правило.

Шаг 2. Нормализуйте поставщика без потери источника

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

Поле	Значение
`vendor_raw`	Точное значение исходной системы
`vendor_canonical_id`	Проверенная внутренняя идентичность
`vendor_display_name`	Утверждённое имя для отчёта
`match_basis`	ID договора, реестр поставщиков или проверенное правило
`match_status`	Подтверждён, кандидат, неоднозначен или не найден
`effective_period`	Период действия сопоставления
`reviewer`	Утвердившее лицо или роль

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

Шаг 3. Опишите границы и право отказаться

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

Создайте явные статусы, например:

classified: доказательства поддерживают один допустимый код.
multi_category: строка действительно содержит разделимые категории.
insufficient_description: описания не хватает для кода.
vendor_ambiguous: личность поставщика не установлена.
taxonomy_gap: подходящей допустимой категории нет.
out_of_scope: операция исключена зафиксированным правилом.
review_required: существенный или чувствительный случай требует человека.

Отказ лучше выдуманной точности: проблему источника нельзя скрывать как проблему таксономии или наоборот.

Шаг 4. Подготовьте эталонную выборку

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

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

Как классифицировать, измерять и контролировать результаты?

Шаг 5. Требуйте предложение, доказательство и исключение

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

Для каждого spend_row_id верните допустимый код категории или статус исключения.
Укажите предоставленные поля, подтверждающие предложение. Не выводите деятельность
поставщика, разделение сумм, налоги, соответствие или квалификацию. Если подходят
несколько категорий либо ни одна, верните review_required с объяснением.
Не создавайте коды за пределами версии TAX-07.

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

Шаг 6. Проверяйте вероятные ошибки

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

Полезные срезы для проверки:

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

Проверяющий должен видеть исходные поля, определение из таксономии, предложенный код, доказательства и соседние альтернативы. Записывайте accept, change, split, insufficient_evidence или taxonomy_issue, причину и личность проверяющего. Не используйте проверку поставщика как скрытую замену классификации: анкета комплексной проверки поставщика собирает другие доказательства и не доказывает, что именно куплено в конкретной транзакции.

Шаг 7. Измеряйте ошибки по категориям

На контрольной выборке постройте матрицу ошибок и рассчитайте precision, recall и F1 по каждой категории, указав количество и сумму примеров. Различайте смысл показателей:

Показатель	Вопрос
Precision	Какая доля присвоений категории верна?
Recall	Какая доля истинных строк категории найдена?
F1	Насколько сбалансированы точность и полнота?
Ошибка по сумме	Какая стоимость отнесена неверно?
Доля исключений	Как часто процесс отказывается от классификации?
Доля пересмотра	Как часто человек меняет предложение?

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

Профиль NIST для генеративного ИИ рассматривает оценку и управление ошибками как постоянный процесс.［4］ Повторяйте оценку при смене таксономии, поставщиков, источника, модели, подсказки или структуры расходов.

Шаг 8. Сверяйте строки и суммы

Прежде чем считать итоги по категориям, докажите:

исходные строки = классифицированные + нерешённые + исключённые из периметра
исходная сумма = классифицированная + нерешённая + документированно исключённая
сумма проверенных категорий = проверенная классифицированная сумма
сумма дочерних строк = исходная сумма смешанной строки

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

Шаг 9. Версионируйте решения

Выпуск включает снимок, таксономию, инструкции, эталон, оценку, сопоставления поставщиков, решения по строкам, исключения, роли и дату действия. Сохраняйте прошлую версию для сравнения и отката.

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

Типичные ошибки

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

Итоги

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

Часто задаваемые вопросы (FAQ)

Можно ли классифицировать расходы только по имени поставщика?

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

Какую таксономию расходов выбрать?

Утвержденную для цели отчета и юрисдикции. Запишите версию и глубину. UNSPSC — один вариант, а не универсальное требование.

Можно ли автоматически разделить смешанный счет?

Только если источник содержит суммы и утвержденное правило разрешает разделение. ИИ не может придумывать распределение; иначе сохраните исходную сумму и направьте строку человеку.

Что означает ошибочно классифицированный поставщик?

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

Достаточно ли уверенности модели, чтобы не проверять результат?

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

Какого размера должна быть эталонная выборка?

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

Может ли классификация определить победителя закупки?

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

Когда переоценивать классификатор?

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

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

Источники

U.S. Department of Commerce, United Nations Standard Products and Services Codes (UNSPSC): https://www.commerce.gov/oam/resources/united-nations-standard-products-and-services-codes-unspsc
Acquisition.gov, Category Management: https://www.acquisition.gov/content/category-management
CanadaBuys, Commodity codes: https://canadabuys.canada.ca/en/tender-opportunities/commodity-codes
National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1): https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 6 сентября 2026 г.

Как классифицировать закупочные расходы с помощью ИИ