Jika Anda engineer yang baru saja diberi tahu bahwa “invoice harus PDF/A-3 with Factur-X pada kuartal berikutnya”, dan satu-satunya konteks Anda adalah seseorang dari legal mengucapkan kata-kata itu, post ini untuk Anda.

Kita akan memotong nada dokumen standar dan menjelaskan apa yang sebenarnya dibatasi oleh profil ini, mengapa pemerintah mulai mewajibkannya, dan pipeline praktis terkecil untuk mengeluarkan PDF compliant dari renderer berbasis data terstruktur.

PDF/A dalam dua paragraf

PDF adalah format yang fleksibel. Terlalu fleksibel — spec PDF yang sama membolehkan Anda embed JavaScript, link ke external resources yang mungkin tidak ada lagi dalam 50 tahun, mengenkripsi content dengan kriptografi yang bisa dibalik, reference external fonts, dan banyak hal lain yang membuat document tidak self-contained.

PDF/A, dengan “A” untuk Archival, adalah profile PDF yang melarang bagian-bagian yang bisa mencegah document render identically dalam 50 tahun. Aturan tingkat tinggi:

Semua fonts harus embedded.
Tidak ada JavaScript, external links, audio/video.
Tidak ada encryption.
Semua transparency harus flatten atau didukung oleh profile version.
Colours harus device-independent; ICC profile diperlukan.
Semua content harus berada di dalam file, tanpa references yang bergantung pada network.

Ada beberapa versions, masing-masing menambahkan toleransi untuk newer features:

Profile	Year	Apa yang ditambahkan
PDF/A-1b	2005	Original baseline, paling ketat
PDF/A-2b	2011	Membolehkan JPEG2000, transparency, layers
PDF/A-3b	2012	Membolehkan arbitrary file attachments, fondasi Factur-X
PDF/A-4	2020	Basis ISO 32000-2 (PDF 2.0), conformance levels disederhanakan

Suffix “b” berarti “basic” conformance, yaitu visual fidelity. Ada juga variants “u” untuk unicode-mapped dan “a” untuk accessibility-tagged. Untuk sebagian besar workflow invoice/receipt, “b” adalah yang Anda butuhkan, karena tax archival peduli pada visual reproducibility, bukan screen-reader semantics.

Practical takeaway: jika renderer Anda mengatakan mendukung PDF/A-3b, itu seharusnya single config flag seperti { profile: "PDF/A-3b" } atau equivalent. Jika Anda harus menjalankan tool kedua seperti Ghostscript, qpdf, atau Acrobat untuk convert setelahnya, itu workflow gap yang perlu dihitung dalam ops.

Mengapa PDF/A-3 penting secara khusus: ini carrier untuk e-invoices

PDF/A-3 menambahkan satu capability yang terdengar biasa tetapi ternyata sangat penting: arbitrary file attachments di dalam PDF.

Kedengarannya membosankan. Bukan. Ini adalah seluruh technical foundation untuk e-invoice mandates yang sedang rollout di Eropa.

Arsitekturnya: satu PDF file yang sekaligus:

Human-readable invoice, dengan visual layout, totals, branding.
Machine-readable XML invoice, bagian yang di-parse software otoritas pajak.

Keduanya berada dalam satu file, keduanya merepresentasikan invoice yang sama, dan PDF/A-3 wrapper menjamin file tetap parseable selama beberapa dekade.

Format XML utama:

Factur-X (France), XML profile berbasis UN/CEFACT Cross Industry Invoice.
ZUGFeRD (Germany), secara substansi identik dengan Factur-X; dua standard ini merge secara teknis pada 2018.
EN 16931, norma Eropa yang diikuti kedua implementation.

Untuk sebagian besar workflows, “Factur-X” dan “ZUGFeRD” adalah istilah yang interchangeable. Mereka share schema, share embedding mechanism, dan satu PDF yang compliant dengan salah satunya umumnya compliant dengan yang lain.

Apa yang wajib, di mana, kapan

Snapshot non-exhaustive untuk engineers yang merencanakan rollout Q2/Q3 2026:

Country	Status	Required format
Germany	B2B mandatory untuk invoice receipt sejak 2025-01-01; mulai 2027 juga untuk issuing	EN 16931 (Factur-X / ZUGFeRD / XRechnung)
France	mandatory issuing untuk large enterprises 2026-09; SMEs 2027-09	Factur-X via Chorus Pro
Italy	B2B mandatory since 2019	FatturaPA via SDI
Poland	Mandatory since 2024-07	KSeF
Spain	Mandatory from 2026 (B2B)	Facturae via FACe
Belgium	Mandatory from 2026-01	Peppol BIS 3

Polanya: setiap EU member state sedang mengimplementasikan flavour tertentu dari EN 16931-compliant e-invoicing pada timeline 2024-2027. Jika customers Anda beroperasi di salah satu market ini, PDF generator Anda perlu emit attached XML bersama visual invoice.

Pipeline praktis terkecil

Lupakan sebentar apa yang ditentukan standards documents. Ini engineering view:

   ┌─────────────────────┐
   │  Your invoice data  │  (sudah berupa JSON object di suatu tempat)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Build EN 16931 XML  │  (deterministic mapping; tested libs ada)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │ Render PDF/A-3b +   │
   │ attach the XML      │  (single API call ke gPdf, atau two-step di tempat lain)
   └─────────┬───────────┘
             │
             ▼
   ┌─────────────────────┐
   │  Hand off to        │
   │  Chorus Pro / SDI / │
   │  Peppol / etc       │
   └─────────────────────┘

Dua step non-trivial:

Step 1: build XML

Ini menjengkelkan tetapi mekanis. Anda memetakan invoice data seperti lines, taxes, totals, dan parties ke field names XML EN 16931. Beberapa library Java/Node/Python melakukan ini untuk Anda; cari “factur-x library” dalam language Anda. Jangan menulis dari scratch kecuali Anda benar-benar menikmati XML schema specs.

Step 2: render PDF/A-3 dan attach XML

Di sinilah pilihan renderer penting.

Tanpa built-in support: Anda render ordinary PDF, lalu post-process dengan tool yang convert ke PDF/A-3 dan attach XML sebagai embedded file. Common stacks: Ghostscript + qpdf, atau paid tool seperti Aspose. Dua extra steps, dua extra failure points, dan Anda harus memastikan post-processing tidak membuat visual layout drift.

Dengan built-in support (pendekatan gPdf): one call.

curl -X POST https://gpdf.com/api/v1/e-invoice/render \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "document": {
      "pages": [{ "size": "a4", "elements": [...] }]
    },
    "einvoice": {
      "format": "factur-x",
      "profile": "BASIC",
      "xml": "<rsm:CrossIndustryInvoice>...</rsm:CrossIndustryInvoice>"
    }
  }' \
  --output invoice-with-einvoice.pdf

Itulah seluruh pipeline. Renderer emit PDF/A-3b, attach XML Anda sebagai factur-x.xml atau zugferd-invoice.xml, keduanya dikenali oleh consumers, lalu return bytes.

Jebakan umum

Beberapa hal sering dipelajari dengan cara sulit:

“PDF/A” dan “dengan PDF/A-compliant fonts” bukan hal yang sama

PDF/A-3 file mengharuskan semua fonts embedded dengan full character coverage untuk glyphs yang dipakai. Jika invoice memiliki nama customer Jepang dan renderer fallback ke font yang tidak fully embeddable, validation tools akan reject. Pastikan renderer Anda embed CJK fonts dalam PDF/A mode; banyak yang tidak melakukan itu by default.

Visual + XML harus cocok

XML invoice dan visual invoice seharusnya merepresentasikan invoice yang sama. Tax auditors akan diff keduanya. Jika code emit XML dengan total: 119.00 dan visual PDF menampilkan Total: 120.00 karena rounding bug atau stale template, Anda memiliki tax discrepancy di file. Generate keduanya dari same source-of-truth, idealnya di code path yang sama.

Level “profile” dalam EN 16931

Factur-X memiliki profiles: MINIMUM, BASIC, EN 16931, EXTENDED. Mereka berbeda pada seberapa banyak data di XML. Gunakan BASIC kecuali customer specifically meminta lebih; ini mencakup tax codes, line items, parties, totals, cukup untuk sekitar 95% B2B invoicing. EN 16931 profile menambahkan detail untuk edge cases.

Validation sebelum submission

Selalu validate generated PDF terhadap PDF/A validator; veraPDF adalah open-source standard. Validate juga XML terhadap schema EN 16931 sebelum ship ke tax authority. Failed submissions ke Chorus Pro / SDI memengaruhi reliability metrics Anda dengan regulator.

TL;DR

PDF/A adalah self-contained-document profile. PDF/A-3 memungkinkan attach files. Factur-X / ZUGFeRD berarti “EN 16931 XML attached di dalam PDF/A-3”. E-invoice mandates di seluruh EU membuat kombinasi ini menjadi de facto B2B invoice format pada 2025-2027.

Jika renderer Anda memperlakukan PDF/A-3 + Factur-X sebagai single config flag, migrasi mekanis. Jika tidak, Anda sedang membangun multi-step ops pipeline. /api/v1/e-invoice/render gPdf adalah single-flag version; API reference memiliki full schema, atau coba sample render di Playground.