# Как сверить журналы заданий AI-видео со счетом? > Сверяйте расходы по неизменяемому журналу попыток с локальными ID операций, ID провайдера, параметрами модели, единицами использования, временем и измерениями оплаты. Нормализуйте строки счета в те же единицы, сначала сопоставляйте точные ID и направляйте вручную только реальные исключения. # Как сверить журналы заданий AI-видео со счетом? Сверка счета начинается до первой генерации. Если журналы содержат только промпт и флаг успеха, поздний счет нельзя надежно отнести к клиенту, кампании, результату или повтору. Нужен неизменяемый журнал попыток, хранящий бизнес-идентичность и платежную идентичность провайдера. Не требуется приводить все источники к одному сырому формату. Сохраняйте исходные доказательства, нормализуйте их в общую схему затрат, сначала сопоставляйте записи высокой уверенности и изолируйте остаток. Хорошее ежемесячное закрытие объясняет обычные расхождения автоматически и дает короткий список исключений. ## Определите объекты сверки Производственное задание и оплачиваемая попытка — разные сущности. Одному товарному видео может понадобиться несколько генераций до утверждения. Используйте минимум: * операцию для задуманного результата; * попытку для каждой отправки провайдеру; * результат для каждого медиафайла; * событие использования для измеренной единицы оплаты; * строку счета или запись платежа; * распределение затрат по клиенту, кампании или центру. Так повторы не исчезают в одном `job_cost`, а три кандидата не становятся тремя несвязанными бизнес-запросами. ## Фиксируйте платежные доказательства при запросе Сохраняйте ID и параметры до ротации логов и агрегации в панели провайдера. | Поле | Пример | Роль в сверке | |---|---|---| | Внутренний ID операции | `op_01J...` | Связывает затраты с деловой целью | | Внутренний ID попытки | `att_03` | Разделяет повторы | | ID задания провайдера | `job_8f...` | Точное совпадение | | Аккаунт или проект | `production-us` | Совпадает с областью оплаты | | ID модели | Точное имя провайдера | Выбирает ценовое измерение | | Параметры | Длительность, разрешение, формат | Объясняют количество и ставку | | Время приема и завершения | UTC | Выравнивает период | | Итоговое состояние | Готово, ошибка, отменено | Проверяет правила оплаты | | Использование | Секунды, кредиты, изображения, токены | Рассчитывает ожидаемый платеж | | Контрольная сумма | SHA-256 | Связывает платеж с ресурсом | Сохраняйте исходный ответ провайдера или отредактированную копию с адресацией по хешу, если политика разрешает. Нормализуйте поля, но не уничтожайте источник их происхождения. ## Создайте нейтральную схему использования Провайдеры могут брать плату за созданную или запрошенную секунду, разрешение, кредиты, готовый результат или другую единицу. Не сводите разнородные единицы в столбец `tokens`. Нормализованное событие сохраняет: * количество и единицу; * модель и тариф; * разрешение или качество; * валюту и ставку; * время источника и загрузки; * признак сообщенного или вычисленного количества; * ID исходной записи; * ссылку на версию цены. В деньги переводите после сохранения исходной единицы. Если отчет содержит 60 кредитов и счет тарифицирует кредиты, оставьте 60 кредитов сверяемым количеством даже при показе оценки в долларах. ## Фиксируйте правило цены для оценки Сегодняшний расчет может не воспроизвестись после изменения страницы цен. Сохраняйте ставку, валюту, время действия и измерение. ```text ожидаемый платеж = нормализованное количество × действующая ставка ``` Расчет верен только при известной оплачиваемой единице. Не считайте ошибку или отмену бесплатной; оставляйте платеж неизвестным до подтверждения документацией или фактическими данными. Отделяйте промокредиты, налоги, обязательства, скидки и конвертацию от базового использования. Они могут появляться на уровне счета и требовать объявленного распределения. ## Загружайте счет без перезаписи источника Сохраните оригинальный счет, CSV или отчет с контрольной суммой. Разберите на строки, сохранив номера и исходные значения. | Поле источника | Нормализованное поле | |---|---| | Ссылка на запрос или задание | `provider_job_id` | | Название продукта или модели | `model_id` и исходное название | | Период услуги | Начало и конец UTC | | Использование | Десятичное количество и единица | | Ставка | Десятичная сумма и валюта | | Платеж | Сумма до налогов | | Кредит или скидка | Отдельная корректировка | | Номер счета | `invoice_id` | Для денег используйте десятичную арифметику: плавающая точка порождает тысячи мелких расхождений при большом объеме. ## Сопоставляйте по уровням уверенности Не начинайте с нечеткого времени. Используйте точные ID и записывайте правило совпадения. 1. Точный ID задания или запроса в правильном аккаунте. 2. Документированный ключ идемпотентности или клиентская ссылка. 3. Событие использования со ссылкой на задание. 4. Агрегированный сегмент по аккаунту, модели, дню, единице и региону. 5. Время и параметры только для очереди исключений. | Уровень | Уверенность | Обработка | |---|---|---| | Точный ID провайдера | Высокая | Автоматически | | Точная клиентская ссылка | Высокая | Автоматически после проверки уникальности | | Связь через использование | Высокая | Автоматически с происхождением | | Агрегированный сегмент | Средняя | Сверить суммы группы | | Сходство времени и параметров | Низкая | Вручную | Не назначайте одну строку нескольким попыткам, если провайдер явно их не агрегирует. Храните связи один-ко-многим в таблице, а не копируйте платеж. ## Выравнивайте часовые пояса и периоды Задание, отправленное в 23:59, может завершиться завтра, а оплата начисляться при приеме, завершении или событии использования. Храните все времена в UTC и отдельно платежный часовой пояс. При отсутствии ID сравнивайте отправку, прием, завершение, событие использования и дату услуги. Документируйте время провайдера. Если оно неизвестно, считайте дневное распределение выводом и сверяйте более широкий интервал. ## Объясняйте повторы, ошибки и дубли Повторы часто выглядят как переплата. В производстве виден один ролик, а провайдер обработал три попытки. ```text стоимость операции = сумма всех генераций + хранение + передача + связанная обработка ``` Группируйте попытки по исходу и причине: финальная ошибка провайдера, неизвестный тайм-аут, запрошенный вариант, отклонение качества и случайный дубль. Если у попыток общий ключ, но разные ID провайдера, не удаляйте одну. Отметьте связь дубля и сохраните оба платежа для улучшения системы и обоснованного запроса по счету. ## Используйте допуски, не скрывая системный дрейф Задайте абсолютный допуск для округления дешевых заданий и процентный — для крупных. Классифицируйте совпадение количества и платежа, разницу ставки, разницу количества, сдвиг периода, строку только в счете, попытку только в логе, нераспределенную скидку и валютно-налоговую разницу. Проверяйте общий дрейф даже внутри допусков. Доля цента на каждом задании становится существенной и может указывать на неверную ставку или округление. ## Создайте контрольный отчет | Контроль | Целевой результат | |---|---| | Сумма счета | Равна сверенным и нерешенным платежам | | Количество использования | Совпадает по модели и единице | | Покрытие точными ID | Высокое и стабильное | | Несопоставленная стоимость | Ниже утвержденного порога | | Попытки только в логе | Объяснены временем или политикой | | Стоимость дублей | Имеет причину и владельца | | Разница цен | Подтверждена версией ставки или договором | После утверждения закройте период. Поздняя корректировка должна быть новой записью, а не молчаливой перезаписью истории. ## Объединяйте интеграцию, не теряя атрибуцию [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=reconcile-ai-video-job-logs-with-invoice) может упростить работу приложения с текстом, изображениями и видео через одну OpenAI-совместимую платформу и оплату. Но атрибуция зависит от ID, записанных приложением. Сохраняйте внутренние ID операций и попыток в каждом адаптере, а также точную модель, параметры и ссылку провайдера. Один счет удобнее только тогда, когда платежи прослеживаются до товаров, клиентов и доставленных ресурсов. ## Итог Сверяйте счета, создавая постоянный журнал попыток до прихода платежных данных. Сохраняйте внутренние и внешние ID, нормализуйте использование без потери исходных единиц, сначала сопоставляйте точные ссылки и отделяйте повторы от задуманных результатов. Явные допуски, уровни уверенности и контролируемая очередь исключений позволяют финансам закрыть счет, а инженерам увидеть источники расходов. ## FAQ ### Какой идентификатор важнее всего для сверки счета за видео? Храните и внутренний ID операции, и ID задания или запроса провайдера. Внутренний объясняет деловую цель, а ID провайдера надежнее всего связывает использование и оплату. ### Нужно ли включать неудачные видеозадания в журнал сверки? Да. Записывайте каждую попытку и ее итог, потому что правила оплаты различаются по моделям и типам ошибок. Не считайте неудачу бесплатной без подтверждения документацией или счетом. ### Как сверить счет только с дневными итогами? Агрегируйте нормализованное использование по тому же аккаунту, дню, модели, региону, валюте и единице и сравните суммы. Отделяйте это менее уверенное сопоставление от точного по заданиям. ### Какой допуск разницы стоимости полезен? Установите абсолютный и процентный допуски с учетом округления валюты, задержки отчетности и объема. Исследуйте систематический дрейф даже при малых отдельных разницах. ### Считать ли повторы отдельными заданиями? Сохраняйте одну производственную операцию, но каждую генерационную попытку записывайте отдельно. Так видна стоимость повторов и связь с задуманным результатом. ### Может ли единый шлюз упростить сверку разных моделей? Atlas Cloud может объединить использование и оплату моделей, но приложение все равно должно хранить ID и параметры заданий для распределения расходов по товарам, кампаниям и результатам.