Almanya'da E-Rechnung Zorunluluğu: 1 Ocak 2027'ye Kadar Kendi Sistemlerinizden Yapılandırılmış Fatura Düzenlemek

1 Ocak 2027'den itibaren 2026 cirosu 800.000 €'nun üzerinde olan bir Alman işletmesi, başka bir Alman işletmesine artık kâğıt ya da PDF fatura gönderemeyecek. Faturanın yapılandırılmış bir e-Fatura olması gerekiyor: Avrupa standardı EN 16931'e göre oluşturulmuş bir veri dosyası. 1 Ocak 2028'den itibaren eşik kalkıyor ve kural, birkaç dar istisna dışında tüm işletmelere uygulanıyor.

Küçük bir firma için bu bir yazılım güncellemesi olarak geliyor. Faturalarını kendi faturalama sisteminden, bir sektör paketinden ya da on beş yılda özelleştirilmiş bir ERP'den çıkaran bir şirket için ise bu bir yazılım projesi ve yaklaşık on üç hafta kaldı. Bu makale ikinci grup için.

Yasa Ne Diyor

Tanım § 14 UStG içinde yer alıyor: fatura, “die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht” (yapılandırılmış bir elektronik formatta düzenlenen, iletilen ve alınan ve elektronik olarak işlenebilen) bir belgedir. Formatın 2014/55/EU sayılı Direktif kapsamındaki Avrupa standardına (pratikte EN 16931'e) uygun olması ya da gerekli verilerin bu standartla uyumlu bir biçime doğru ve eksiksiz olarak aktarılabilmesi koşuluyla taraflar arasında kararlaştırılmış olması gerekiyor. Bir PDF, ne kadar düzenli görünürse görünsün, bu tanıma girmez.

Yükümlülük, her iki tarafın da Almanya'da yerleşik olduğu, başka bir işletmeye yapılan teslimleri kapsıyor. Geçiş hükümleri § 27 Abs. 38 UStG içinde:

• 2025 ve 2026'da yapılan teslimler, fatura 31 Aralık 2026'ya kadar gönderildiği sürece hâlâ kâğıt üzerinde ya da müşteri kabul ederse başka bir elektronik formatta faturalandırılabilir.
• 2027'de yapılan teslimler 31 Aralık 2027'ye kadar aynı imkândan yararlanır, ancak yalnızca faturayı düzenleyenin önceki takvim yılındaki toplam cirosu 800.000 €'yu aşmadıysa.
• Standardı karşılamayan EDI, büyüklüğünüz ne olursa olsun, müşterinin onayıyla 2027'de yapılan teslimler için kullanılmaya devam edebilir.

Üç ayrıntı göründüğünden daha önemli.

Eşik, geçen yılın cirosuna göre ölçülüyor. 2027'deki durumunuz 2026 rakamınıza bağlı ve bu rakamı defterler kapanana kadar kimse tam olarak bilmeyecek. 800.000 €'ya yakın bir yerdeyseniz eşiğin üzerindeymiş gibi hazırlanın.

Geçiş imkânı bir gönderim tarihinde sona eriyor. Kelimesi kelimesine okunduğunda ilk geçiş kuralı, 2026'da yapılan işler için bile kâğıt ve PDF'yi 31 Aralık 2026'da kapsamaz hale geliyor. Eşiğin üzerindeyseniz ve işi tamamladıktan sonra faturalandırıyorsanız, Aralık ayındaki iş için Ocak'ın ilk haftasında gönderdiğiniz faturanın zaten yapılandırılmış olması gerekiyor. Bunu vergi danışmanınızla teyit edin, ama canlıya geçişi Ocak ortasına planlamayın.

Bazı faturalar kapsam dışında kalıyor: tüketicilere kesilen faturalar, sınır ötesi faturalar, brüt 250 €'ya kadar olan küçük tutarlı faturalar, fatura yerine geçen biletler, Kleinunternehmer statüsündeki işletmelerin faturaları ve § 4 Nr. 8 ila 29 UStG kapsamında muaf teslimler.

Bu tarihleri değiştirecek herhangi bir yasa tasarısından haberdar değiliz. Tarihler geçerliymiş gibi plan yapın.

Alma Yükümlülüğü 2025'ten Beri Geçerli. Yeni Olan Düzenleme Yükümlülüğü.

1 Ocak 2025'ten bu yana her Alman işletmesinin e-Fatura alabilmesi gerekiyor. Federal Maliye Bakanlığının e-Fatura SSS sayfası bunun için ne gerektiği konusunda açık: “Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.” Bir e-posta kutusu yeterli.

§ 14'ün kendisindeki bir satıra dikkat edin: e-Fatura yükümlülüğünün geçerli olduğu durumlarda alıcının onayı gerekmez. Alman bir kurumsal müşteri yapılandırılmış faturanızı reddedemez.

Düzenlemek ise farklı bir sorun. Fatura aldığınızda bir araç başkasının dosyasını okur. Fatura düzenlediğinizde ise belgenin sahibi sizin sisteminizdir: veri kaynağında hatalıysa zincirde sonra gelen hiç kimse onu düzeltemez ve müşterinizin doğrulamasından geçemeyen bir fatura ödenmeden bekler.

Bunu Bir Güncellemeyle Alanlar

Açıkça söyleyelim: DATEV, lexoffice, sevDesk ya da benzeri bir paketle fatura kesen küçük bir firmaysanız formatı tedarikçiniz sağlar. Ana verilerinizi (KDV numarası, müşteri adresleri, banka bilgileri) kontrol edin, özelliği açın ve bir test faturası gönderin. Bir projeye ihtiyacınız yok, bir yazılım şirketine de ihtiyacınız yok.

Standarda hâlâ yakın olan yaygın bir ERP için de durum büyük ölçüde aynı: çıktıyı tedarikçi veya iş ortağınız sağlar, iş yapılandırma ve testten ibarettir.

Bu makalenin geri kalanı, faturaları kendilerine ait koddan ya da artık kimsenin bakımını yapmadığı koddan çıkan şirketler için:

• abonelik platformları, pazaryerleri ve kamu hizmeti şirketlerinde, yüksek hacimde programatik olarak fatura düzenleyen faturalama motorları;
• tedarikçinin küçük, yavaş ya da artık var olmadığı toptan ticaret, inşaat, lojistik veya saha hizmeti yazılımları;
• fatura çıktısı yıllar önce özel yazdırma programları, rapor şablonları ya da ay sonu adres-mektup birleştirme (mail merge) olarak yeniden yazılmış ERP'ler.

Formatlar: EN 16931, XRechnung ve ZUGFeRD

EN 16931 Avrupa standardıdır. Bir faturanın anlamsal modelini (alanları, bunların ne anlama geldiğini, hangilerinin zorunlu olduğunu ve aralarındaki iş kurallarını) tanımlar ve bunu UBL 2.1 ve UN/CEFACT CII olmak üzere iki XML sözdizimine bağlar.

XRechnung, EN 16931 üzerine kurulu ve KoSIT tarafından sürdürülen Alman spesifikasyonudur: iki sözdiziminden birinde saf XML; kamu kurumları tarafından zorunlu tutulur ve işletmeler arasında da aynı şekilde geçerlidir. KoSIT'in XRechnung sayfasına göre 3.0 sürümü 1 Şubat 2024'ten beri yürürlükte ve en az 31 Temmuz 2027'ye kadar yürürlükte kalacak. 4.0'ın ön sürümü Eylül 2026'da yayımlandı; nihai sürümün 2027 baharında çıkması bekleniyor. Canlıya 3.0 ile geçecek ve ilk yılınız içinde yükseltme yapacaksınız.

ZUGFeRD hibrit bir formattır: içine CII XML gömülü bir PDF/A-3 dosyası. İnsanlar PDF'yi, makineler XML'i okur. Fransa'da aynı format Factur-X olarak adlandırılıyor ve ikisi teknik olarak aynı. FeRD, 2.5.2 sürümünü 4 Ağustos 2026'da yayımladı. ZUGFeRD profiller halinde gelir (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED) ve bakanlığın SSS sayfası 2.0.1 sürümünden itibaren ZUGFeRD'yi “mit Ausnahme der Profile MINIMUM und BASIC-WL” (MINIMUM ve BASIC-WL profilleri hariç) kabul ediyor.

Hibrit bir faturada geçerli olan XML'dir. SSS sayfası yapılandırılmış kısmı “führender Teil”, yani belirleyici kısım olarak adlandırıyor. PDF'niz ile XML'iniz uyuşmuyorsa hatalı olan PDF'dir.

Almanya'daki B2B fatura düzenleyicilerin çoğu için mantıklı varsayılan seçenek, faturaları hâlâ gözle okuyan müşterilerin bunu sürdürebilmesi için EN 16931 profilinde ZUGFeRD; buna ek olarak kamu kurumları ve talep eden herkes için XRechnung. Her ikisi de iki ayrı kod yolundan değil, tek bir dahili fatura nesnesinden üretilmeli.

Sisteminizde Neyin Değişmesi Gerekiyor

Fatura bir sayfa düzeni değil, veri haline geliyor

Birçok eski sistem faturayı yazdırma anında oluşturur: metin bir şablona eklenir, toplamlar raporun içinde hesaplanır, KDV notu koda gömülü bir paragraftır. Bunların hiçbiri EN 16931'den sağ çıkmaz. Her alanı tutan, kaydedilmiş bir fatura nesnesine ihtiyacınız var; XML de PDF de bu nesneden üretilmeli.

Genellikle eksik ya da hatalı olan alanlar:

• Taraf verileri. ISO ülke kodlarıyla yapılandırılmış adresler ve bir KDV numarası ya da vergi numarası. Serbest metin adres blokları bölünmeli.
• Teslim tarihi veya hizmet dönemi, başlıkta bir cümle olarak değil, veri olarak tutulmalı.
• Birimler. Her miktar için UN/ECE Recommendation 20'den bir kod gerekiyor (adet için H87, kilogram için KGM, gün için DAY). “Stk.” ve “pauschal” gibi ifadelerin eşlenmesi gerekiyor.
• KDV. Her satır bir KDV kategorisi ve oranı taşır. Fatura, her kategori ve oran kombinasyonu için bir KDV dökümü içerir ve toplamlar iki ondalık basamakta tam olarak tutmalıdır. KDV'yi satır bazında yuvarlayan sistemler burada başarısız olur.
• Muafiyet ve tersine vergilendirme (reverse charge) ifadeleri. PDF'nin altındaki cümle, bir KDV kategori kodu ve bir muafiyet gerekçesine dönüşür.
• Ödeme. Ödeme yöntemi, IBAN ve ödeme koşulları yapılandırılmış biçimde.
• Referanslar. Müşterinizin borç hesapları (accounts payable) ekibinin eşleştirme için kullandığı sipariş numarası veya alıcı referansı. Bunu hiç saklamadıysanız şimdi kaydetmeye başlayın.

Yalnızca metin içeren satırlar (“kararlaştırıldığı şekilde teslimat”) sık karşılaşılan bir engeldir. Yapılandırılmış bir faturada satır, faturalandırılabilir bir kalemdir; dolayısıyla bu metin bir nota aittir.

Düzeltmeler, alacak dekontları ve müşteri tarafından düzenlenen faturalar

SSS sayfası açık: e-Fatura yükümlülüğünün geçerli olduğu durumlarda düzeltmenin de düzeltme için öngörülen fatura türüyle bir e-Fatura olması gerekiyor. EN 16931'de düzeltme, önceki faturaya numarası ve düzenlenme tarihiyle atıf yapar; dolayısıyla sisteminizin bu bağlantıyı veri olarak tutması gerekir.

Terimlere dikkat edin. Alman KDV hukukunda “Gutschrift”, önceden yapılmış bir anlaşmaya dayanarak müşteri tarafından düzenlenen faturadır (self-billing, § 14 Abs. 2 UStG). İngilizce konuşan birinin credit note dediği şey (bir fiyat indirimi veya iptal) ise bir düzeltmedir. Birçok sistem ikisi için tek bir belge türü kullanır. Bunları eşlemeden önce ayırın; tedarikçileriniz adına fatura düzenliyorsanız bu belgeleri sisteminizin düzenlediği faturalar olarak ele alın.

Nihai bir fatura, yapılandırılmış kısım ona atıf yaptığı sürece önceki kısmi ödemeleri bir ekte listeleyebilir; SSS sayfası bunun 2027'den sonra da devam edeceğini teyit ediyor.

Hiçbir şey çıkmadan önce doğrulama

KoSIT, XML'i şemalara ve Schematron kurallarına göre kontrol eden, XRechnung için herkese açık bir yapılandırmaya sahip açık kaynaklı bir doğrulayıcı yayımlıyor. Komut satırından, bir HTTP daemon'ı olarak ya da bir kütüphane olarak çalışıyor. Bunu gönderim akışına yerleştirin: her fatura gönderilmeden önce doğrulanır ve başarısız olan fatura, hangi alanın hangi kuralı ihlal ettiğini belirterek sorumlusu belli bir kişiye ait bir kuyruğa düşer.

ZUGFeRD için gömülü XML'i profilinizin kurallarına göre doğrulayın, PDF/A-3 kapsayıcısını ayrıca kontrol edin ve PDF'nin XML ile aynı toplamları gösterdiğini teyit edin.

İletim

SSS sayfasına göre yasa “sieht keinen bestimmten Weg vor”: belirli bir kanal öngörmüyor. Dosyanın ekli olduğu bir e-posta yeterli. Bir API, bir indirme portalı, bir şirketler grubu içinde paylaşılan depolama alanı ya da (bakanlığın kendi örneğiyle) bir USB bellek de olur. Almanya'da yurt içi B2B için Peppol zorunlu değil.

Mühendislik işi müşteri bazında: bir fatura adresi, tercih edilen bir format ve neyin nereye gönderildiğinin kaydı. Başarısız bir gönderimden sonraki yeniden deneme, aynı fatura numarasıyla aynı belgeyi taşır. Tek bir teslim için iki numara bir yazılım sorunu değil, vergi sorunudur.

Arşivleme

En azından yapılandırılmış kısmın “unversehrt in seiner ursprünglichen Form”, yani özgün haliyle bozulmadan saklanması gerekiyor; § 14b UStG de saklama süresini düzenlenme yılının sonundan itibaren sekiz yıl olarak belirliyor. Gönderdiğiniz baytların birebir aynısını bir hash değeriyle birlikte saklayın. Faturaları daha sonra veritabanından yeniden üretmeyi planlamayın: o zamana kadar hem veri hem kod değişmiş olur. Aynısı aldığınız e-Faturalar için de geçerli.

Ekim-Aralık 2026 İçin Bir Plan

Kaynak veriler makul durumdaysa odaklı bir geliştirme için on üç hafta yeterli. Faturalama sistemini değiştirmek için ise yeterli değil.

1. ve 2. haftalar: envanter ve kararlar. Manuel alacak dekontları, proje kapanış faturaları ve büyük bir müşteri için tutulan tablo dahil, fatura üretilen her yeri listeleyin. 2026 cirosunu eşiğe göre kontrol edin. Varsayılan formatı seçin ve oluşturucuyu kendiniz mi geliştireceğinize, yoksa fatura verilerini bir e-Fatura sağlayıcısının API'sine mi göndereceğinize karar verin.

2-4. haftalar: veri eksikliği analizi. Üç aylık gerçek faturaları alan alan EN 16931 ile eşleyin. Neyin eksik olduğunu, neyin koda dönüşmesi gerektiğini ve neyin farklı hesaplandığını işaretleyin. Projenin gerçek boyutu burada ortaya çıkar.

4-9. haftalar: geliştirme. Fatura nesnesi, eşleme, XML ve PDF/A-3 üretimi, gönderim akışındaki doğrulayıcı, hata kuyruğu ve arşiv. Paralel olarak biri ana verileri temizler ve müşterilerden fatura adreslerini toplar.

9-11. haftalar: tekrar çalıştırma ve pilot. Son üç ayın faturalarını yeni oluşturucudan geçirin ve her birini doğrulayın. Ardından birkaç gönüllü müşteriyle pilot yapın ve sistemlerinin dosyaları okuyup okumadığını sorun.

11-13. haftalar: dondurma ve operasyon el kitabı. Aralık ayında değişiklikleri dondurun. Hata kuyruğunun sorumlusunun kim olduğunu, bir düzeltmenin nasıl düzenlendiğini ve bir müşteri faturayı reddettiğinde ne olacağını yazın. Aralık işleri için Ocak'ta kesilen faturalar zaten kapsamda.

Ocak 2027. Canlıya geçin ve ilk ay sonu ile ilk KDV beyannamesi boyunca kuyruğu her gün izleyin.

2027 boyunca. 3.0 geçerliliğini yitirmeden XRechnung 4.0 yükseltmesini planlayın ve eşiğin altındaki grup şirketlerini 1 Ocak 2028'den önce geçirin.

Geç başlarsanız çıktının geçerliliğinden değil, otomasyondan kısın: önce yüksek hacimli fatura türlerini otomatikleştirin, nadir belgeleri birkaç hafta boyunca bir e-Fatura aracıyla elle gönderin.

Nereden Destek Alabilirsiniz

Faturalarınızı üreten sistem ile yasanın gerektirdiği format arasındaki bağlantıyı kuruyoruz: veri modeli değişiklikleri, eşleme, doğrulama, iletim ve arşiv; kendi kod tabanınızda ve ekibinizle birlikte. Bu projelerin nasıl yürüdüğünü e-Fatura entegrasyonu hizmetimiz anlatıyor; zorunluluk bir ERP değişikliğinin ortasına denk geliyorsa ERP modernizasyonu sayfasına göz atın. Daha geniş takvim 2026 AB dijital uyum rehberimizde.

Biz vergi danışmanı değil, mühendisiz: kapsam soruları Steuerberater'ınızın alanında; biz onların yanıtına göre geliştiririz. Bugün faturalarınızı neyin ürettiğini ve her ay yaklaşık kaç fatura gönderdiğinizi bize anlatın: office@c9group.dev adresine yazın.