Проверка рамки
Публикация о расчёте выплаты не заменяет бухгалтерский учёт и не устанавливает действующий тариф площадки. Перед разбором выберите один кабинет, одну валюту и один законченный период. Если продавец работает сразу на нескольких площадках, держите отдельные выгрузки и правила для каждой: похожие названия удержаний могут обозначать разные услуги. Даже внутри одной площадки условия меняются по категориям и дате, поэтому результат модели не должен автоматически становиться проводкой или претензией.
Начните с документа, а не с претензии
Продавец видит продажи на одну сумму, а выплата приходит меньше. Разница не обязательно ошибка площадки: в ней могут быть комиссия, доставка, хранение, возвраты, штрафы и перенос операций с прошлого периода. Попросить нейросеть сразу написать жалобу — соблазнительно, но такой черновик легко обвинит не того адресата. Сначала выгрузите отчёт за конкретный расчётный период и сохраните его исходную версию. Запишите дату выгрузки, валюту, идентификатор кабинета и правило, по которому операция попала в период. Если интерфейс показывает предварительные цифры, не называйте их окончательными. Для пилота достаточно обезличенного файла без персональных данных покупателей.
Сделайте собственную арифметику
Составьте контрольное уравнение: начисления по заказам минус известные удержания плюс корректировки прошлых периодов должны объяснить сумму к выплате. Не смешивайте количество заказов, сумму продаж и фактически доступные деньги. Площадка может отражать возврат в одном периоде, а связанную продажу — в другом. Поэтому каждой строке нужны тип операции, дата события, дата расчёта, заказ или партия и знак суммы. ИИ попросите только привести подписи к единой форме и показать строки без объяснения. Итоговые суммы лучше пересчитать формулой таблицы. Модель нередко красиво пересказывает числа, но ошибается в знаке или дважды учитывает комиссию.
Сопоставляйте по ключу, не по похожему названию
У одного товара может быть несколько артикулов, карточек и комплектаций. Сопоставление по названию «кружка белая» ненадёжно: это может быть другой объём или набор. Используйте идентификатор заказа и SKU, а при отсутствии связки оставляйте строку спорной. В запросе к модели отдельно укажите: «Не объединяй строки только по сходству текста; покажи предложенную пару и основание». Это тот же принцип, что в гайде о сверке счёта и накладной: похожая подпись не заменяет первичный ключ и фактическую поставку.
Выведите расхождения в отдельный список
После механической сверки останутся несколько типов вопросов. Одни операции отражены дважды; другие не найдены в выгрузке заказов; третьи появились с новым тарифом. Для каждого пункта запишите исходную строку, ожидаемую формулу, фактическую сумму и ссылку на применимое условие площадки. Не просите модель оценивать законность удержания: правила меняются, а сведения в чате могут быть устаревшими. Пусть она оформит короткий список вопросов для человека, который проверит актуальный тариф и дату его действия. Важная пометка — уверенность: «арифметическое расхождение подтверждено» не равно «площадка начислила неправильно».
Проверьте три заказа руками
Выберите обычный заказ, возврат и заказ с дополнительной логистикой. Пройдите путь от карточки продажи до строки итогового отчёта. Посчитайте комиссию и удержание отдельно. Если контрольный образец не сходится, не загружайте в модель тысячи строк ради массовой обработки — масштаб лишь размножит ошибку правила. Необходимо понять, какие суммы указаны с налогом, какие без него и где происходит округление. Для договорных ставок сохраните скрин условий с датой или официальный документ; устное «обычно берут столько» не годится. Проверяющий бухгалтер утверждает метод расчёта прежде, чем автоматизация получает зелёный свет.
Сформулируйте обращение по фактам
В поддержке легче разбирать конкретный номер операции, период и две сопоставленные суммы, чем абзац о том, что «ИИ нашёл мошенничество». Короткое обращение: «По заказу … в отчёте от … указано удержание …; по применимому тарифу на дату события ожидаем …; просьба объяснить расчёт или указать основание корректировки». Прикладывайте только необходимые строки, не полный реестр покупателей. Если площадка ответила новой версией отчёта, сохраните обе версии и сравните. Упоминать модель в претензии не требуется: ответственность за цифры несёт компания-продавец.
Оцените пользу процесса
Для проверки возьмите три уже закрытых периода, где известна итоговая причина расхождений. Сколько реальных ошибок ИИ помог быстро вывести на поверхность? Сколько ложных вопросов возникло из-за сдвига периода или неправильной ставки? Сколько минут бухгалтер потратил на проверку машинной таблицы? Хороший результат — не число найденных «подозрительных» строк, а сокращение времени до объяснённой выплаты без новых финансовых ошибок. В разборе меняющегося остатка показано, как статус и время источника меняют ответ; у расчётного отчёта это не менее важно.
Вывод и вопросы
ИИ здесь нужен для нормализации названий операций и подготовки списка исключений. Арифметика, актуальный тариф и решение об обращении остаются у людей. **Можно ли доверить модели финальную сумму?** Нет, финал нужно сверить формулами и исходным отчётом. **Нужно ли загружать данные покупателей?** Для такой сверки обычно достаточно обезличенных идентификаторов. **Когда писать в поддержку?** Когда по конкретным операциям собраны период, ключ, расчёт и действующее условие. **Что делать при изменении отчёта?** Хранить обе версии и отдельно фиксировать, какая строка и почему изменилась.