Cloud faturanızın yarısını devletten hibe olarak geri almak? O kadar kolay mı?

Bir bilişim firmasının gider tablosuna baktığınızda, personel ve pazarlama giderinden sonra en büyük kalemi muhtemelen bulut oluşturuyor. Bu giderin büyümesi işlerin iyi gittiği anlamına gelir; ama sonuçta bu bir maliyettir. AWS, Azure, Google Cloud, Hetzner, üstüne son bir yıldır GPU sağlayıcılarına ödenen ücretler rahatsız edici boyutlara ulaşmakta. Bu firmaların verdiği krediler tükeniyor, sistemleri optimize ederek maliyeti azaltan sistemciler bir yere kadar katkı sağlayabiliyor. Dolayısıyla devlet teşvikleri büyüme sürecinde önemli bir yardımcı oluyor.

Peki teşvikle geri alınabildiği iddia edilen bu harcamaların %50’sini geri almak kolay mı? Maalesef değil.

Kural olarak ihracatçı bilişim firmalarının barındırma desteği kapsamında, uygun bulut/sunucu harcamalarının %50’si, firma başına yılda 5 milyon TL’ye kadar destekleniyor. Bu bilişim firmalarına verilen milyonlarca TL desteklerden yalnızca birisi. Rakam iştah açıcı. Sorun rakamda değil, o rakama ulaşan yolda.

Kapsamda kim, ne var?

Destekten bilişim şirketleri yararlanıyor: yazılım, mobil uygulama ve oyun stüdyoları. Kapsamdaki harcama da göründüğünden geniş:

• Klasik sunucu, hosting, IaaS/PaaS bulut hizmetleri. Barındırma desteğinin tam merkezi burası — AWS, Azure, Google Cloud sunucu giderleri tartışmasız kapsamda.
• Ve çoğu firmanın gözden kaçırdığı kısım: GPU üzerinde barındırma. Ama burada bir incelik var ve dosyanın kaderi bu inceliğe bağlı: her “inference” harcaması aynı şey değildir. Talep edilebilir olan, kendi uygulamanızın çalışır tutulmasıdır; hazır bir modele çağrı yapıp çıktı satın almak değil.

AI ağırlıklı ürünlerde bu ikinci kalem hızla büyüyor ve zaman zaman klasik sunucu giderini geçiyor. Bir görsel/video üretimini ya da LLM tabanlı bir özelliği sunucu tarafında çalıştırıyorsanız, bu harcamanın barındırma desteği kapsamında değerlendirilebileceğini büyük ihtimalle kimse size söylemedi. Ama söylediğimiz gibi — burada bir çizgi var, ve o çizgi göründüğü yerde durmuyor. Buna birazdan geleceğiz.

İnceleyici otorite dosyada ne arıyor?

Yüzlerce dosyanın ardından red sebepleri birkaç başlıkta toplanıyor. Neredeyse hiçbiri “bu harcama uygun değil” değil. Hepsi “bu dosya bunu kanıtlayamıyor.”

1. Kapsam uyuşmazlığı. Aynı faturada destek kapsamındaki ve kapsam dışındaki kalemler bir arada. Yönetilen veritabanı, CDN, üçüncü taraf lisans/abonelik, marketplace üzerinden alınan yazılım… Fatura kalem kalem ayrıştırılmadığında, kapsam dışı tek bir satır yüzünden faturanın tamamı reddedilebiliyor.
2. Fatura kalitesi. Kırılımsız, tek satırlık konsolide fatura. Muğlak hizmet tanımı. Fatura–ödeme–banka dekontu zincirinin kopuk olması. Ön ödemeli bakiye modelinde ödemenin hangi döneme ait olduğunun gösterilememesi.
3. Taraf ve mukimlik. Reseller ya da partner üzerinden alım yaptığınızda “hizmeti gerçekte kim sağlıyor?” sorusu. Yurt içi mukim bir iştirakten ya da grup içinden alım. Bunlar dosyada açıkça kurulmadığında takılıyor.
4. Ürün ayrıştırmasının yapılamaması. En sık ve en pahalı hata. Her ürün için ayrı başvuru yapılıyor — ama tek bir bulut hesabından çıkan tek fatura, üç ürün için birlikte sunulduğunda dosya ayakta duramıyor. Bu konu o kadar kritik ki ayrı bir bölümü hak ediyor.
5. Usul. Süre, ön onay/DYS akışı, üyelik, eksik evrak. Sıkıcı ama acımasız: kaçırılan sürenin telafisi yok.
6. Teknik anlatımın olmaması. Dosyayı inceleyen kişi, aldığınız hizmetin teknik olarak ne olduğunu ve hangi ürününüze hizmet ettiğini dosyadan anlayamıyor. Sizin için apaçık olan şey, dosyada yazılı değilse yok hükmünde.

Asıl mesele: bulut faturasını ürün bazında ayrıştırmak

Her ürün ayrı bir başvuru demek. Beş oyununuz varsa beş dosya. Ve her dosya yalnızca o ürüne ait harcamayı gösterebilmeli.

Şöyle düşünün: tek bir elektrik sayacı olan çok katlı bir binada faturayı her daireye adil bölüştürmek gerekiyor. En temizi her dairenin kendi sayacının olması; o yoksa, önceden üzerinde anlaşılmış ve savunulabilir bir bölüşüm kuralı şart. Herkes taşındıktan aylar sonra “sanırım üçüncü kat şu kadar harcamıştı” demek kimseyi ikna etmez.

Bulut faturasında da durum aynı. En yaygın yanılgı, ayrıştırmayı sonradan yapılacak bir muhasebe işlemi sanmak. Değil. Ayrıştırma bir mimari karar ve doğru zamanı harcamadan sonra değil, öncesidir. Fatura kesildikten sonra “şu kadarı bu oyuna aitti” demeye çalışmak, dosyayı en zayıf haline getirir.

İşin özü şu kanıt hiyerarşisi:

Kademe	Nasıl ayrıştırıldı	Kanıt gücü
1	Sağlayıcı her ürün için ayrı fatura kesiyor	En güçlü
2	Tek fatura, ama fatura üzerinde ürün bazlı bölüm/kalem	Güçlü
3	Tek fatura + sağlayıcının resmî kullanım raporu (fatura toplamıyla birebir mutabık)	Savunulabilir
4	Tek fatura + şirket içi dağıtım anahtarı	Zayıf — yazılı metodoloji şart

Hangi kademede olursanız olun, sağlam bir ayrıştırma üç şeyi birden sağlar: fatura toplamıyla kuruşu kuruşuna tutar, sizden bağımsız biri tarafından tekrar üretilebilir, ve harcamadan önce yazıya dökülmüş bir mantığa dayanır.

Her sağlayıcının kendine göre bir zorluğu var

AWS

AWS, “ayrı sayaç” takmaya en elverişli sağlayıcılardan. En temiz yol, AWS Organizations altında her ürün için ayrı bir linked account açmaktır. Fatura tek bir payer account’ta toplansa bile, Cost and Usage Report (CUR) her hesabın harcamasını birebir ayrıştırabilirsiniz — böylece  kanıt hiyerarşisinin en üst basamağı sağlanmış olur (kademe 1). İkinci yol Cost Allocation Tags ve Cost Categories kullanmaktır; ama burada çok kaçırılan bir şey var: etiketlerin Billing konsolundan aktive edilmesi gerekmekte ve aktivasyondan önceki döneme geriye dönük işlememektedir. Yani etiketlemeye bugün başlarsanız, geçmiş harcamalar için kapı çoktan kapanmış olabilmektedir.

Azure

Azure’da fatura hiyerarşisi, ayrıştırmayı doğrudan faturanın üzerinde yapmaya izin vermektedir. Microsoft Customer Agreement altındaki Billing Profile / Invoice Section kurgusu, tek faturanın içinde ürün bazlı bölümler üretmektedir (kademe 2). Alternatif olarak her ürüne ayrı Subscription açılabilmektedir. En kolayı distribütör/partner üzerinden alıyorsanız, partnerdan abonelik bazında ayrı fatura talep edebilirsiniz — çalıştığımız partnerların bunu sağladığını görüyoruz.

Google Cloud

Google Cloud’da en temiz yol, her ürün için ayrı bir Cloud Billing Account’tır — bu da ürün başına ayrı fatura, yani kademe 1 demektir. Daha hafif yol ise her ürüne ayrı Project açıp BigQuery billing export üzerinden labels ile kırılım almaktır.

Hetzner

Hetzner bu işin en kolay tarafı. Proje başına ayrı fatura kesebildiği için, doğru kurulmuş bir hesapta kanıt zaten faturanın içinde gelebilmektedir.; fazladan bir mimari gayret gerekmez. Sayaç benzetmesinde, her daireye baştan ayrı sayaç takılmış gibi düşünün.

OVH / DigitalOcean

Bu sağlayıcılarda konsolun ayrıştırma yeteneği daha sınırlıdır. En sağlam pratik çözüm, her ürün için ayrı bir müşteri hesabı açmaktır. Bu mümkün değilse, harcamadan önce kurulmuş bir sunucu isimlendirme standardı (örneğin oyunadi-prod-01) ve fatura kalemlerinin bu isimlerle eşleştirilmesi işi görür — yeter ki bu standart harcamadan sonra uydurulmuş değil, baştan kurgulanmış olsun.

fal.ai ve GPU/inference sağlayıcıları

Bu tür sağlayıcılarda dosyayı ayakta tutan tek hamle, faturayı ekonomik niteliğine göre ikiye bölmektir. Benzetmeyle: bir atölye kiralayıp kendi makinelerinizi orada çalıştırmak ile hazır bir ürünü başkasının fabrikasından sipariş etmek arasındaki fark. İlkinde mekân kirası ödersiniz ama üretim sizindir; ikincisinde yalnızca çıktının parasını ödersiniz. Yalnızca ilki barındırmadır.

Barındırma (talep edilir): Kendi kodunuzun ya da modelinizin sağlayıcının GPU’larında dağıtılıp (deployment) çalışır tutulması. fal.ai faturasında bu, Cloud Hosting Services kalemine karşılık gelmektedir. Ölçü birimi “ay” yerine “GPU-saniye” olsa da ekonomik nitelik birebir aynıdır: uygulama çalışabilsin diye sunucu (GPU) kapasitesi kiralanmaktadır.

API tüketimi (desteklenmez): Sağlayıcının hazır (marketplace) modellerine yapılan çağrıların çıktı bedeli — fal.ai’de Endpoint Output, Compute Seconds, Request Count gibi kalemler. Bu, sizin yazılımınızın barındırılması değil, bir dış hizmetin tüketimidir; barındırma niteliği taşımamaktadır..

Bu ayrım kritik, çünkü “sunucusuz (serverless)” ifadesi “sunucu yok” demek değildir. Fiziksel GPU’ların kurulumunu ve ölçeklenmesini sağlayıcı üstlenir; ama üzerinde çalışan yine sizin yazılımınızdır. Barındırılan şey sizin uygulamanızdır.

Ürün ataması ise kalem adlarından yürümektedir. İyi kurulmuş bir düzende her ürünün deployment’ı adında ürün adını taşımaktadır (urunadi-workflow-…) — bu, AWS tarafındaki “uygulama adına göre kullanım” etiketlemesinin fal.ai karşılığıdır. Böylece Cloud Hosting Services içinden yalnızca ürün adını taşıyan satırlar talep edilebilmektedir; paylaşımlı havuzları, ara katmanları ve diğer ürünleri dışarıda bırakıp; bir mutabakat tablosuyla “toplam = talep edilen + talep dışı” eşitliğini gösterebilirsiniz.

Küçük ama pahalı bir detay: Türkçe dil desteği

Mevzuat gereği, Türkçe dil desteği bulunan yazılım, uygulama ve oyunlar destekten %50 yerine %25 oranında yararlanır. Türkiye pazarında kullanıcısı olmayan, tümüyle yurt dışına satış yapan bir ürün için bu, üzerine ciddi biçimde düşünülmesi gereken bir tercih hâline gelmektedir. Küçük görünen böyle detaylar, yıllık destek tutarında hatırı sayılır fark yaratabilmektedir.

Sonuç

Baştaki soruya dönelim: cloud faturanızın yarısını hibe olarak geri almak kolay mı? Hayır. Ama imkânsız da değil — ve zorluğun neredeyse tamamı harcamanın uygunluğunda değil, dosyada.

Aynı harcama, iki firmada iki farklı sonuç doğuruyor: birinde milyonlarca liralık destek, diğerinde bir red mektubu. Aradaki farkı yaratan bütçe değil; faturanın harcamadan önce doğru kurgulanması, her sağlayıcının kendine özgü tuzağının önceden bilinmesi, barındırma ile tüketim çizgisinin doğru yere çekilmesi ve tüm bunların inceleyici otoritenin diliyle belgelenmesi.

Finahukuk’un yaklaşımı tam da burada ayrışıyor. Biz bir dilekçe bürosu değiliz; işi tersinden kurarız. Desteğin dosyasını harcama yapılmadan önce tasarlar, teknik gerekçeyi hem mühendisin hem inceleyicinin anlayacağı dille yazar, reddedilmiş dosyaları itirazla yeniden ayağa kaldırırız. Ve en önemlisi: kurgu bir kez doğru oturduğunda, destek her yıl kendiliğinden işleyen, tekrarlayan bir gelir kalemine dönüşmektedir.

Karmaşık görünüyorsa, en basit yerden başlayalım: son 12 ayın bulut faturalarını bir araya getirin. Kapsama giren kalemleri işaretleyip ürün bazlı ayrıştırmanın mevcut kurgunuzla mümkün olup olmadığını birlikte çıkaralım. Size maliyeti yok; çıkanı görünce kararı siz verirsiniz.