PDF/A là phiên bản PDF dành cho lưu trữ: lời hứa rằng tài liệu năm 2050 sẽ render giống như năm 2026. Có bốn profile chính (PDF/A-1, 2, 3, 4), mỗi profile có các mức conformance. Trong đó, PDF/A-3 là profile âm thầm vận hành e-invoicing của EU, và là profile PDF/A được dùng rộng rãi duy nhất cho phép gắn arbitrary file attachments trong archival wrapper.
Nếu bạn làm invoice, hồ sơ pháp lý hoặc bất kỳ workflow “PDF + structured data” nào, PDF/A-3 sẽ xuất hiện. Dưới đây là ý nghĩa thực tế, điểm khác biệt và cách verify file có compliant thật không.
Họ PDF/A trong một bảng
| Profile | ISO part | Year | Điểm định nghĩa |
|---|---|---|---|
| PDF/A-1 | 19005-1 | 2005 | Profile lưu trữ đầu tiên. Không transparency, không JavaScript, fonts embedded. |
| PDF/A-2 | 19005-2 | 2011 | Thêm JPEG2000, transparency và layer support. Print fidelity tốt hơn. |
| PDF/A-3 | 19005-3 | 2012 | Thêm embedded file attachments. Wrapper cho Factur-X / ZUGFeRD. |
| PDF/A-4 | 19005-4 | 2020 | Bản hiện đại; conformance model sạch hơn, không tách b và a. |
Các sub-level:
- b (basic): giữ visual fidelity, không đảm bảo semantic structure.
- a (accessible): structure tagging + Unicode mapping cho screen reader.
- u (Unicode): có Unicode mapping nhưng không có full structure.
- e / f (chỉ PDF/A-4): engineering 3D content và full forms.
“PDF/A-3b” nghĩa là profile lưu trữ 3, cho phép attachments, ở mức basic không yêu cầu accessibility tagging. Đây là variant phổ biến nhất trong invoicing.
PDF/A-3 đặc biệt ở đâu
PDF/A-1 và PDF/A-2 cấm arbitrary embedded files. Lý do: PDF lưu trữ phải self-contained; nếu có data.xlsx bên trong, attachment đó có thể hỏng hoặc lỗi thời độc lập với PDF và làm vỡ cam kết lưu trữ.
PDF/A-3 nới quy tắc đó với điều kiện chặt: mọi embedded file phải khai báo AFRelationship, nói rõ file liên hệ thế nào với visible PDF content. Giá trị hợp lệ là Source, Data, Alternative, Supplement, Unspecified. PDF cũng phải liệt kê attachment trong array /AF và emit XMP metadata mô tả attached file.
Nói cách khác, PDF/A-3 cho phép đính kèm, nhưng bắt bạn nói rõ đó là gì và liên quan gì tới phần con người nhìn thấy. Đây là lý do nó trở thành nền tảng e-invoicing: invoice đọc được nằm trong PDF, EN 16931 CII XML đọc bằng máy nằm trong attachment, và AFRelationship="Alternative" tuyên bố hai phần là hai representation của cùng một invoice.
PDF/A-3 trong production
- Factur-X (Pháp, B2B bắt buộc dần từ 2026): PDF/A-3 + CII XML, với XMP namespace
urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#. - ZUGFeRD 2.x (Đức, bắt buộc nhận từ 2025): PDF/A-3 + CII XML, với XMP namespace
urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#. - Engineering CAD archival: PDF/A-3 kèm native CAD file. PDF là rendering, CAD là source.
- Regulatory submissions: PDF/A-3 kèm XML payloads, như FDA submissions hoặc ESEF financial reports của issuer niêm yết EU.
Trong các trường hợp này, wrapper không chỉ là container. Nó là contract rằng PDF và attached file là cùng một document, và cả hai phải validate.
Cách verify PDF/A-3 compliance
Conformance checker chính thức là veraPDF (verapdf.org), do PDF Association duy trì. Nó implement rule set ISO 19005-3; nếu veraPDF báo “Pass — PDF/A-3b”, đó là tín hiệu mạnh nhất từ một engine đơn.
Nhưng single-engine “Pass” không phải audit-grade standard (Why two PDF/A validators are better than one giải thích lý do). Pattern audit-grade là chạy hai independent engines và chỉ coi file compliant khi cả hai pass.
Với e-invoice, bạn còn cần Mustang (mustangproject.org), checker de-facto cho Factur-X / ZUGFeRD. Mustang validate embedded CII XML theo EN 16931 Schematron. PDF/A-3 conformance thôi chưa đủ; attached XML cũng phải valid EN 16931, nếu không AP system của bên nhận sẽ reject invoice.
Nhiều team cài Java, setup veraPDF CLI, cài Mustang rồi viết shell script gộp output. Chạy được, nhưng nhiều friction.
validator chạy cả ba trong browser:
- veraPDF: official reference, PDF/A-3 conformance.
- gPdf Rust+WASM edge engine: independent re-implementation, second opinion.
- Mustang: EN 16931 CII XML Schematron cho embedded e-invoice payloads.
Drop file, ba engine chạy parallel, report trả về side-by-side. Có thể download JSON làm QA evidence. Không login, không quota.
Cần nhìn gì trong report
Failure thường rơi vào các nhóm:
- Embedded file metadata missing: thiếu array
/AF, hoặc embedded file không được listed trong đó. - AFRelationship missing or wrong: e-invoice phải là
Alternative; nhiều PDF libraries default sangSourcehoặcData. - XMP namespace missing or wrong: Factur-X và ZUGFeRD có URI namespace riêng; sai một ký tự cũng fail.
- Fonts not subsetted or not embedded: PDF/A yêu cầu mọi glyphs dùng trong document phải embedded cùng font.
- Output intent missing: PDF/A yêu cầu colour intent (sRGB hoặc ICC profile khác), kể cả document chỉ là text đen trắng.
- Document metadata incomplete: information dictionary phải có
/Title,/Producer,/CreationDate.
Report thường chỉ rõ spec section. Hãy sửa từ source; nếu generate bằng gPdf, API tự xử lý các yêu cầu này và validator là public receipt.
TL;DR
PDF/A-3 = PDF/A-2 + khả năng embed arbitrary files hợp lệ. Khả năng này làm EU e-invoicing khả thi: human-readable invoice + structured EN 16931 CII XML trong một archival wrapper. PDF/A-3 wrapper và attached XML đều phải pass.
Generate bằng POST /api/v1/e-invoice/render. Verify tại validator. Ba engines (veraPDF + gPdf edge + Mustang), một upload, miễn phí.