E-Beyanname Kapsamı: Beyanname, Dönem ve Kanal

Bir e-Beyanname ürününün “KDV, Muhtasar veya Kurumlar Vergisini desteklediğini” söylemek tek başına yeterli bir kapsam tanımı değildir. Aynı beyanname için geçerli gönderim kanalı döneme, mükellefin bağlı olduğu il veya vergi dairesinin geçiş takvimine, mükellefin yetkisine, işlemin yeni veya düzeltme olmasına ve GİB’in test, pilot veya üretim ortamındaki güncel açılımına göre değişebilir.

Bu nedenle kapsam, ürün listesindeki bir onay işaretinden ziyade izlenebilir bir beyanname–dönem–il/vergi dairesi–mükellef–kanal matrisi olarak yönetilmelidir.

Kapsam kararının altı boyutu

1. Beyanname türü ve vergi kodu

İlk anahtar, günlük kullanılan kısa ürün adı değil GİB’deki tam beyanname ve vergi kodudur. KDV 1, Damga, Kurumlar Geçici veya Muhtasar ve Prim Hizmet gibi başlıkların farklı veri alanları, zorunlu ekleri ve iş kuralları vardır. GİB geliştirici dokümanlarında KDV1, Damga, Kurumlar, Kurumlar Geçici ve MUHSGK gibi beyannameler için ayrı API bölümleri yayımlanır.

Bir API dokümanının yayımlanmış olması, her mükellef için üretim ortamının açık olduğu anlamına gelmez. Üretim kapsamı ayrıca doğrulanmalıdır.

2. Vergilendirme dönemi ve beyanname versiyonu

GİB API akışlarında dönem bilgisi, geçerli beyanname versiyonunu ve doğrulama kurallarını belirleyen temel girdilerden biridir. Dokümanlarda “döneme ait versiyon bilgisi bulunamadı” veya bazı geçmiş dönemler için BDP kullanılmasını isteyen hata mesajları bulunabilir.

Bu yüzden SAP eşlemesi yalnızca form adına göre değil, geçerlilik başlangıç ve bitiş tarihleriyle sürümlenmelidir. Geçmiş dönem düzeltmelerinin güncel dönemle aynı kanalı kullanacağı varsayılmamalıdır.

3. İl, vergi dairesi ve kademeli geçiş

GİB, bazı beyanname ailelerini il ve vergilendirme dönemi bazında kademeli olarak kullanıma açabilir. Örneğin 20 Temmuz 2026 tarihli duyuruda KDV1, KDV2, KDV2B, KDV4 ve KDV9015 için kapsamın 2026/Temmuz döneminden, 1 Ağustos 2026 tarihinden itibaren İstanbul hariç bütün illere genişletileceği açıklanmıştır.

Bu takvim, yalnız beyanname türünü ve dönemi bilmenin yeterli olmadığını gösterir. Proje ve canlı kullanım öncesinde mükellefin bağlı olduğu il veya vergi dairesi için güncel GİB duyurusu yeniden doğrulanmalıdır.

4. Mükellef ve kullanıcı yetkisi

GİB entegrasyon başvurusu için beyanname gönderme yetkisi gerekir. Ana kullanıcı, alt kullanıcı, meslek mensubu veya şirket adına gönderim senaryolarında farklı yetki ve sözleşme kontrolleri devreye girebilir. API’nin 401, 403 veya iş kuralına özgü yetki mesajı döndürmesi, yalnızca teknik bir bağlantı problemi değildir; mükellef ve sözleşme bağlamının da incelenmesi gerekir.

5. Çalışma ortamı

GİB entegrasyon kılavuzu Pre-Prod, Pilot ve Prod ortamlarını ayırır. Onaylı IP adresleri ve API anahtarları ortama bağlıdır. Testte başarılı olan bir beyanname, GİB tarafından üretimde henüz kullanıma açılmamış olabilir.

Kapsam matrisinde ortam sütunu bulunmalı; test başarısı ile canlı kullanım izni birbirine karıştırılmamalıdır.

6. İşlem senaryosu

Yeni beyanname, düzeltme, kanuni süresinden sonra beyan, özel onay, iptal ve belge indirme aynı kurallara sahip değildir. Örneğin GİB kullanıcı dokümanı düzeltmenin son onaylı beyanname üzerinden ilerlediğini, onaylı beyannamelerin silinemediğini ve tahakkuk belgesinin uygun durumlarda indirilebildiğini açıklar.

Önerilen kapsam matrisi

Her satırda en az şu alanları yönetin:

Alan	Karar kaydı
Beyanname	GİB adı, vergi kodu ve şirket içi süreç sahibi
Dönem	Geçerlilik başlangıcı, bitişi ve beyanname versiyonu
İl / vergi dairesi	Mükellefin bağlı olduğu birim ve kapsama giriş tarihi
Ortam	Pre-Prod, Pilot veya Prod
Yetki	Mükellef, kullanıcı, sözleşme ve onay koşulları
Kanal	REST API, BDP veya doğrulanacak kanal
Senaryo	Yeni, düzeltme, geç/özel onay, iptal
Kanıt	GİB duyurusu, API kılavuzu ve test sonucu
Son kontrol	Tarih ve kontrolü yapan sorumlu

Bu matris proje başlangıcında hazırlanmalı, GİB duyurusu veya API sürümü değiştiğinde yeniden gözden geçirilmelidir. “Tüm beyannameler desteklenir” gibi kalıcı bir ifade yerine doğrulanabilir kapsam kaydı kullanmak hem kullanıcı beklentisini hem de test planını iyileştirir.

Teknik tasarım için SAP E-Beyanname entegrasyon mimarisini, proje planı için geçiş kontrol listesini okuyun. Ürün kapsamının nasıl ifade edildiğini Fenikstech SAP E-Beyanname çözümünün interaktif simülasyonunda görebilirsiniz.

Resmî kaynaklar

Bu yazı 23 Temmuz 2026’da resmî kaynaklara göre gözden geçirilmiştir.