# AI video iş logları faturayla nasıl uzlaştırılır? > İç operasyon ID'leri, sağlayıcı ID'leri, model parametreleri, kullanım birimleri, zamanlar ve fatura boyutları olan değişmez deneme defteriyle maliyeti uzlaştırın. Fatura satırlarını aynı birimlere normalize edin, önce kesin ID'leri eşleştirin ve yalnız gerçek istisnaları manuel incelemeye gönderin. # AI video iş logları faturayla nasıl uzlaştırılır? Fatura uzlaştırma ilk video üretilmeden başlar. Loglarda yalnız prompt ve başarı bayrağı varsa sonraki fatura müşteri, kampanya, çıktı veya retry'a güvenle atanamaz. Eksik halka ticari kimlik ile sağlayıcının fatura kimliğini saklayan değişmez deneme defteridir. Amaç tüm kaynakları tek ham biçime zorlamak değildir. Kaynak kanıtı koruyun, ortak maliyet şemasına normalize edin, önce yüksek güvenli kayıtları eşleştirin ve kalanı ayırın. İyi aylık kapanış normal farkları otomatik açıklar ve inceleyene kısa istisna listesi verir. ## Uzlaştırılan nesneleri tanımlayın Üretim işi ve faturalanabilir deneme aynı değildir. İstenen ürün videosu onaydan önce birkaç üretim gerektirebilir. En az şunları kullanın: * hedef teslimat için operasyon; * her sağlayıcı gönderimi için deneme; * her medya varlığı için çıktı; * ölçülen fatura miktarı için kullanım olayı; * fatura satırı veya ücret kaydı; * müşteri, kampanya veya maliyet merkezine dağıtım. Bu yapı retry'ların tek `job_cost` içinde kaybolmasını ve üç aday çıktının üç bağımsız talep gibi görünmesini önler. ## Fatura kanıtını istek sırasında yakalayın Loglar döndürülmeden veya dashboard toplulaştırmadan ID ve parametreleri saklayın. | Alan | Örnek | Uzlaştırmadaki rolü | |---|---|---| | İç operasyon ID | `op_01J...` | Maliyeti ticari niyete bağlar | | İç deneme ID | `att_03` | Retry'ları ayırır | | Sağlayıcı iş ID | `job_8f...` | Kesin sağlayıcı eşleşmesi | | Hesap veya proje | `production-us` | Fatura kapsamıyla eşleşir | | Model ID | Kesin sağlayıcı adı | Fiyat boyutunu seçer | | Parametreler | Süre, çözünürlük, oran | Miktar ve oranı açıklar | | Kabul ve bitiş zamanı | UTC | Fatura dönemini hizalar | | Son durum | Tamam, hatalı, iptal | Kuralları test eder | | Kullanım alanları | Saniye, kredi, görüntü, token | Beklenen ücreti hesaplar | | Çıktı checksum'u | SHA-256 | Ücreti varlığa bağlar | Politika izin verirse özgün sağlayıcı yanıtını veya hash adresli düzeltilmiş kopyayı saklayın. Analiz için alanları normalize edin, değerin kaynağını atmayın. ## Sağlayıcıdan bağımsız kullanım şeması kurun Sağlayıcılar üretilen veya istenen saniye, çözünürlük, kredi, çıktı veya başka birimle faturalayabilir. Farklı birimleri `tokens` sütununa sıkıştırmayın. Normalize kullanım olayı şunları korur: * miktar ve birim; * model ve fiyat katmanı; * çözünürlük veya kalite; * para ve oran; * kaynak ve içe alma zamanı; * miktarın raporlanmış veya hesaplanmış oluşu; * kaynak kayıt ID'si; * fiyat sürümü referansı. Özgün birimi sakladıktan sonra paraya çevirin. Sağlayıcı 60 kredi bildiriyor ve fatura krediyi fiyatlıyorsa dashboard dolar tahmini gösterse bile 60 krediyi uzlaştırılan miktar tutun. ## Tahminde kullanılan fiyat kuralını dondurun Bugünkü tahmin fiyat sayfası değişince gelecek ay üretilemeyebilir. Oran, para, geçerlilik zamanı ve boyutu saklayın. ```text beklenen ücret = normalize miktar × geçerli birim oranı ``` Formül yalnız fatura birimi biliniyorsa geçerlidir. Başarısız veya iptal işin sıfır olduğunu varsaymayın; belge veya gerçek fatura kuralı gösterene kadar bilinmeyen tutun. Promosyon kredisi, vergi, taahhüt, indirim ve kur dönüşümünü temel kullanımdan ayırın. Fatura düzeyinde görünebilir ve açıklanmış dağıtım gerektirir. ## Fatura verisini üzerine yazmadan alın Özgün fatura, CSV veya kullanım raporunu checksum ile kalıcı saklayın. Yapısal satırlara ayrıştırın, kaynak satır numarası ve ham değeri koruyun. | Kaynak alan | Normalize alan | |---|---| | İstek veya iş referansı | `provider_job_id` | | Ürün veya model etiketi | `model_id` ve kaynak etiket | | Hizmet dönemi | UTC başlangıç ve bitiş | | Kullanım miktarı | Ondalık miktar ve birim | | Oran | Ondalık tutar ve para | | Ücret | Vergi öncesi satır tutarı | | Kredi veya indirim | Ayrı düzeltme satırı | | Fatura numarası | `invoice_id` | Para için ondalık aritmetik kullanın. Floating-point yüksek hacimde binlerce küçük fark oluşturabilir. ## Güven katmanlarında eşleştirin Bulanık zaman eşleştirmeyle başlamayın. Kesin ID kullanın ve her eşleşme kuralını kaydedin. 1. Doğru hesapta kesin sağlayıcı iş veya istek ID'si. 2. Belgeli idempotency key veya client reference. 3. İşe referans veren kullanım olayı. 4. Hesap, model, gün, birim ve bölgeye göre toplu bucket. 5. Zaman ve parametre benzerliği yalnız istisna kuyruğunda. | Katman | Güven | İşlem | |---|---|---| | Kesin sağlayıcı ID | Yüksek | Otomatik uzlaştır | | Kesin client reference | Yüksek | Benzersizlik sonrası otomatik | | Kullanım olayı köprüsü | Yüksek | Lineage ile otomatik | | Toplu bucket | Orta | Grup toplamlarını uzlaştır | | Zaman-parametre benzerliği | Düşük | Manuel inceleme | Sağlayıcı açıkça toplamadıkça tek fatura satırını birden çok denemeye sessizce atamayın. Aynı ücreti kopyalamak yerine ilişkileri join table'da saklayın. ## Saat dilimi ve dönemi hizalayın 23:59'da gönderilen iş ertesi gün bitebilir ve sağlayıcı kabul, bitiş veya kullanım zamanında faturalayabilir. Tüm operasyonel zamanları UTC, hesap fatura saat dilimini ayrı tutun. Kesin ID yoksa gönderim, kabul, bitiş, kullanım ve hizmet tarihini karşılaştırın. Yayınlanmış zaman kullanımını belgeleyin. Yoksa günlük dağıtımı çıkarım sayın ve daha geniş dönem uzlaştırın. ## Retry, hata ve yinelenen işleri açıklayın Retry görünen fazla faturalamanın yaygın kaynağıdır. Dashboard tek video gösterirken sağlayıcı üç deneme işlemiş olabilir. ```text operasyon maliyeti = tüm üretim denemeleri + depolama + transfer + ilgili işlem ``` Denemeleri sonuç ve nedene göre gruplayın: terminal sağlayıcı hatası, bilinmeyen timeout, istenen varyant, kalite reddi ve yanlışlıkla yinelenen gönderim. İki deneme aynı operasyon anahtarına ancak farklı sağlayıcı ID'sine sahipse birini silmeyin. Yinelenme ilişkisini işaretleyip iki ücreti koruyun; önleme ve meşru fatura sorusu için kanıttır. ## Sistematik sapmayı gizlemeden tolerans kullanın Ucuz işler için küçük mutlak, büyük ücretler için yüzde toleransı belirleyin. Tam eşleşme, oran farkı, miktar farkı, dönem kayması, yalnız faturadaki ücret, yalnız logdaki deneme, dağıtılmamış indirim ve para-vergi farkı olarak sınıflayın. Tek satırlar tolerans içinde olsa da toplu sapmayı inceleyin. İş başına centin kesri ölçekte maddi olabilir ve yanlış oran veya yuvarlamayı gösterebilir. ## Kontrol raporu üretin | Kontrol | Hedef sonuç | |---|---| | Fatura toplamı | Uzlaştırılan ve çözülmeyen ücrete eşit | | Kullanım miktarı | Model ve birime göre uyumlu | | Kesin ID kapsamı | Yüksek ve kararlı | | Eşleşmeyen değer | Onaylı eşikten düşük | | Yalnız log denemeleri | Zaman veya politika ile açıklanmış | | Yinelenme maliyeti | Neden ve sahibi atanmış | | Fiyat farkı | Oran sürümü veya sözleşmeyle destekli | Onaydan sonra dönemi kilitleyin. Geç düzeltmeler yeni kayıt olarak girsin, geçmişi üzerine yazmasın. ## Atıf kaybetmeden entegrasyonu birleştirin [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=reconcile-ai-video-job-logs-with-invoice) metin, görüntü ve videoyu tek OpenAI uyumlu platform ve fatura ilişkisiyle kolaylaştırabilir. Birleşme sağlayıcı raporlarını azaltır, ancak atıf uygulamanın kaydettiği ID'lere bağlıdır. Her adaptörde iç operasyon ve deneme ID'sini koruyun. Gateway API'yi normalize etse bile kesin model, parametre ve sağlayıcı referansını saklayın. Tek fatura, ücretler ürün, müşteri ve varlığa izlenebiliyorsa kolaydır. ## Sonuç Fatura verisi gelmeden kalıcı deneme defteri kurarak AI video faturalarını uzlaştırın. İç ve sağlayıcı ID'lerini koruyun, özgün birimleri kaybetmeden kullanımı normalize edin, önce kesin referansları eşleştirin ve retry'ları hedef teslimattan ayırın. Açık tolerans, güven katmanları ve kontrollü istisna kuyruğu finansın faturayı kapatmasını, mühendisliğin maliyet nedenlerini görmesini sağlar. ## FAQ ### Video fatura uzlaştırmasında en önemli kimlik nedir? Hem iç operasyon ID'sini hem sağlayıcı iş veya istek ID'sini saklayın. İç ID ticari amacı açıklar; sağlayıcı ID'si kullanım ve faturalamayla en güçlü bağlantıdır. ### Başarısız video işleri uzlaştırma defterinde olmalı mı? Evet. Kurallar model ve hata türüne göre değişebildiği için her deneme ve terminal durumu kaydedin. Belge veya fatura doğrulamadıkça başarısız işi ücretsiz saymayın. ### Yalnız günlük toplam içeren fatura nasıl uzlaştırılır? Normalize kullanımı aynı hesap, gün, model, bölge, para ve birime göre toplayıp karşılaştırın. Daha düşük güvenli sonucu kesin iş eşleşmesinden ayrı tutun. ### Maliyet farkı için yararlı tolerans nedir? Kur yuvarlama, rapor gecikmesi ve hacme göre açık mutlak ve yüzde tolerans belirleyin. Tek tek farklar küçük olsa da sistematik sapmayı araştırın. ### Retry ayrı işler olarak sayılmalı mı? Tek üretim operasyonu tutun, her üretim denemesini ayrı kaydedin. Böylece hedef teslimatla ilişki korunurken retry maliyeti görünür. ### Tek gateway modeller arası uzlaştırmayı kolaylaştırır mı? Atlas Cloud model kullanım ve faturayı birleştirebilir, fakat ücretleri ürün, kampanya ve çıktılara bağlamak için uygulama iş ID'leri ve parametrelerini saklamalıdır.