Teknopark Kazanç İstisnasında Belge Bütünlüğü: Projeden Beyannameye Beşli Kontrol

Teknopark / 4691 / ED@ARGE

Teknopark Kazanç İstisnasında Belge Bütünlüğü: Projeden Beyannameye Beşli Kontrol

E-DENET Mali Müşavirlik | Mevzuat değerlendirme tarihi: 2 Ekim 2026

Teknoparkta yer almak ile her gelirin istisna kapsamında olması aynı şey değildir. Sağlıklı uygulama, projenin teknik kapsamından beyannamedeki kazanç tutarına kadar izlenebilir bir kayıt düzeni gerektirir.

Bir yazılım şirketinin proje dosyası, müşteri sözleşmesi ve faturası ayrı ayrı düzgün görünebilir. Buna rağmen belgeler aynı ekonomik faaliyeti anlatmıyorsa vergi uygulamasını açıklamak güçleşir. Projede yeni bir yazılım modülü geliştirilmesi yer alırken sözleşmede yalnızca personel tahsisi yazması veya faturanın donanım, bakım ve geliştirme bedellerini tek satırda toplaması, inceleme sırasında cevaplanması gereken sorular doğurur.

Bu nedenle Teknopark kazanç istisnasını yalnızca yıl sonunda beyannamede seçilecek bir satır olarak değil; proje, sözleşme, fatura, muhasebe ve beyan kayıtlarının birlikte yönetildiği bir süreç olarak ele alıyoruz. Aşağıdaki çalışma, teknoloji geliştirme bölgesinde faaliyet gösteren girişimciler bakımından bu sürecin nasıl kurulabileceğine odaklanmaktadır.

1. İstisna şirketin bütün gelirine değil, şartları taşıyan kazanca uygulanır

4691 sayılı Kanunun geçici 2’nci maddesi, bölgede faaliyet gösteren gelir ve kurumlar vergisi mükelleflerinin münhasıran bölgedeki yazılım, tasarım ve Ar-Ge faaliyetlerinden elde ettikleri kazançlarını, öngörülen şartlarla 31 Aralık 2028 tarihine kadar istisna kapsamına alır. Şirketin adresinin Teknoparkta bulunması, her satışının bu kapsama girdiğini göstermez. [1]

İkinci ayrım, hasılat ile kazanç arasındadır. Kurumlar Vergisi Genel Tebliğinin 5.12.2.4 bölümündeki yaklaşım uyarınca istisna konusu tutar; ilgili hasılattan bu faaliyetlere ait gider ve maliyetlerin düşülmesiyle belirlenir. İstisna kapsamındaki ve kapsam dışındaki işlemlerin gelir, gider ve maliyetleri ayrıştırılmalıdır. [2]

Temel kontrol sorusu: “Bu fatura Teknopark şirketinden mi kesildi?” değil, “Bu kazanç hangi uygun faaliyetten doğdu ve tutarı hangi kayıtlarla hesaplandı?” olmalıdır.

2. Proje dosyası ile müşteriye verilen taahhüt aynı işi anlatmalı

Önerdiğimiz ilk kontrol, onaylı projenin güncel kapsamını tek sayfalık bir proje kimlik kartına aktarmaktır. Proje numarası, başlangıç ve bitiş tarihleri, uzatma veya kapsam değişiklikleri, teknik çıktı ve gelir modeli bu kartta birlikte yer almalıdır. Bu kart, mevzuatta ayrıca adı konulmuş bir zorunlu belge olarak değil, işletmenin iç kontrol aracı olarak düşünülmelidir.

Ardından müşteri sözleşmesiyle karşılaştırma yapılır. Müşteriye gerçekten yazılım geliştirme mi, lisans veya kullanım hakkı mı, ayrı bir bakım hizmeti mi, donanım mı sunulmaktadır? Teslim ve kabul ölçütleri nelerdir? Fikrî hakların kime ait olacağı nasıl düzenlenmiştir? Proje kapsamının değişmesi, sözleşmenin ve sonraki faturaların da yeniden değerlendirilmesini gerektirebilir.

Teknopark veya proje onayı, vergisel değerlendirmede incelenen önemli belgelerden biridir; ancak gelirin niteliği ve istisnanın diğer koşulları ayrıca ele alınır. Özellikle gayrimaddi hak gelirlerinde, uygulanabildiği ölçüde tescil, belgelendirme ve nitelikli harcama gibi özel kurallar da değerlendirilmelidir. Her gelir modeline tek bir istisna kontrolü uygulamak yeterli değildir. [1, 4]

3. Fatura açıklaması gerçek işlemi görünür kılmalı

“Yazılım hizmeti” şeklindeki çok genel bir açıklama, faturanın hangi proje çıktısına ait olduğunu tek başına göstermez. İç kontrol amacıyla fatura üzerinde veya onu destekleyen belgelerde proje referansının, ilgili sözleşme ya da siparişin, teslim edilen modülün ve hizmet döneminin izlenmesini öneriyoruz. Bu öneri, her faturada proje numarası yazılmasını başlı başına istisnanın kanuni şartı olarak sunmak anlamına gelmez.

Aynı müşteriye yazılım geliştirme, rutin destek ve donanım satışı yapılıyorsa; sözleşme, teslim belgeleri ve bedellerin gerçek ekonomik içeriği birbirini desteklemelidir. Ayrıştırmanın amacı vergi sonucunu değiştirmek için yapay satırlar oluşturmak değil, zaten farklı olan teslim ve hizmetleri doğru göstermek olmalıdır.

Örneğin sözleşmenin bir bölümünde yeni modül geliştirme, diğer bölümünde mevcut sistem için çağrı merkezi desteği bulunuyorsa, iki işin personel sürelerini, teslimlerini ve bedellerini ayrı izlemek incelemeyi kolaylaştırır. Buna karşılık yalnızca faturadaki açıklamayı değiştirmek, gerçekte farklı olan bir hizmeti Ar-Ge veya yazılım geliştirme faaliyetine dönüştürmez.

4. Kurumlar vergisi istisnası ile KDV istisnası ayrı testlerden geçer

4691 kapsamındaki kazanç istisnası ile KDV Kanununun geçici 20/1 maddesindeki istisna aynı değildir. KDV uygulamasında yazılımın türü, bölgede üretilmesi ve ilgili hükmün diğer koşulları ayrıca incelenir. KDV Genel Uygulama Tebliğinin II/G-2 bölümünde, güncelleme dışında bir yazılımla ilgili verilen bakım ve destek hizmetlerinin; ayrıca donanım teslimleri ve donanıma ilişkin hizmetlerin bu istisnaya girmediği açıklanır. [3]

Bu ayrımın pratik sonucu şudur: Muhasebe birimi, kurumlar vergisi yönünden olumlu değerlendirilmiş bir gelire otomatik olarak KDV istisna kodu atamamalıdır. Her gelir kalemi için “kazanç istisnası değerlendirmesi” ve “KDV değerlendirmesi” ayrı sütunlarda tutulmalıdır. Bir vergi bakımından kapsam dışında kalan işlemin diğer vergi yönünden sonucu da kendi hükümlerine göre belirlenir.

5. Gider dağıtımı, istisna kazancını değiştiren temel hesaplamadır

Önce doğrudan hangi işe ait olduğu belirlenebilen gider ve maliyetler ilgili faaliyete yüklenir. Birlikte yürütülen istisna kapsamındaki ve kapsam dışındaki işlerin müşterek genel giderleri ise Tebliğin 5.12.2.5 bölümünde belirtildiği üzere, bu faaliyetlerle ilgili cari yılda oluşan maliyetler esas alınarak dağıtılır. Ortak kullanılan sabit kıymetlerde amortisman dağıtımı için aynı bölümdeki kullanım süresi kuralları ayrıca dikkate alınır. [2, 5]

Dolayısıyla yalnızca uygulanması kolay olduğu için tüm ortak giderleri ciroya göre paylaştırmak veya istisna dışı faaliyete yüklemek doğru bir başlangıç değildir. İşletme, hangi maliyetlerin dağıtım hesabına girdiğini ve doğrudan yükleme ile ortak gider dağıtımının birbirine karışmadığını gösterebilmelidir.

Varsayımsal örnek: Aynı hesap döneminde uygunluğu ayrıca teyit edilmiş yazılım faaliyetinin hasılatı 3.000.000 TL, doğrudan maliyeti 1.800.000 TL; istisna dışı faaliyetin hasılatı 1.000.000 TL, doğrudan maliyeti 600.000 TL olsun. Dağıtılacak müşterek genel gider 240.000 TL’dir. Örnekte dağıtım esasına alınacak diğer maliyet bulunmadığı ve tüm tutarların ilgili dönem kazancıyla eşleştiği varsayılmıştır.

Örnekte istisna değerlendirmesine esas kazanç 3.000.000 TL hasılat değil, 1.020.000 TL’dir. İki faaliyetin toplam kazancı 1.360.000 TL olup, 4.000.000 TL toplam hasılattan 2.400.000 TL doğrudan maliyet ve 240.000 TL ortak gider düşülmesiyle de aynı sonuca ulaşılır. Bu mutabakat, dağıtımın toplam kazancı değiştirmeden doğru faaliyetlere yapılıp yapılmadığını kontrol eder.

Bu örnek tam bir kurumlar vergisi beyannamesi hesabı değildir. Aktifleştirme, amortisman, dönem ayırımı, diğer gelir ve giderler, kanunen kabul edilmeyen giderler ve ilgili ek yükümlülükler somut dosyada ayrıca değerlendirilir.

6. Beyan öncesinde beş kayıt grubunu eşleştirin

Bu tabloyu her ay kapatmak, yıl sonunda eksik proje veya maliyet bilgisini yeniden oluşturmaya çalışmaktan daha kullanışlı bir yöntemdir. Özellikle sözleşme kapsamı değişen, birden fazla ürün satan veya hem Teknopark içinde hem dışında faaliyeti bulunan işletmelerde, farklılıklar ayrı bir kontrol listesinde izlenmelidir. Bu aylık tablo önerisi bir iç kontrol yaklaşımıdır; resmi bildirim ve onayların yerine geçmez.

E-DENET değerlendirmesi

Sağlam bir istisna dosyası, yalnızca çok sayıda belge içeren dosya değildir. Asıl ölçüt, aynı işlemin teknik ekip, satış, muhasebe ve beyan kayıtlarında tutarlı biçimde takip edilebilmesidir. Bir kazancın neden istisna kapsamında olduğu ve tutarının nasıl bulunduğu bu kayıtlarla açıklanabiliyorsa, işletme hem hesaplamasını hem uygulamasını daha şeffaf yönetebilir.

Bu nedenle önerimiz, istisna kontrolünü beyanname hazırlığına bırakmamak; sözleşme ve fatura düzenlenmeden önce başlatmaktır. Proje kodu, hizmet sınıflandırması ve maliyet eşleştirmesini erken kurmak, sonradan yalnızca belge açıklamalarını değiştirerek çözülmeye çalışılan sorunların önüne geçmeye yardımcı olur.

Kaynaklar ve mevzuat dayanakları

1. 4691 sayılı Teknoloji Geliştirme Bölgeleri Kanunu, geçici 2’nci madde; GİB mevzuat sayfası. Resmî kaynağı aç
2. Kurumlar Vergisi Genel Tebliği (Seri No: 1), 5.12.2.4 ve 5.12.2.5. Bu bölümlerin GİB tarafından aktarıldığı resmi özelge metinleri; kaynak, ilgili genel kurallar için kullanılmıştır. Resmî kaynağı aç
3. KDV Genel Uygulama Tebliği, II/G-2: Teknoloji Geliştirme Bölgesinde ve İhtisas Teknoloji Geliştirme Bölgesinde Verilen Teslim ve Hizmetler. GİB birleştirilmiş metni. Resmî kaynağı aç
4. Kurumlar Vergisi Genel Tebliği (Seri No: 1)’nde Değişiklik Yapılmasına Dair Tebliğ (Seri No: 16); gayrimaddi haklara ilişkin düzenlemeler. Resmî kaynağı aç
5. Ortak kullanılan sabit kıymetlerin amortisman dağıtımına ilişkin 5.12.2.5 hükmünün aktarıldığı GİB resmi özelge metni. Resmî kaynağı aç

Bu yazı genel bilgilendirme amacıyla hazırlanmıştır. Örnekler varsayımsaldır. Somut işlemlerde ilgili dönemin mevzuatı, sözleşmeler ve belgeler birlikte değerlendirilmelidir.