Matchpoint | Автоматизация счетов к оплате

1. Контекст: расхождение — не ошибка в таблице, а рабочий объект

Matchpoint — сервис для команд, которые обрабатывают счета от поставщиков.

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

Причин может быть много:

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

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

Конкуренты — Bill.com, Tipalti и Coupa — оптимизируют идеальный сценарий и трактуют исключения как предупреждения: система поднимает флаг, а причину, владельца и следующий шаг человек находит сам. Matchpoint я строил от обратного: расхождение здесь не ошибка в таблице, а управляемый объект с жизненным циклом Detect → Diagnose → Route → Resolve → Trace. Скоуп этого кейса — Detect и Diagnose, то самое слабое место, которое конкуренты оставляют пользователю.

Домен. Основной пользователь — специалист по расчётам с поставщиками (AP-специалист), который обрабатывает 200–500 счетов в месяц от 50–100 поставщиков. Каждый счёт проходит сверку счёта, заказа на закупку и подтверждения приёмки. Исключение — это любое место, где три документа не сходятся.

Метрики успеха

• Бизнес-метрики: средний срок оплаты счетов поставщиков (DPO), стоимость обработки одного счёта, доля оплат в срок, штрафы за просрочку, готовность к аудиту.
  • Операционные метрики: время решения исключения, доля исключений, закрытых без эскалации, доля ложных тревог, доля исключений, закрытых группами.
• Пользовательские метрики: доля расхождений, для решения которых не нужно выходить из системы; время, за которое AP-специалист понимает причину расхождения; доля расхождений, для которых сразу понятен ответственный.

Пользователи

• AP-специалист — разбирает исключения каждый день. Главная боль — постоянное переключение между документами и системами.
• Менеджер — подключается, когда сумма высокая или решение рискованное.
• Закупки и склад — не работают в системе постоянно, но получают вопросы, когда ошибка связана с заказом или приёмкой.

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

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

В скоупе — расхождение с заказом на закупку и возможный дубль счёта. Вне скоупа — зависшие согласования, SLA (соглашение об уровне обслуживания) и эскалации.

3. Дискавери: система находит расхождение, но причину ищет человек

Я начал с кабинетного исследования: изучил отзывы о Bill.com, Tipalti и Coupa, публичные материалы об автоматизации расчётов с поставщиками и обсуждения AP-специалистов. В разных источниках повторялась одна проблема: система находит расхождение, но дальше человек всё равно сам выясняет причину, ответственного и следующий шаг.

Ключевые инсайты

• Флаг без объяснения. Система сообщает, что счёт «не сходится», но не показывает достаточно контекста: какая строка вызвала проблему, с чем именно она расходится и кто должен это исправить. В итоге AP-специалист, закупки и склад разбирают такие случаи вручную — через письма, чаты и созвоны.
• Автоматике не доверяют без объяснения уверенности. Если система просто поднимает флаг, но не показывает, насколько надёжен этот сигнал, пользователь начинает перепроверять всё вручную. Особенно это критично для нестандартных шаблонов, новых поставщиков и спорных данных.
• Контекст утекает из системы. Когда решение обсуждают в почте и мессенджерах, история быстро теряется: кто проверил, что решил и почему согласился или отклонил счёт. В конце месяца это усложняет аудит и замедляет закрытие периода.
• Задержка стоит денег. Зависшие исключения напрямую влияют на бизнес: платежи задерживаются, поставщик ждёт ответа, отношения портятся, а по некоторым контрактам могут начисляться штрафы за каждый день просрочки.

4. Допущения: три предположения вместо недостающих данных

Без доступа к реальным данным я зафиксировал допущения явно: что предположил, почему и как проверил бы.

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

5. Сценарии: три ситуации, в которых расхождение стоит дорого

6. Приоритизация: все три сценария упираются в один экран

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

• Сценарий 1 — редкий, но дорогой за случай: один сорванный платёж превращается в пеню и задержку поставки.
• Сценарий 2 — частый и дешёвый за случай, но 34 повтора складываются в 100+ минут рутины.
• Сценарий 3 — не про частоту, а про риск решения без истории.

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

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

7. Формулировка проблемы: система показывает факт, но не источник

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

8. Решение: объяснение рядом с данными, а не в соседнем окне

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

Модель сигналов

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

Экран 1. Карточка исключения

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

Гипотеза: если показывать вероятную причину прямо у строки, время на понимание причины сокращается: специалисту не нужно вручную восстанавливать картину по нескольким документам.

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

Анатомия исключения

Каждый блок на этом экране отвечает на вопрос, который иначе AP-специалист искал бы по вкладкам, письмам и сторонним каналам. Каждый блок на этом экране отвечает на вопрос, который иначе AP-специалист искал бы по вкладкам, письмам и сторонним каналам.

Запустите пошаговый разбор экрана. Запустите пошаговый разбор экрана.

Разобрать экран

Назад Далее

Запустите разбор, чтобы пройти экран шаг за шагом. ← → двигают рамку между шагами · клик по экрану / Esc — выход

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

Экран 2. Очередь исключений и групповая обработка

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

Однотипные исключения можно закрыть одним действием. Группировка строгая: должны совпадать сразу пять признаков — поставщик, тип расхождения, направление отклонения от заказа на закупку, диапазон отклонения и конкретное поле. Нетипичные случаи автоматически исключаются из группы и остаются видимыми отдельно. Группа на сумму выше $50 тыс. или из более чем 20 исключений отправляется на согласование.

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

Экран 3. Профиль поставщика

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

В профиле собраны данные, которые обычно приходится искать в разных местах:

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

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

Основные действия

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

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

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

Допуски

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

9. Компромисс: уверенность как явный статус

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

10. Как я бы мерил успех

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

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

Мост к бизнесу: эти метрики уровня решения — опережающие индикаторы; операционные (время до закрытия, доля эскалаций) — то, во что они конвертируются.