PDF/A-3 क्या है: और कैसे जांचें कि आपकी फाइल सच में compliant है

PDF/A, PDF का archival रूप है: यह वादा कि दस्तावेज 2050 में भी वैसा ही render होगा जैसा 2026 में होता है। इसके मुख्य profile PDF/A-1, 2, 3 और 4 हैं, और हर profile के अंदर conformance levels हैं। इनमें PDF/A-3 वही profile है जो EU e-invoicing को चलाता है, और व्यापक उपयोग में अकेला ऐसा PDF/A profile है जो archival wrapper के अंदर arbitrary file attachments की अनुमति देता है।

अगर आप invoices, regulatory filings या “PDF + structured data” वाले किसी workflow पर काम कर रहे हैं, तो PDF/A-3 सामने आएगा। यहां उसका व्यावहारिक अर्थ, बाकी profiles से अंतर और verification का तरीका है।

PDF/A family एक नजर में

Profile	ISO part	Year	मुख्य विशेषता
PDF/A-1	19005-1	2005	पहला archival profile. Transparency और JavaScript नहीं, fonts embedded.
PDF/A-2	19005-2	2011	JPEG2000, transparency और layer support. बेहतर print fidelity.
PDF/A-3	19005-3	2012	Embedded file attachments जोड़ता है. Factur-X / ZUGFeRD का wrapper.
PDF/A-4	19005-4	2020	आधुनिक revision; conformance model साफ, b बनाम a split नहीं.

Sub-levels भी होते हैं:

• b (basic): visual fidelity सुरक्षित रहती है; semantic structure की guarantee नहीं।
• a (accessible): structure tags और Unicode mapping; screen readers सही क्रम में text निकाल सकते हैं।
• u (Unicode): Unicode mapping है, लेकिन full structure नहीं।
• e / f (केवल PDF/A-4): engineering 3D content और full forms।

इसलिए “PDF/A-3b” का मतलब है: archival profile 3, जिसमें attachments allowed हैं, और basic level, जिसमें accessibility tagging जरूरी नहीं। Invoicing में यही सबसे आम variant है।

PDF/A-3 खास क्यों है

PDF/A-1 और PDF/A-2 arbitrary embedded files को forbid करते हैं। वजह यह है कि archival PDF self-contained होना चाहिए; अगर उसमें data.xlsx attach है, तो वह attachment PDF से अलग खराब हो सकती है और archival guarantee टूट सकती है।

PDF/A-3 इस नियम को एक tight condition के साथ relax करता है: हर embedded file को AFRelationship attribute देना होगा, जो बताता है कि file visible PDF content से कैसे जुड़ी है। Valid values हैं Source, Data, Alternative, Supplement, Unspecified। PDF declaration को attachment को /AF array में भी list करना होता है और उस attached file के लिए XMP metadata emit करना होता है।

यानी PDF/A-3 कहता है: “Attach कर सकते हो, लेकिन साफ बताओ कि attachment क्या है और इंसान जो PDF देखता है उससे उसका रिश्ता क्या है।” यही e-invoicing का आधार बना। Human-readable invoice PDF में रहती है, machine-readable EN 16931 CII XML attachment में, और AFRelationship="Alternative" बताता है कि दोनों एक ही invoice की alternative representations हैं।

Production में PDF/A-3 कहां दिखता है

• Factur-X (France, 2026 से B2B mandatory rollout): PDF/A-3 + CII XML, urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# XMP namespace के साथ।
• ZUGFeRD 2.x (Germany, 2025 से receipt mandatory): PDF/A-3 + CII XML, urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0# XMP namespace के साथ।
• Engineering CAD archival: PDF/A-3 में native CAD file attached होती है। PDF rendering है, CAD source है।
• Regulatory submissions: PDF/A-3 के साथ XML payloads, जैसे FDA submissions या EU-listed issuers की ESEF financial reports।

इन मामलों में wrapper सिर्फ container नहीं है। यह contract है कि “यह PDF और यह attached file एक ही document हैं, और दोनों validate होने चाहिए।”

PDF/A-3 compliance कैसे verify करें

Official conformance checker veraPDF (verapdf.org) है, जिसे PDF Association maintain करता है। यह ISO 19005-3 ruleset implement करता है; अगर veraPDF “Pass — PDF/A-3b” report करता है, तो single engine से मिलने वाला सबसे मजबूत signal यही है।

लेकिन single-engine “Pass” audit-grade standard नहीं है (Why two PDF/A validators are better than one इसी पर है)। Audit-grade pattern है दो independent engines चलाना और file को compliant तभी मानना जब दोनों pass हों।

E-invoice file के लिए एक और engine चाहिए: Mustang (mustangproject.org)। यह Factur-X / ZUGFeRD के लिए de-facto checker है और embedded CII XML को EN 16931 Schematron के खिलाफ validate करता है। PDF/A-3 conformance अकेले काफी नहीं; attached XML भी valid EN 16931 होना चाहिए, वरना receiving AP system invoice reject करेगा।

अधिकांश teams Java install करती हैं, veraPDF CLI setup करती हैं, Mustang install करती हैं और outputs मिलाने के लिए shell script लिखती हैं। यह चलता है, पर friction जोड़ता है।

validator तीनों को browser में चलाता है:

1. veraPDF: official reference, PDF/A-3 conformance।
2. gPdf का Rust+WASM edge engine: independent re-implementation, second opinion।
3. Mustang: embedded e-invoice payloads के लिए EN 16931 CII XML Schematron।

File drop करें, तीनों parallel में run होते हैं, reports side-by-side आते हैं। QA evidence के लिए JSON download कर सकते हैं। Login नहीं, quota नहीं।

PDF/A-3 report में क्या देखें

Failures आमतौर पर इन जगहों पर आते हैं:

• Embedded file metadata missing: /AF array नहीं है, या embedded file उसमें listed नहीं है।
• AFRelationship missing या गलत: e-invoice के लिए Alternative होना चाहिए; कई PDF libraries default में Source या Data देती हैं।
• XMP namespace missing या गलत: Factur-X और ZUGFeRD के namespace URI specific हैं; एक character typo भी fail करा सकता है।
• Fonts subsetted या embedded नहीं: PDF/A में document में use हुए सभी glyphs font के साथ embedded होने चाहिए। Declared पर unused font reference भी edge case में fail कर सकता है।
• Output intent missing: Document black-and-white text ही क्यों न हो, PDF/A में colour intent (sRGB या कोई ICC profile) declare होना चाहिए।
• Document metadata incomplete: document info dictionary में /Title, /Producer, /CreationDate होने चाहिए।

Validator report आमतौर पर specific spec section दिखाता है। Fix source में करें; gPdf से generate कर रहे हैं तो API इन्हें auto-handle करती है और validator आपकी public receipt है।

TL;DR

PDF/A-3 = PDF/A-2 + arbitrary files को legally embed करने की क्षमता। इसी से EU e-invoicing practical बनती है: human-readable invoice और structured EN 16931 CII XML, एक archival wrapper में। Compliance के लिए PDF/A-3 wrapper और attached XML, दोनों pass होने चाहिए।

POST /api/v1/e-invoice/render से generate करें। validator पर verify करें। तीन engines (veraPDF + gPdf edge + Mustang), एक upload, free।