PDF/A, PDF’in arşivleme için tanımlanmış halidir: bir belgenin 2026’da nasıl görünüyorsa 2050’de de aynı şekilde render edileceğine dair garanti. Başlıca profiller PDF/A-1, 2, 3 ve 4’tür; her profil ayrıca conformance seviyelerine ayrılır. Bunların içinde PDF/A-3, AB e-faturalarının sessiz temelidir ve yaygın kullanımda arşiv wrapper içinde keyfi dosya eklerine izin veren tek PDF/A profilidir.

Invoice, regulatory filing ya da “PDF + structured data” içeren bir workflow üzerinde çalışıyorsanız PDF/A-3 ile karşılaşırsınız. İşte ne olduğu, diğerlerinden nasıl ayrıldığı ve dosyanın gerçekten uyumlu olup olmadığını nasıl kontrol edeceğiniz.

PDF/A ailesi kısa özet

Profile	ISO part	Year	Belirleyici özellik
PDF/A-1	19005-1	2005	İlk arşiv profili. Transparency yok, JavaScript yok, fontlar embedded.
PDF/A-2	19005-2	2011	JPEG2000, transparency ve layer support ekler. Daha iyi print fidelity.
PDF/A-3	19005-3	2012	Embedded file attachments ekler. Factur-X / ZUGFeRD wrapper’ı.
PDF/A-4	19005-4	2020	Modern revizyon; daha temiz conformance model, `b` ve `a` ayrımı yok.

Alt seviyeler:

b (basic): görsel sadakat korunur; semantik yapı garantisi yoktur.
a (accessible): structure tagging ve Unicode mapping; screen reader doğru sırayla text çıkarabilir.
u (Unicode): Unicode mapping vardır, tam yapı yoktur.
e / f (sadece PDF/A-4): engineering 3D content ve full forms.

“PDF/A-3b” şu demektir: attachment’a izin veren arşiv profili 3 ve accessibility tagging gerektirmeyen basic seviye. Faturalamada en yaygın varyant budur.

PDF/A-3’ü özel yapan şey

PDF/A-1 ve PDF/A-2 arbitrary embedded files kullanımını yasaklar. Mantık nettir: arşiv PDF’i self-contained olmalıdır; içine konan data.xlsx, PDF’den bağımsız bozulabilir ve arşiv garantisini kırabilir.

PDF/A-3 bu kuralı sıkı bir şartla gevşetir: her embedded file, visible PDF content ile ilişkisini açıklayan AFRelationship attribute’unu taşımalıdır. Geçerli değerler Source, Data, Alternative, Supplement, Unspecified. PDF ayrıca attachment’ı /AF array içinde listelemeli ve attached file için XMP metadata üretmelidir.

Yani PDF/A-3 şunu söyler: “Dosya ekleyebilirsin, ama ne olduğunu ve insanın gördüğü PDF ile ilişkisini açıkça beyan etmelisin.” Bu beyan e-faturanın temelidir: insan tarafından okunan invoice PDF içindedir, makine tarafından okunan EN 16931 CII XML attachment içindedir ve AFRelationship="Alternative" ikisinin aynı faturanın alternatif temsilleri olduğunu söyler.

Production’da PDF/A-3 nerede kullanılır

Factur-X (Fransa, 2026’dan itibaren B2B zorunlu geçiş): PDF/A-3 + CII XML, urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# XMP namespace ile.
ZUGFeRD 2.x (Almanya, 2025’ten itibaren alma zorunlu): PDF/A-3 + CII XML, urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0# XMP namespace ile.
Engineering CAD archival: native CAD file attach edilmiş PDF/A-3. PDF rendering’dir, CAD source’tur.
Regulatory submissions: FDA submissions veya AB listeli şirketlerin ESEF financial reports gibi XML payloads içeren PDF/A-3.

Bu örneklerde wrapper yalnızca container değildir. Bir contract’tır: PDF ve attached file aynı document’ı temsil eder ve ikisi de validate olmalıdır.

PDF/A-3 uyumluluğu nasıl doğrulanır

Resmi conformance checker veraPDF’tir (verapdf.org); PDF Association tarafından sürdürülür. ISO 19005-3 rule set’i implement eder. veraPDF “Pass — PDF/A-3b” diyorsa, tek engine’den alınabilecek en güçlü sinyal budur.

Ama tek engine “Pass” audit-grade standard değildir (Why two PDF/A validators are better than one nedenini anlatır). Audit-grade pattern, iki independent engine çalıştırmak ve dosyayı yalnızca ikisi de pass olduğunda compliant saymaktır.

E-invoice için ek bir engine gerekir: Mustang (mustangproject.org). Factur-X / ZUGFeRD için de-facto checker’dır ve embedded CII XML’i EN 16931 Schematron’a karşı validate eder. PDF/A-3 conformance tek başına yetmez; attached XML de valid EN 16931 olmalıdır, yoksa alıcının AP system’i invoice’u reddeder.

Birçok ekip Java kurar, veraPDF CLI ayarlar, Mustang kurar ve sonuçları birleştiren shell script yazar. Çalışır, ama sürtünme yaratır.

validator üçünü browser içinde çalıştırır:

veraPDF: official reference, PDF/A-3 conformance.
gPdf Rust+WASM edge engine: independent re-implementation, second opinion.
Mustang: embedded e-invoice payloads için EN 16931 CII XML Schematron.

Dosyayı bırakın, üç engine parallel çalışır, raporlar side-by-side gelir. QA evidence için JSON indirilebilir. Login yok, quota yok.

Raporda gerçekten neye bakmalı

Hatalar çoğunlukla şu alanlarda toplanır:

Embedded file metadata missing: /AF array yoktur veya embedded file içinde listelenmemiştir.
AFRelationship missing or wrong: e-invoice için Alternative olmalıdır; birçok PDF library default olarak Source veya Data verir.
XMP namespace missing or wrong: Factur-X ve ZUGFeRD belirli namespace URI’ları kullanır; tek karakter hatası fail eder.
Fonts not subsetted or not embedded: PDF/A, kullanılan tüm glyphs’in font ile birlikte embedded olmasını ister.
Output intent missing: belge yalnızca siyah-beyaz text olsa bile PDF/A renk niyeti (sRGB veya başka ICC profile) ister.
Document metadata incomplete: information dictionary içinde /Title, /Producer, /CreationDate bulunmalıdır.

Report genellikle ilgili spec section’a işaret eder. Kaynakta düzeltin; gPdf ile generate ediyorsanız API bunları otomatik halleder ve validator public receipt olur.

TL;DR

PDF/A-3 = PDF/A-2 + arbitrary files’ı yasal olarak embed edebilme yeteneği. AB e-invoicing’i pratik yapan şey budur: human-readable invoice + structured EN 16931 CII XML, tek archival wrapper içinde. Hem PDF/A-3 wrapper hem attached XML pass olmalıdır.

POST /api/v1/e-invoice/render ile generate edin. validator üzerinde verify edin. Üç engine (veraPDF + gPdf edge + Mustang), tek upload, ücretsiz.