PDF/A là phiên bản PDF dành cho lưu trữ, một cam kết rằng tài liệu sẽ render giống nhau vào năm 2050 như nó render trong năm 2026. Có bốn profile lớn (PDF/A-1, 2, 3, 4), mỗi profile có các mức sub-conformance. Trong đó, PDF/A-3 là profile âm thầm vận hành e-invoicing của EU, và là profile được dùng rộng rãi duy nhất cho phép arbitrary file attachments bên trong archival wrapper.
Nếu bạn chạm vào invoice, regulatory filings hoặc bất kỳ workflow “PDF + structured data” nào, PDF/A-3 là spec bạn sẽ gặp. Dưới đây là nó là gì, khác các profile anh em ra sao, và cách xác thực một file thật sự compliant.
Gia đình PDF/A trong một đoạn
| Profile | ISO part | Năm | Đặc điểm định nghĩa |
|---|---|---|---|
| PDF/A-1 | 19005-1 | 2005 | Archival profile đầu tiên. Không transparency, không JavaScript, font 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 | Revision hiện đại; mô hình conformance sạch hơn, không chia b và a. |
Mỗi profile có sub-level:
- b (basic): giữ fidelity thị giác. Ai cũng đọc được; không bảo đảm semantic content.
- a (accessible): structure tagging + Unicode mapping. Screen reader có thể extract text theo đúng thứ tự.
- u (Unicode): Unicode mapping nhưng không full structure. Mức trung gian.
- e / f (chỉ PDF/A-4): thêm engineering 3D content và full forms.
Vì vậy “PDF/A-3b” nghĩa là: archival profile 3 (cho phép attachments), basic level (không yêu cầu accessibility tagging). Đây là biến thể phổ biến nhất trong invoicing.
PDF/A-3 có gì đặc biệt
PDF/A-1 và PDF/A-2 cấm arbitrary embedded files. Lý do: PDF lưu trữ phải self-contained; một data.xlsx nhúng có thể hỏng độc lập với PDF, phá vỡ bảo đảm archival.
PDF/A-3 nới quy tắc đó trong một điều kiện rất rõ: mọi embedded file phải được khai báo bằng thuộc tính AFRelationship, nói file đó liên hệ thế nào với nội dung PDF nhìn thấy. Giá trị hợp lệ gồm Source, Data, Alternative, Supplement, Unspecified. PDF declaration cũng phải liệt kê attachment trong mảng /AF và emit XMP metadata mô tả file được attach.
Nói cách khác, PDF/A-3 nói: “bạn có thể attach thứ khác, nhưng chỉ khi khai báo chính xác chúng là gì và liên hệ thế nào với thứ con người nhìn thấy”. Khai báo đó biến PDF/A-3 thành phương tiện cho e-invoicing: invoice con người đọc được nằm trong PDF, EN 16931 CII XML máy đọc được nằm trong attachment, và AFRelationship="Alternative" khai báo rằng hai thứ là hai biểu diễn thay thế của cùng invoice.
PDF/A-3 sống ở đâu trong production
- Factur-X (Pháp, bắt buộc B2B từ 2026 trở đi): 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 invoice từ 2025): PDF/A-3 + CII XML, với XMP namespace
urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#. - Lưu trữ CAD engineering: PDF/A-3 kèm native CAD file. PDF là bản render; CAD là source.
- Regulatory submissions: PDF/A-3 kèm XML payloads, ví dụ FDA submissions hoặc ESEF financial reports cho EU-listed issuers.
Trong tất cả trường hợp này, wrapper không chỉ là container. Nó là một contract nói rằng “PDF này và file attach này là cùng một tài liệu, và cả hai đều phải validate”.
Cách xác thực file compliant PDF/A-3
Conformance checker chính thức là veraPDF (verapdf.org), do PDF Association duy trì. Nó triển khai rule set ISO 19005-3; nếu veraPDF báo “Pass — PDF/A-3b”, đó là tín hiệu mạnh nhất mà một engine đơn có thể đưa ra.
Nhưng “Pass” từ một engine đơn chưa phải chuẩn audit-grade (Why two PDF/A validators are better than one giải thích lý do). Pattern đạt mức audit là chạy hai engine độc lập và chỉ xem file là compliant khi cả hai đều pass.
Với file e-invoice cụ thể, còn một engine thứ hai nữa bạn cần: Mustang (mustangproject.org), checker de-facto cho Factur-X / ZUGFeRD, validate CII XML nhúng theo EN 16931 Schematron. Chỉ compliant PDF/A-3 là chưa đủ; XML attach cũng phải valid EN 16931, nếu không hệ thống AP phía nhận sẽ reject invoice.
Phần lớn đội cài Java, set up veraPDF CLI, cài Mustang, rồi viết shell script nối output. Cách đó chạy được nhưng có friction.
validator chạy cả ba trong browser:
- veraPDF: reference chính thức, PDF/A-3 conformance.
- Engine Edge Rust+WASM của gPdf: independent re-implementation, xác nhận second opinion.
- Mustang: EN 16931 CII XML Schematron cho payload e-invoice nhúng.
Thả file vào, cả ba chạy song song, report trả về cạnh nhau. JSON có thể tải xuống làm bằng chứng QA. Không login, không quota.
Nên nhìn gì trong report PDF/A-3
Khi chạy validator và một engine báo lỗi, failure thường gom vào vài nhóm:
- Thiếu embedded file metadata: không có mảng
/AF, hoặc embedded file không được liệt kê trong đó. - Thiếu hoặc sai AFRelationship: với e-invoice nên là
Alternative;Source/Datalà mặc định của nhiều PDF library. - Thiếu hoặc sai XMP namespace: Factur-X và ZUGFeRD có namespace URI cụ thể; sai một ký tự cũng fail check.
- Font không subset hoặc không embedded: PDF/A yêu cầu mọi glyph dùng trong tài liệu được embed với font. Edge case: một font reference được khai báo nhưng chưa thật sự dùng vẫn có thể fail.
- Thiếu output intent: PDF/A yêu cầu khai báo colour intent (sRGB hoặc ICC profile khác) ngay cả khi tài liệu chỉ là text đen trắng.
- Document metadata chưa đủ:
/Title,/Producer,/CreationDatephải có trong document info dictionary.
Mỗi lỗi đều có section spec cụ thể mà validator trỏ tới trong report. Bạn sửa ở source, hoặc nếu generate qua gPdf thì API auto-handle các phần này và validator là biên nhận public của bạn.
TL;DR
PDF/A-3 = PDF/A-2 + khả năng embed arbitrary files một cách hợp lệ. Khả năng đó làm e-invoicing EU khả thi: invoice con người đọc được + EN 16931 CII XML có cấu trúc trong cùng một archival wrapper. Compliance yêu cầu wrapper pass PDF/A-3 và XML attach pass EN 16931. Cả hai phải pass trước khi bạn gửi file vào production.
Generate bằng POST /api/v1/e-invoice/render. Verify tại validator. Ba engine (veraPDF + gPdf Edge + Mustang), một upload, miễn phí.