PDF/A คือ PDF สำหรับงานเก็บถาวร: สัญญาว่าเอกสารที่เห็นในปี 2026 จะยัง render เหมือนเดิมในปี 2050 มี profile หลักคือ PDF/A-1, 2, 3 และ 4 พร้อมระดับ conformance ย่อย ในกลุ่มนี้ PDF/A-3 คือ profile ที่รองรับ e-invoicing ของยุโรปอยู่เบื้องหลัง และเป็น PDF/A profile ที่ใช้งานกว้างขวางเพียงตัวเดียวซึ่งอนุญาตให้มี arbitrary file attachments ภายใน archival wrapper

ถ้าคุณทำงานกับ invoice, regulatory filing หรือ workflow แบบ “PDF + structured data” คุณจะเจอ PDF/A-3 แน่นอน บทนี้สรุปว่ามันคืออะไร ต่างจาก profile อื่นอย่างไร และควร verify อย่างไร

ครอบครัว PDF/A แบบย่อ

Profile	ISO part	Year	จุดสำคัญ
PDF/A-1	19005-1	2005	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 เป็น wrapper ของ Factur-X / ZUGFeRD
PDF/A-4	19005-4	2020	revision สมัยใหม่ conformance model สะอาดขึ้น ไม่มีการแยก `b` กับ `a`

Sub-level ที่พบบ่อย:

b (basic): รักษาความถูกต้องทางภาพ แต่ไม่รับประกัน semantic structure
a (accessible): มี structure tagging และ Unicode mapping สำหรับ screen reader
u (Unicode): มี Unicode mapping แต่ไม่มีโครงสร้างเต็ม
e / f (เฉพาะ PDF/A-4): engineering 3D content และ full forms

ดังนั้น “PDF/A-3b” หมายถึง archival profile 3 ที่อนุญาต attachments พร้อม basic level ที่ไม่บังคับ accessibility tagging นี่คือ variant ที่พบมากที่สุดในงาน invoicing

PDF/A-3 พิเศษอย่างไร

PDF/A-1 และ PDF/A-2 ห้าม arbitrary embedded files เหตุผลคือ archival PDF ควร self-contained หากมี data.xlsx แนบอยู่ ไฟล์แนบนั้นอาจเสื่อมหรือใช้งานไม่ได้แยกจาก PDF และทำให้สัญญาการเก็บถาวรเสียหาย

PDF/A-3 ผ่อนกฎนี้ภายใต้เงื่อนไขเข้มงวด: embedded file ทุกไฟล์ต้องประกาศ AFRelationship เพื่อบอกว่าไฟล์นั้นสัมพันธ์กับ visible PDF content อย่างไร ค่า valid คือ Source, Data, Alternative, Supplement, Unspecified ตัว PDF ยังต้อง list attachment ใน array /AF และ emit XMP metadata อธิบาย attached file ด้วย

พูดง่าย ๆ PDF/A-3 อนุญาตให้แนบไฟล์ได้ แต่ต้องประกาศชัดว่าไฟล์คืออะไร และเกี่ยวข้องกับสิ่งที่มนุษย์เห็นอย่างไร นี่คือฐานของ e-invoicing: invoice ที่คนอ่านได้อยู่ใน PDF, EN 16931 CII XML ที่เครื่องอ่านได้อยู่ใน attachment และ AFRelationship="Alternative" บอกว่าทั้งสองเป็น representation ทางเลือกของ invoice เดียวกัน

PDF/A-3 อยู่ตรงไหนใน production

Factur-X (ฝรั่งเศส, B2B เริ่มบังคับเป็นลำดับจาก 2026): PDF/A-3 + CII XML พร้อม XMP namespace urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#
ZUGFeRD 2.x (เยอรมนี, บังคับรับตั้งแต่ 2025): PDF/A-3 + CII XML พร้อม XMP namespace urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#
Engineering CAD archival: PDF/A-3 พร้อม native CAD file แนบอยู่ PDF คือ rendering ส่วน CAD คือ source
Regulatory submissions: PDF/A-3 พร้อม XML payloads เช่น FDA submissions หรือ ESEF financial reports ของบริษัทจดทะเบียนใน EU

ในกรณีเหล่านี้ wrapper ไม่ใช่แค่ container แต่เป็น contract ว่า PDF และ attached file คือเอกสารเดียวกัน และทั้งสองต้อง validate ผ่าน

วิธี verify ว่า PDF/A-3 compliant

Conformance checker ทางการคือ veraPDF (verapdf.org) ดูแลโดย PDF Association และ implement rule set ของ ISO 19005-3 ถ้า veraPDF รายงาน “Pass — PDF/A-3b” นั่นคือ signal ที่แข็งที่สุดจาก engine เดียว

แต่ single-engine “Pass” ยังไม่ใช่ audit-grade standard (Why two PDF/A validators are better than one อธิบายไว้) รูปแบบที่ใช้ตรวจระดับ audit คือรัน สอง independent engines และถือว่า file compliant เฉพาะเมื่อทั้งสอง pass

สำหรับ e-invoice ต้องมีอีกชั้นคือ Mustang (mustangproject.org) ซึ่งเป็น checker de-facto ของ Factur-X / ZUGFeRD มัน validate embedded CII XML กับ EN 16931 Schematron แค่ PDF/A-3 conformance ไม่พอ เพราะ attached XML ต้อง valid EN 16931 ด้วย ไม่เช่นนั้น AP system ฝั่งรับจะ reject invoice

หลายทีมติดตั้ง Java, ตั้งค่า veraPDF CLI, ติดตั้ง Mustang แล้วเขียน shell script รวม output ใช้ได้ แต่มี friction

validator รันทั้งสามใน browser:

veraPDF: official reference สำหรับ PDF/A-3 conformance
gPdf Rust+WASM edge engine: independent re-implementation เป็น second opinion
Mustang: EN 16931 CII XML Schematron สำหรับ embedded e-invoice payloads

Drop file แล้วสาม engine จะ run parallel และ report จะกลับมา side-by-side ดาวน์โหลด JSON เป็น QA evidence ได้ ไม่มี login ไม่มี quota

ต้องดูอะไรใน report

Failures มักอยู่ในกลุ่มต่อไปนี้:

Embedded file metadata missing: ไม่มี array /AF หรือ embedded file ไม่ได้ listed อยู่ในนั้น
AFRelationship missing or wrong: e-invoice ควรเป็น Alternative; PDF libraries หลายตัว default เป็น Source หรือ Data
XMP namespace missing or wrong: Factur-X และ ZUGFeRD มี namespace URI เฉพาะ typo หนึ่งตัวก็ fail
Fonts not subsetted or not embedded: PDF/A ต้องการให้ glyphs ที่ใช้ทั้งหมด embedded พร้อม font
Output intent missing: PDF/A ต้องมี colour intent เช่น sRGB หรือ ICC profile อื่น แม้เอกสารจะเป็นขาวดำ
Document metadata incomplete: information dictionary ต้องมี /Title, /Producer, /CreationDate

Report มักชี้ไปยัง spec section ที่เกี่ยวข้อง แก้ที่ source; ถ้า generate ด้วย gPdf API จะจัดการกฎเหล่านี้ให้อัตโนมัติ และ validator คือ public receipt ของคุณ

TL;DR

PDF/A-3 = PDF/A-2 + ความสามารถในการ embed arbitrary files อย่างถูกต้อง ความสามารถนี้ทำให้ EU e-invoicing ใช้งานจริงได้: human-readable invoice + structured EN 16931 CII XML ใน archival wrapper เดียว ทั้ง PDF/A-3 wrapper และ attached XML ต้อง pass

Generate ด้วย POST /api/v1/e-invoice/render และ verify ที่ validator สาม engines (veraPDF + gPdf edge + Mustang), upload ครั้งเดียว, ฟรี