Oyun ve Yazılım Geliştirme Maliyetleri Muhasebede Nasıl İzlenir? 740, 263 ve 15’li Hesaplar Açısından 2026 Rehberi
Giriş ve Arka Plan
Oyun, mobil uygulama, SaaS (software as a service) platformları ve müşteri için geliştirilen özel yazılımlar; hem teknolojik hem de hukuki açıdan karmaşık, uzun soluklu projelerdir. Bu projelerde, aylar hatta yıllar boyunca katlanılan personel, lisans, test, sunucu ve diğer giderler vardır; ancak çoğu zaman henüz gelir oluşmamıştır. İşte tam bu noktada, bu maliyetlerin doğrudan dönem gideri mi yapılacağı, gayrimaddi duran varlık olarak mı aktifleştirileceği yoksa stok hesabında mı izleneceği sorusu kritik hale gelir.
Tek Düzen Hesap Planı’nda (TDHP) hizmet faaliyetleri için 740 Hizmet Üretim Maliyeti hesabı, araştırma-geliştirme niteliğindeki harcamalar için 263 Araştırma ve Geliştirme Giderleri hesabı, tamamlanmış yazılım ve lisanslar için 260 Haklar hesabı ve satılabilir nitelikte ürün-stoklar için 15’li grup (özellikle 153 Ticari Mallar, 151 Yarı Mamuller, 152 Mamuller, 154–155 hizmet stokları vb.) bulunmaktadır. Yazılım projeleri bu hesap gruplarının hepsine birden temas edebilir. Bu nedenle tek bir “doğru” hesap yok; doğru sınıflandırma, projenin niteliğine, ekonomik fayda beklentisine, kontrol ve mülkiyet durumuna ve aktifleştirme kriterlerine göre yapılmalıdır.
Vergi mevzuatı (özellikle Kurumlar Vergisi Kanunu, Gelir Vergisi Kanunu, Vergi Usul Kanunu) ile 5746 sayılı Ar-Ge ve Tasarım Faaliyetlerinin Desteklenmesi Hakkında Kanun, yazılım ve oyun geliştirme projelerinin vergisel teşvikler çerçevesinde değerlendirilmesini gündeme getirmektedir. Ar-Ge niteliği taşıyan projelerde, 5746 sayılı Kanun kapsamındaki Ar-Ge indirimleri, gelir vergisi stopaj teşviki, sigorta primi desteği gibi avantajlardan yararlanılabilmesi için, harcamaların ayrıntılı, proje bazlı ve doğru hesaplarda izlenmesi zorunludur.
Sonuç olarak, oyun ve yazılım geliştirme maliyetlerinin muhasebesi; sadece bir hesap seçimi değil, aynı zamanda finansal tabloların gerçeğe uygun sunumu, vergisel avantajların doğru kullanımı ve olası vergi incelemelerinde ispat kolaylığı açısından stratejik bir karardır.
Düzenlemenin / Yaklaşımın Detayları
Oyun ve yazılım geliştirme faaliyetlerinde uygulamada en sık karşımıza çıkan hesaplar ve kullanım amaçları özetle şöyledir:
- 740 Hizmet Üretim Maliyeti: Müşteri adına, sözleşmeye dayalı olarak verilen yazılım geliştirme hizmetlerinde doğrudan ve dolaylı maliyetlerin izlendiği hesap. Dönem sonunda 741 yansıtma hesabı aracılığıyla 622 Satılan Hizmet Maliyeti’ne veya TMS 2 kapsamında stok hesaplarına aktarılır.
- 750 Araştırma ve Geliştirme Giderleri: 7/A ve 7/B maliyet yönteminde Ar-Ge niteliğindeki giderlerin faaliyet türüne göre toplandığı gider türü hesabıdır. Dönem sonlarında 263 Araştırma ve Geliştirme Giderleri hesabına veya ilgili sonuç hesaplarına devredilir.
- 263 Araştırma ve Geliştirme Giderleri: İşletmenin gelecekte ekonomik fayda elde etme amacıyla yaptığı ve VUK/TMS aktifleştirme kriterlerini sağlayan Ar-Ge ve geliştirme nitelikli harcamaların aktifleştirildiği maddi olmayan duran varlık hesabıdır. Amortisman yoluyla (genelde 5 yıl) itfa edilir.
- 260 Haklar: Tamamlanmış, kullanılmaya veya satılmaya hazır hale gelmiş ve gayrimaddi hak niteliği taşıyan yazılımların, lisansların, patentlerin izlendiği hesap. Yazılım geliştirme projesi tamamlandığında, 263’te biriken aktifleştirilmiş tutar bu hesaba devredilebilir.
- 15’li Hesaplar (Stoklar – Hizmet ve Yazılım Stokları Dahil): TMS 2 Stoklar standardı, henüz hasılatı kaydedilemeyen ancak maliyeti oluşmuş ve gelecekte satışa konu olacak hizmet veya ürünleri stok olarak aktifleştirmeye izin verir. Bu çerçevede yazılım ürünleri, tamamlanmamış veya tamamlanmış hizmet üretim maliyeti gibi 154–155 hesaplarda veya 151–152–153 gibi stok kalemlerinde izlenebilir.
Buradaki ana mesaj şudur: Yazılım geliştirme maliyetlerinde tek bir doğru hesap yoktur. Doğru sınıflandırma için şu sorular sorulmalıdır:
- Proje müşteri adına hizmet mi, yoksa işletmenin kendi adına ürün/hak geliştirmesi mi?
- Faaliyet Ar-Ge/yenilik projesi mi, yoksa rutin bakım-güncelleme mi?
- Ortaya çıkacak çıktı, stok niteliğinde bir ürün mü, yoksa işletmenin uzun süreli kullanacağı veya lisanslayacağı gayrimaddi hak mı?
- Geliştirilen yazılım üzerinde
kimde? - Gelecekte ekonomik fayda sağlayacağı makul ölçüde güvenilir bir şekilde öngörülebiliyor mu ve maliyetler güvenilir biçimde ölçülebiliyor mu?
Bu sorulara verilen cevaplar, 740 – 750 – 263 – 260 – 15’li hesaplar arasında nasıl bir sınıflandırma yapılacağını doğrudan etkiler.
Uygulamada Faaliyetin Niteliğine Göre Muhasebe Yaklaşımı
Yazılım projelerinde muhasebeleştirme öncesi mutlaka şu ilk ayrım yapılmalıdır:
| Faaliyetin niteliği | Tipik örnek | Muhasebe yaklaşımı (özet) |
| Müşteri adına hizmet üretimi | Belirli bir müşteri için sözleşmeye dayalı oyun modülü, özel CRM, entegrasyon yazılımı geliştirme | 740 Hizmet Üretim Maliyeti hesabında proje bazlı izlenir; gelirle ilişkilendirme, TMS 11/TMS 18/TFRS 15 kapsamında değerlendirilir. Dönem sonunda 622 veya hizmet stok hesaplarına aktarılır. |
| İşletmenin kendi adına oyun veya yazılım geliştirmesi | Şirketin kendi mobil oyununu, SaaS platformunu geliştirmesi | Önce gider/Ar-Ge/geliştirme ayrımı yapılır. Ar-Ge niteliği varsa 750’de toplanıp 263’e aktifleştirilebilir. Proje tamamlanıp gayrimaddi hak oluşursa 260 Haklar hesabına devredilir. |
| Ar-Ge veya yenilik projesi | Yeni oyun motoru, yapay zekâ temelli oyun davranış modülü vb. teknik belirsizlik içeren projeler | 5746 sayılı Kanun, KVK ve ilgili tebliğlerdeki Ar-Ge kriterleri sağlanıyorsa Ar-Ge harcaması olarak takip edilir, 750/263 hesapları ve Ar-Ge teşvikleri gündeme gelir. |
| Rutin bakım, güncelleme, destek | Mevcut oyunun hata düzeltmeleri, küçük görsel güncellemeler, SLA kapsamındaki destek | Genellikle dönem gideri veya hizmet maliyeti olarak 740 (veya doğrudan 770, 760 vb.) hesaplarına alınır; aktifleştirme için ilave ekonomik fayda yaratma kriteri aranır. |
740 Hizmet Üretim Maliyeti Hesabı Ne Zaman ve Nasıl Kullanılır?
740 Hizmet Üretim Maliyeti, hizmet sektöründe üretilen hizmetin maliyetinin izlendiği temel hesaptır. Yazılım geliştirme faaliyeti, belirli bir müşteri sözleşmesine bağlı olarak yürütülüyor ve ortaya çıkan sonuç üzerinde kontrol ve ekonomik fayda müşteriye geçiyorsa, bu faaliyet muhasebe açısından hizmet üretimi olarak değerlendirilir.
Bu durumda tipik uygulama şöyledir:
- Yazılım geliştirici personel brüt ücretleri, sosyal güvenlik işveren payları, proje ile doğrudan ilişkili danışmanlık, test, lisans, sunucu giderleri vb. 740 hesabın borcuna kaydedilir.
- 740 hesabın işleyişinde, maliyetler dönem içinde bu hesapta birikir, dönem sonunda 741 Hizmet Üretim Maliyeti Yansıtma hesabı aracılığıyla 622 Satılan Hizmet Maliyeti hesabına veya TMS 2 kapsamında stok hesabına (154/155) aktarılır.
- Klasik TDHP uygulamasında, 740 hesap bilanço hesabı gibi yıl sonu bakiyesi taşımamalı, dönem sonunda kapatılmalıdır.
Ancak TMS 2 Stoklar standardı, henüz gelir olarak kaydedilemeyen hizmet maliyetlerinin dönem sonunda giderleştirilmeyip, stok olarak aktifleştirilebileceğini belirtmektedir. Buna göre:
- Tamamlanmamış, devam eden yazılım hizmetleri için maliyetler 154 Tamamlanmamış Hizmet Üretim Maliyeti hesabına;
- Tamamlanmış ancak ilgili hasılatı gelecek dönemlerde doğacak hizmetler için maliyetler 155 Tamamlanmış Hizmet Üretim Maliyeti hesabına
aktarılabilir. Böylece dönemsellik ve gelir-gider eşleştirme ilkeleri daha doğru uygulanmış olur.
Eğer verilen hizmet aynı zamanda Ar-Ge niteliği taşıyor ancak sözleşme gereği çıktının mülkiyeti müşteriye geçiyorsa; pratikte harcamalar 740 hesapta proje bazlı izlenmekte, 5746 kapsamındaki teşvikler açısından ayrıca proje dosyaları düzenlenmekte, ancak maliyetin bilançoda 263 hesabında aktifleştirilmesi genellikle tercih edilmemektedir; çünkü varlık üzerindeki kontrol müşteriye geçmektedir.
263 Araştırma ve Geliştirme Giderleri, 260 Haklar ve 15’li Hesaplarla İlişki
263 Araştırma ve Geliştirme Giderleri hesabı, TDHP açıklamalarına göre; yeni ürün ve tekniklerin geliştirilmesi, mevcutların iyileştirilmesi için yapılan ve gelecekte fayda sağlayacağı öngörülen Ar-Ge harcamalarının aktifleştirildiği hesaptır. Bu hesapta izlenen tutarlar, VUK’a göre genelde 5 yılda eşit taksitlerle itfa edilir.
Yazılım geliştirme projelerinde 263 hesabının kullanımı için temel kriterler özetle şunlardır (TMS/TFRS ve vergi mevzuatındaki aktifleştirme ilkelerinin ortak paydası):
- Harcamalar, ayrı olarak tanımlanabilir bir proje kapsamında olmalıdır.
- Projede teknik belirsizlik ve geliştirme unsuru bulunmalıdır (rutin bakım-güncelleme değil).
- İşletme projenin sonucunda ortaya çıkacak yazılım üzerinde kontrole ve ekonomik faydaya sahip olmalıdır.
- Projenin başarılı olacağı ve gelecekte ekonomik fayda sağlayacağı makul ölçüde güvenilir şekilde öngörülebilmelidir.
- Harcamalar güvenilir biçimde ölçülebilmelidir (proje bazlı maliyet takibi).
Bu şartlar sağlanıyorsa, dönem içinde 750 Araştırma ve Geliştirme Giderleri hesabında toplanan maliyetler dönem sonunda 263 hesabına aktarılabilir. Proje henüz tamamlanmamış olsa bile, yukarıdaki kriterleri sağladığı andan itibaren yapılan harcamalar aktifleştirilebilir; öncesi ise genelde araştırma fazı kabul edilip dönem gideri yapılır.
Proje tamamlanıp ortaya ticari bir yazılım ürünü veya lisans verilebilir bir oyun çıktığında artık somut bir gayrimaddi hak söz konusudur. Bu durumda:
- 263 hesabında biriken proje maliyeti, 260 Haklar hesabına devredilerek “yazılım hakkı” olarak takip edilebilir.
- 260 hesapta izlenen tutar, VUK ve TMS’ye göre makul bir ekonomik ömür içinde amortismana tabi tutulur (genellikle 3–5 yıl arasında, projeye göre belirlenmek üzere).
15’li hesaplar (Stoklar grubu) ise; yazılımın stok niteliğinde ürün olması halinde gündeme gelir. Örneğin:
- CD/DVD ortamında, kutulu oyun veya lisans kartı satışı (fiziksel stok),
- Çoklu lisans satışı amaçlı üretilen ve her satışta yeni lisans anahtarı üretilen yazılım paketleri,
- TMS 2 kapsamında tamamlanmış veya tamamlanmamış hizmet üretimi stokları (154–155).
Bu durumda proje maliyetleri, mamul maliyeti veya hizmet üretim maliyeti olarak stok hesaplarına devredilir. Satış oldukça, ilgili stok hesabı alacaklandırılır, 620/622 hesapları borçlandırılır.
Uygulamada Adım Adım Süreç ve Muhasebe Kayıtları
Oyun ve yazılım geliştirme maliyetlerinin muhasebeleştirilmesinde izlenecek adımları, faaliyet niteliğine göre pratik bir süreç olarak şöyle özetleyebiliriz:
Adım 1 – Projenin hukuki ve ekonomik niteliğini tespit
- Müşteri sözleşmeleri, lisans ve fikri mülkiyet sözleşmeleri incelenir.
- Projenin müşteriye hizmet mi, işletmeye ürün/hak mı ürettiği belirlenir.
- Ar-Ge/yenilik unsuru ve teknik belirsizlik düzeyi analiz edilir (5746 ve ilgili tebliğler çerçevesinde).
Adım 2 – Dönem içi giderlerin toplanması
- Müşteri adına geliştirilen yazılımlarda: Geliştirici personel ücretleri, dış danışmanlık, lisans, test ve diğer ilgili giderler 740 Hizmet Üretim Maliyeti hesabına borç; karşı hesaplar 335, 360, 100, 320 vb.
- İşletmenin kendi Ar-Ge projelerinde: Gerçek Ar-Ge niteliğindeki giderler 750 Araştırma ve Geliştirme Giderleri hesabında toplanır; teknik açıdan Ar-Ge niteliği taşımayan bakım-güncelleme türü giderler ise 740 veya 770 gibi dönem gideri hesaplarına kaydedilir.
Adım 3 – Dönem sonu sınıflandırma ve aktifleştirme
- Müşteri adına hizmet ise ve TMS 2’ye göre stok niteliğinde tamamlanmış/tamamlanmamış hizmet söz konusuysa, 740’ta biriken tutarlar 741 aracılığıyla 154/155 hesaplara aktarılabilir.
- Hizmet tamamlanmış ve hasılat aynı dönemde kaydedilecekse, 740’taki maliyetler doğrudan 622 Satılan Hizmet Maliyeti hesabına aktarılır.
- İşletmenin kendi Ar-Ge projesi ise ve aktifleştirme kriterleri sağlanıyorsa; 750’de biriken harcamalar 263 Araştırma ve Geliştirme Giderleri hesabına devredilir.
Adım 4 – Projenin tamamlanması ve gayrimaddi hak / stok ayrımı
- Proje tamamlanıp yazılım kullanıma veya satışa hazır ise ve işletme üzerinde kontrol ve ekonomik faydaya sahipse:
- Uzun süreli lisanslama veya kendi kullanım amacı varsa, 263’ten 260 Haklar hesabına devir yapılır.
- Bir defalık veya kısa vadeli satışlar için “stok niteliğinde ürün” ise, 263’ten 15’li stok hesaplarına devir yapılması değerlendirilebilir.
Adım 5 – Amortisman ve maliyet / giderle ilişkili kayıtlar
- 260 ve 263 hesaplarında izlenen tutarlar için, belirlenen ekonomik ömür üzerinden amortisman ayrılır ve giderleştirilir.
- Stoklara alınan yazılım ürünleri satıldıkça, 620/622 hesaplara maliyet olarak aktarılır.
Örnek Senaryo: Oyun Geliştiren Bir Şirketin Muhasebe Uygulaması
Bu bölümü, rakamlı ve gerçekçi bir örnek üzerinden adım adım ele alalım.
Örnek 1 – Müşteri adına özel oyun modülü geliştirilmesi (740 hesabın kullanımı)
Varsayalım ki ABC Oyun A.Ş., X Teknoloji A.Ş. için sözleşmeye dayalı özel bir oyun modülü geliştirmektedir. Proje süresi 6 ay olup, toplam sözleşme bedeli 1.200.000 TL + KDV’dir. İlk üç ayda gerçekleşen maliyetler şöyledir:
- Yazılımcı personel ücret ve işveren SGK maliyeti: 300.000 TL
- Proje için alınan dış danışmanlık hizmeti: 80.000 TL
- Proje test ortamı için bulut sunucu giderleri: 20.000 TL
- Proje ile doğrudan ilişkili lisans ve araç giderleri: 50.000 TL
Toplam maliyet (ilk 3 ay): 450.000 TL.
Dönem içi kayıtlar (özet):
- Personel giderleri: 740 Hizmet Üretim Maliyeti Hesabı 300.000 TL borç; karşı hesaplar 335, 360, 100 vb. alacak.
- Danışmanlık: 740 Hesap 80.000 TL borç; 320 Satıcılar 80.000 TL alacak.
- Bulut sunucu: 740 Hesap 20.000 TL borç; 320 Satıcılar 20.000 TL alacak.
- Lisans gideri: 740 Hesap 50.000 TL borç; 320 Satıcılar 50.000 TL alacak.
Üç ay sonunda 740 hesapta ilgili proje için 450.000 TL birikmiştir.
Senaryo A – Hizmet henüz tamamlanmadı, gelir kaydedilmedi:
Bu durumda, TMS 2 uyarınca bu maliyetlerin dönem sonunda doğrudan 622’ye aktarılması, hasılat kaydı olmadığı için dönemsellik ilkesini zedeler. Çözüm:
- 740’taki proje maliyetini 741 aracılığıyla 154 Tamamlanmamış Hizmet Üretim Maliyeti hesabına aktarmak.
Bu sayede bilanço tarafında 154 hesabında 450.000 TL tutarında “devam eden proje maliyeti” görünür; gelir oluşmadığından gelir tablosunda henüz maliyet yazılmaz.
Senaryo B – Hizmet tamamlandı, fatura düzenlendi:
Proje 4. ayda tamamlanmış ve 1.200.000 TL + KDV fatura kesilmiş olsun. Bu durumda:
- Gelir kaydı: 120 Alıcılar 1.416.000 TL borç; 600 Yurt İçi Satışlar 1.200.000 TL alacak; 391 Hesaplanan KDV 216.000 TL alacak (varsayım KDV %18).
- Maliyet kaydı: 740’taki 450.000 TL, 741 aracılığıyla 622 Satılan Hizmet Maliyeti hesabına aktarılır.
İlerleyen aylardaki ek maliyetler de 740’ta toplanıp proje tamamlandığında 622’ye aktarılır. Böylece gelir ve maliyet aynı dönemde eşleştirilmiş olur.
Örnek 2 – İşletmenin kendi adına mobil oyun geliştirmesi (263 ve 260 hesapları)
XYZ Games A.Ş., kendi adına geliştireceği ve dünya çapında yayınlamayı planladığı bir mobil oyun projesine başlamıştır. Proje süresi 1 yıldır. İlk yılın harcamaları:
- Oyun tasarım ve yazılım ekibi ücretleri: 1.000.000 TL
- Grafik tasarım dış hizmeti: 300.000 TL
- Sunucu ve test giderleri: 150.000 TL
- Proje yönetimi ve dokümantasyon giderleri: 50.000 TL
Toplam: 1.500.000 TL.
Proje, teknik açıdan yenilik içermekte, şirket bu oyun üzerinden reklam, uygulama içi satış ve lisans gelirleri elde etmeyi planlamaktadır. Proje dosyası, iş planı, gelir projeksiyonları ve teknik dokümantasyon mevcuttur. Yönetim, projenin yüksek olasılıkla tamamlanacağını ve gelecekte ekonomik fayda sağlayacağını öngörmektedir.
Dönem içi gider izleme:
- Ar-Ge niteliği taşıyan harcamalar 750 Araştırma ve Geliştirme Giderleri hesabında toplanır (personel, dış hizmet, sunucu, proje yönetimi vb.).
Yıl sonunda yapılan değerlendirmede yönetim, projenin %70 oranında tamamlandığını ve aktifleştirme kriterlerinin tümünün sağlandığını tespit etmiştir. Buna göre;
- 750’de biriken 1.500.000 TL, 263 Araştırma ve Geliştirme Giderleri hesabına devredilir.
- 263 hesabı, bilançoda “Maddi Olmayan Duran Varlıklar” grubu altında gösterilir.
Ertesi yıl projenin kalan kısmı için 500.000 TL ilave harcama yapılmış ve oyun tamamlanmıştır. Toplam proje maliyeti 2.000.000 TL olmuştur.
Proje tamamlandığında:
- 263’teki 2.000.000 TL, 260 Haklar hesabına devredilir; böylece artık “oyun yazılımı hakkı” olarak takip edilir.
- Şirket, bu hakkın ekonomik ömrünü 5 yıl olarak belirler ve 2.000.000 TL’yi 5 yılda eşit taksitlerle (yıllık 400.000 TL) amortismana tabi tutar.
- Her yıl 400.000 TL amortisman gideri (örneğin 770 Genel Yönetim Giderleri veya 760 Pazarlama Giderleri) kaydedilir.
Böylece, oyun geliştirme maliyeti bir anda giderleşmek yerine, oyunun gelir yarattığı yıllara dağıtılmış olur; bu da hem gerçeğe uygun sunum hem de dönemsellik açısından daha doğrudur.
Örnek 3 – Stok niteliğinde yazılım paketi (15’li hesapların kullanımı)
DEF Yazılım Ltd., kurumsal müşterilere satmak üzere “ERP modülü” içeren bir yazılım paketi geliştirmiştir. Bu yazılım, bir kez geliştirilmekte; ancak her yeni müşteriye lisans satışı yapılmaktadır. Yazılım geliştirme projesi için 1.000.000 TL harcanmış, proje sonunda ürün piyasaya sunulmuştur.
Şirket, yazılımı stok niteliğinde bir ürün gibi değerlendirmek istemektedir. Bu durumda, iki farklı yaklaşım mümkündür:
- Yazılımı 260 Haklar hesabına alıp, her satışta ilgili maliyeti 622’ye dağıtacak bir yöntem kurgulamak (müşteriye özel kurulum ve uyarlama yapılan projelerde yaygın).
- Yazılımı stoklar içinde (örneğin 152 Mamuller veya TMS 2 kapsamında 155 Tamamlanmış Hizmet Üretim Maliyeti) izlemek.
Uygulamada çoğu şirket, ana yazılımı 260 Haklar hesabında, müşteri bazlı kurulum ve uyarlama hizmetlerini ise 740/622 ve gerektiğinde 154–155 hesaplarında izlemektedir. Önemli olan, seçilen yöntemin istikrarlı biçimde uygulanması ve dipnotlarda açıklanmasıdır.
Dikkat Edilmesi Gereken Kritik Noktalar
- (1) Tek bir hesap üzerinden genelleme yapmak hatalıdır
Her yazılım maliyetini otomatik olarak 263’e veya 15’li hesaplara almak; yahut her durumda dönem gideri yapmak doğru değildir. Projenin hukuki ve ekonomik niteliği ayrı ayrı değerlendirilmeli, müşteri hizmeti – kendi ürünü – Ar-Ge projesi ayrımı netleştirilmelidir.
- (2) Aktifleştirme için tüm kriterlerin birlikte sağlanması gerekir
Gelecekte ekonomik fayda sağlayacağı makul ölçüde kesin olmayan, maliyetleri güvenilir biçimde ölçülemeyen, Ar-Ge projesi niteliği taşımayan veya işletmenin kontrolünde olmayan yazılım projelerinde 263 hesabında aktifleştirme yapılması risklidir. İncelemelerde bu tür aktifleştirmeler reddedilebilir.
- (3) 740 hesabının yılsonu bakiyesi bırakılması istisnadır
TDHP’de 740, bir maliyet toplama hesabıdır ve dönem sonunda 741 aracılığıyla sonuç veya stok hesaplarına devredilerek kapatılması esastır. 740’ta sürekli bakiye bırakılması, mali tabloların gerçeğe uygunluğu ve standartlara uyumu açısından sorgulanabilir.
- (4) Ar-Ge teşviklerinden yararlanmak için proje bazlı izleme şarttır
5746 sayılı Kanun kapsamındaki Ar-Ge indirimleri, gelir vergisi stopaj teşviki ve diğer destekler için harcamaların proje bazında, gider türü ayrımına göre (personel, malzeme, dış hizmet, genel gider payı vb.) ayrıntılı olarak izlenmesi gerekmektedir. 750–263–740 gibi hesapların doğru kullanımı, teşviklerin güvenli şekilde uygulanmasını sağlar.
- (5) Yazılım bakım ve güncelleme giderleri genellikle aktifleştirilmez
Mevcut bir oyunun küçük versiyon güncellemeleri, hata düzeltmeleri, güvenlik yaması uygulamaları gibi çalışmalar çoğunlukla “mevcut varlığın performansını korumaya yönelik” gider kabul edilir ve dönem gideri yapılır. Ancak yazılımın kapasitesini, kullanım ömrünü veya gelir yaratma potansiyelini önemli ölçüde artıran büyük çaplı geliştirmeler aktifleştirilebilir.
- (6) Vergi ve finansal raporlama açısından farklı yaklaşımlar olabilir
TMS/TFRS’ye göre aktifleştirilen bazı yazılım geliştirme maliyetleri, vergi mevzuatı açısından doğrudan gider kabul edilebilir veya amortisman süresi farklı belirlenebilir. Bu durumda geçici farklar doğar ve ertelenmiş vergi hesaplaması gündeme gelir. Mali müşavirler her iki çerçeveyi de birlikte değerlendirmelidir.
- (7) Sözleşme hükümleri ve fikri mülkiyet hakları kritik önemdedir
Müşteri adına geliştirilen yazılımda, sözleşme gereği tüm hak ve lisanslar müşteriye devrediliyorsa, projeyi 263/260 hesaplarında aktifleştirmek çoğu durumda uygun değildir; zira işletmenin kontrolü ve ekonomik fayda hakkı bulunmaz. Bu durumda 740/154/155 yaklaşımı tercih edilmelidir.
Mali Müşavirler İçin Yapılması Gerekenler (Aksiyon Listesi)
- Her yeni oyun veya yazılım projesi için proje sınıflandırma formu oluşturmak (müşteri hizmeti / kendi ürünü / Ar-Ge / bakım).
- Sözleşmeleri, lisans ve fikri mülkiyet sözleşmelerini inceleyerek, yazılım üzerindeki kontrol ve mülkiyetin kimde olduğuna dair dosyalama yapmak.
- Ar-Ge niteliği taşıyan projeler için 5746 kapsamındaki Ar-Ge proje dosyalarını, personel listelerini, zaman çizelgelerini, harcama dökümlerini muhasebe kayıtlarıyla uyumlu tutmak.
- 7/A veya 7/B seçimine göre 740, 750 ve diğer gider hesaplarını proje bazlı izleyebilecek bir maliyet muhasebesi altyapısı kurmak.
- Yıl sonlarında, her proje için aktifleştirme kriteri kontrol listesi uygulamak; kriterleri sağlamayan projeleri dönem gideri olarak bırakmak.
- 260, 263 ve 15’li hesaplarda izlenen yazılım varlıkları için ekonomik ömür, amortisman yöntemi ve değer düşüklüğü testlerini (gerektiğinde) dokümante etmek.
- Vergi ve TMS/TFRS uygulamaları arasındaki olası farkları (örneğin amortisman süresi, aktifleştirilen/giderleştirilen tutarlar) tespit ederek geçici fark tablosu ve gerekirse ertelenmiş vergi hesaplaması yapmak.
- Yazılım şirketlerinin yönetimini, satış/pazarlama ve teknik ekipleri; yeni proje başlarken muhasebe ile erken aşamada iletişim kurmaları konusunda bilinçlendirmek (gecikmiş sınıflandırma hatalarının önüne geçmek için).
Sık Sorulan Sorular
Soru 1: Her yazılım geliştirme projesi Ar-Ge midir ve 263’te mi izlenmelidir?
Hayır. Her yazılım geliştirme faaliyeti Ar-Ge niteliği taşımaz. 5746 sayılı Kanun ve ilgili tebliğlere göre Ar-Ge; bilimsel ve teknolojik belirsizlik içeren, sistematik ve planlı faaliyetleri ifade eder. Basit iyileştirme, uyarlama, rutin güncelleme, bakım-destek ve çoğu müşteri için uyarlama projesi Ar-Ge değildir. Ar-Ge kriterlerini karşılamayan projelerde maliyetler genellikle 740, 770 gibi dönem gideri veya hizmet maliyeti hesaplarında izlenir; 263’te aktifleştirme yapılmaz.
Soru 2: Oyun geliştirme maliyetlerini doğrudan gider yazmak yerine neden aktifleştireyim?
Eğer proje, uzun süre gelir yaratacak bir oyun veya yazılım ürünü ortaya çıkarıyorsa ve aktifleştirme kriterleri sağlanıyorsa, maliyetin aktifleştirilmesi; gelirin elde edildiği dönemlere yayılmasını sağlar. Böylece, projenin yapıldığı yıl mali tablolar aşırı zarar göstermez; sonraki yıllarda da suni kâr oluşumu engellenir. Ayrıca bazı teşvik ve destekler, Ar-Ge varlıklarının bilançoda izlenmesi ve belgelenmesine bağlı olabilir.
Soru 3: Müşteriye özel geliştirdiğim yazılımı 260 Haklar hesabına alabilir miyim?
Genellikle hayır. Sözleşme gereği yazılım üzerindeki fikri mülkiyet hakları ve ekonomik fayda müşteriye geçiyorsa, geliştirdiğiniz yazılım sizin bilançonuzda varlık olarak kabul edilmez. Bu nedenle maliyetler 740 Hizmet Üretim Maliyeti hesabında izlenip, 622 Satılan Hizmet Maliyeti veya uygun stok hesaplarına aktarılmalıdır. Ancak bazı karma modellerde, temel yazılım çekirdeği sizin kontrolünüzde kalıp, müşteriye sadece sınırlı lisans veriliyorsa; çekirdek ürün kısmı 260 Haklar hesabında, müşteri özelinde yapılan uyarlama kısmı ise 740/622’de izlenebilir. Bu ayrım sözleşmelere ve gerçeğe uygun duruma göre yapılmalıdır.
Soru 4: Ar-Ge projesi başarısız olursa 263’teki tutar ne olacak?
Eğer daha önce aktifleştirilmiş bir Ar-Ge projesi ekonomik fayda sağlamayacağı anlaşılarak iptal edilirse, 263 hesabında izlenen tutar artık varlık niteliğini kaybeder. Bu durumda söz konusu tutar, sonuç hesaplarına gider olarak aktarılmalı; ayrıca varsa Ar-Ge teşvikleri açısından da gerekli düzeltmeler yapılmalıdır. Uygulamada bu tür projeler için yönetim onayı ve iptal kararları yazılı hale getirilerek dosyalanmalıdır.
Soru 5: Yazılımın amortisman süresini nasıl belirlemeliyim?
Vergi mevzuatında, bilgisayar yazılımları genellikle 3–5 yıl arasında itfa edilmektedir; ancak TMS/TFRS’ye göre ekonomik ömür, varlığın kullanım süresi, teknolojik eskitme hızı, pazardaki rekabet ve ürün yaşam döngüsü dikkate alınarak belirlenmelidir. Örneğin mobil oyunların ekonomik ömrü çoğu zaman daha kısadır; kurumsal ERP yazılımlarının ise daha uzun olabilir. Önemli olan; seçilen sürenin makul, gerekçelendirilmiş ve istikrarlı biçimde uygulanmasıdır.
Sonuç ve Değerlendirme
Oyun ve yazılım geliştirme maliyetlerinde 740, 750, 263, 260 ve 15’li hesapların kullanımı; tek bir şablona indirgenemeyecek kadar çok değişkene bağlıdır. Projenin müşteri adına hizmet üretimi mi, işletme için gelir yaratacak bir gayrimaddi hak mı, yoksa stok niteliğinde tekrarlı satılabilir bir ürün mü olduğu; Ar-Ge niteliği, teknik belirsizlik derecesi, kontrol ve mülkiyet, ekonomik fayda beklentisi ve maliyetlerin ölçülebilirliği gibi unsurlar birlikte değerlendirilmelidir.
Mali müşavirler ve şirket yönetimleri; projelerin en başından itibaren muhasebe ile koordineli çalışmalı, sözleşmeleri ve teknik dokümanları mali tabloların gerçeğe uygun sunumuna hizmet edecek şekilde okumalı, aktifleştirme kararlarını teknik ve hukuki temellere oturtmalıdır. Böylece hem vergi riskleri minimize edilir, hem Ar-Ge teşvikleri etkin biçimde kullanılabilir, hem de yazılım şirketlerinin gerçek performansı finansal tablolara doğru yansıtılabilir.
Yasal Dayanaklar
Bu makalede açıklanan yaklaşım ve örnekler hazırlanırken aşağıdaki temel mevzuat ve düzenlemeler çerçevesi dikkate alınmıştır (tam metinler ve güncel hükümler ilgili resmi kaynaklardan kontrol edilmelidir):
- Tek Düzen Hesap Planı ve Hesap Planı Açıklamaları (özellikle 260 Haklar, 263 Araştırma ve Geliştirme Giderleri, 740 Hizmet Üretim Maliyeti hesapları).
- TMS/TFRS düzenlemeleri – TMS 2 Stoklar standardı (tamamlanmamış ve tamamlanmış hizmet maliyetlerinin stok olarak aktifleştirilmesi ve 154–155 hesapların kullanımı).
- 5746 sayılı Araştırma, Geliştirme ve Tasarım Faaliyetlerinin Desteklenmesi Hakkında Kanun ve ilgili uygulama yönetmelikleri, tebliğler (Ar-Ge faaliyet tanımı, Ar-Ge harcamalarının kapsamı, teşvik mekanizmaları).
- Kurumlar Vergisi Kanunu, Gelir Vergisi Kanunu, Vergi Usul Kanunu (amortisman, gayrimaddi haklar, Ar-Ge indirimi ve giderleştirme hükümleri).
- İlgili diğer ikincil mevzuat, genel tebliğler, özelgeler ve meslek literatürü (özellikle yazılım ve oyun sektörüne ilişkin örnek uygulamalar).
Uygulamada her şirketin proje yapısı, sözleşmeleri ve iş modeli farklı olduğundan; somut olay bazında ek mevzuat incelemesi ve gerektiğinde idare görüşü (özelge) alınması önem taşımaktadır.