gPdf render/edge
Blog

PDF/A-3 dijelaskan: dan cara memastikan file benar-benar compliant

PDF/A-3 adalah profil PDF/A umum yang membolehkan lampiran legal, dasar e-invoicing Factur-X / ZUGFeRD. Perbedaan, titik cek, dan validasi dua mesin.

by Tim Engineering gPdf
#pdf-a#compliance#archival#e-invoice

PDF/A adalah versi arsip dari PDF: janji bahwa dokumen akan tampil sama pada 2050 seperti pada 2026. Ada empat profil utama (PDF/A-1, 2, 3, 4) dengan level conformance masing-masing. Di antara semuanya, PDF/A-3 adalah profil yang menjadi fondasi e-invoicing Uni Eropa, sekaligus satu-satunya profil PDF/A yang umum dipakai dan mengizinkan lampiran file arbitrer di dalam wrapper arsip.

Jika Anda menyentuh invoice, filing regulasi, atau workflow “PDF + structured data”, PDF/A-3 akan muncul. Berikut penjelasan praktis: apa bedanya, bagaimana dipakai, dan cara memverifikasi file benar-benar compliant.

Keluarga PDF/A secara ringkas

ProfileISO partYearCiri utama
PDF/A-119005-12005Profil arsip pertama. Tanpa transparency, tanpa JavaScript, font embedded.
PDF/A-219005-22011Menambah JPEG2000, transparency, dan layer support. Print fidelity lebih baik.
PDF/A-319005-32012Menambah embedded file attachments. Wrapper untuk Factur-X / ZUGFeRD.
PDF/A-419005-42020Revisi modern; model conformance lebih bersih, tanpa split b vs a.

Sub-level yang umum:

  • b (basic): visual fidelity terjaga, tanpa jaminan struktur semantik.
  • a (accessible): structure tagging + Unicode mapping untuk screen reader.
  • u (Unicode): Unicode mapping tanpa struktur penuh.
  • e / f (PDF/A-4 saja): engineering 3D content dan full forms.

Jadi “PDF/A-3b” berarti profile arsip 3 yang mengizinkan attachment, dengan level basic. Ini varian paling umum untuk invoicing.

Apa yang spesial dari PDF/A-3

PDF/A-1 dan PDF/A-2 melarang arbitrary embedded files. Alasannya: PDF arsip harus self-contained; attachment seperti data.xlsx bisa rusak atau usang terpisah dari PDF, sehingga janji arsipnya runtuh.

PDF/A-3 melonggarkan aturan itu dengan syarat ketat: setiap embedded file harus mendeklarasikan AFRelationship, yaitu bagaimana file tersebut berhubungan dengan konten PDF yang terlihat. Nilai validnya Source, Data, Alternative, Supplement, Unspecified. PDF juga harus mencantumkan attachment di array /AF dan mengeluarkan XMP metadata yang menjelaskan file tersebut.

Dengan kata lain: PDF/A-3 memperbolehkan attachment, tetapi menuntut deklarasi jelas tentang apa file itu dan hubungannya dengan apa yang dilihat manusia. Inilah yang membuatnya menjadi kendaraan e-invoicing: invoice yang dibaca manusia berada di PDF, XML CII EN 16931 berada di attachment, dan AFRelationship="Alternative" menyatakan keduanya adalah representasi alternatif dari invoice yang sama.

PDF/A-3 di production

  • Factur-X (Prancis, B2B wajib bertahap mulai 2026): PDF/A-3 + CII XML, dengan namespace XMP urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
  • ZUGFeRD 2.x (Jerman, penerimaan wajib mulai 2025): PDF/A-3 + CII XML, dengan namespace XMP urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
  • Arsip CAD engineering: PDF/A-3 dengan file CAD native sebagai attachment. PDF adalah rendering, CAD adalah source.
  • Submisi regulasi: PDF/A-3 dengan XML payloads, seperti FDA submissions atau ESEF financial reports untuk issuer UE.

Dalam semua ini, wrapper bukan sekadar container. Ia adalah contract bahwa PDF dan file terlampir adalah dokumen yang sama, dan keduanya harus validate.

Cara memverifikasi PDF/A-3

Conformance checker resmi adalah veraPDF (verapdf.org), dikelola oleh PDF Association. Ia mengimplementasikan ruleset ISO 19005-3; jika veraPDF melaporkan “Pass — PDF/A-3b”, itu sinyal terkuat dari satu engine.

Namun single-engine “Pass” bukan standar audit (Why two PDF/A validators are better than one menjelaskan alasannya). Pola audit-grade adalah menjalankan dua independent engines dan menerima file hanya jika keduanya pass.

Untuk e-invoice, ada lapisan lain: Mustang (mustangproject.org), checker de-facto untuk Factur-X / ZUGFeRD. Mustang memvalidasi embedded CII XML terhadap EN 16931 Schematron. PDF/A-3 conformance saja tidak cukup; XML terlampir juga harus valid EN 16931, atau sistem AP penerima akan menolak invoice.

Banyak tim memasang Java, veraPDF CLI, Mustang, lalu menulis shell script untuk menggabungkan output. Bisa, tetapi menambah friction.

validator menjalankan ketiganya di browser:

  1. veraPDF: reference resmi untuk PDF/A-3 conformance.
  2. gPdf Rust+WASM edge engine: implementasi independen sebagai second opinion.
  3. Mustang: EN 16931 CII XML Schematron untuk embedded e-invoice payloads.

Drop file, ketiga engine berjalan paralel, report tampil berdampingan. JSON bisa diunduh untuk QA evidence. Tanpa login, tanpa quota.

Apa yang perlu dilihat di report

Failure biasanya berkumpul di area berikut:

  • Embedded file metadata missing: array /AF tidak ada, atau embedded file tidak listed di sana.
  • AFRelationship missing atau wrong: untuk e-invoice harus Alternative; banyak PDF libraries default ke Source atau Data.
  • XMP namespace missing atau wrong: Factur-X dan ZUGFeRD punya URI spesifik; satu karakter salah bisa fail.
  • Fonts not subsetted or not embedded: PDF/A mewajibkan semua glyph yang digunakan embedded bersama font.
  • Output intent missing: PDF/A butuh colour intent (sRGB atau ICC profile lain), meski dokumen hanya teks hitam-putih.
  • Document metadata incomplete: /Title, /Producer, /CreationDate harus ada di information dictionary.

Report biasanya menunjuk spec section spesifik. Perbaiki di source; jika generate via gPdf, API menangani semuanya dan validator menjadi public receipt.

TL;DR

PDF/A-3 = PDF/A-2 + kemampuan legal untuk embed arbitrary files. Inilah yang membuat EU e-invoicing praktis: invoice untuk manusia + XML CII EN 16931 terstruktur, dalam satu archival wrapper. Wrapper PDF/A-3 dan attached XML harus sama-sama pass.

Generate lewat POST /api/v1/e-invoice/render. Verifikasi di validator. Tiga engine (veraPDF + gPdf edge + Mustang), satu upload, gratis.