Aturan e-invoice Kroasia 2026 memaksa pengembang PHP untuk merancang ulang validasi – file Schematron otoritas pajak bergantung pada XSLT 2.0, namun mesin XSLT PHP yang dominan hanya mendukung XSLT 1.0. Hasilnya: sebagian besar aplikasi akuntansi tidak dapat menjalankan 62 pemeriksaan aturan bisnis wajib tanpa solusi alternatif, dan faktur yang ditolak dapat menghentikan arus kas B2B.
Mengapa hambatan teknis ini penting
Mulai 1 Januari 2026, setiap transaksi B2B di Kroasia harus dipertukarkan sebagai e-Račun yang mematuhi 62 aturan validasi spesifik. Administrasi Pajak menerbitkan aturan-aturan tersebut dalam bentuk file Schematron – yang pada dasarnya adalah stylesheet XSLT 2.0 yang menandai pelanggaran. Library libxslt bawaan PHP, yang menggerakkan xsltproc populer dan sebagian besar paket Composer, hanya mengimplementasikan XSLT 1.0. Tanpa dukungan XSLT 2.0, Schematron tidak dapat diterapkan, yang berarti sistem penagihan berbasis PHP akan menghasilkan faktur yang ditolak oleh portal pajak atau harus memanggil bahasa atau layanan lain.
Tiga jalur yang dapat diambil pengembang
| Opsi | Apa yang dilakukan | Kekurangan praktis |
|---|---|---|
| Ekstensi SaxonC PECL | Instal prosesor Saxon-C sebagai ekstensi PHP asli, lalu panggil Schematron secara langsung. | Ekstensi ini bukan bagian dari alur kerja Composer yang umum; membangun dan menyebarkan biner asli di berbagai server menambah kompleksitas. |
| Layanan validasi eksternal | Kirim XML ke layanan web yang menjalankan Schematron atas nama Anda. | Setiap faktur kini bergantung pada latensi jaringan dan ketersediaan layanan; gangguan sementara dapat menghentikan proses penagihan sepenuhnya. |
| Implementasikan ulang aturan dalam PHP | Terjemahkan 62 asersi Schematron ke dalam kode PHP asli. | Memerlukan upaya di awal, tetapi setelah dikodekan, validator berjalan secara lokal, terintegrasi dengan bersih dengan stack PHP apa pun, dan menghilangkan ketergantungan eksternal. |
Logika tersembunyi yang menjebak implementasi sederhana
Terjemahan Schematron yang naif masih dapat melewatkan semantik yang halus. Ambil contoh aturan HR-BR-4: “Tanggal jatuh tempo harus ada jika jumlah yang harus dibayar lebih besar dari nol.” Schematron mendefinisikan variabel yang mengalikan jumlah faktur dengan –1 untuk nota kredit (credit notes). Dalam XML mentah, nota kredit menunjukkan jumlah positif, tetapi variabel tersebut membaliknya menjadi negatif, sehingga kondisi “lebih besar dari nol” menjadi salah (false). Jika validator hanya membaca teks asersi, ia akan menolak setiap nota kredit.
Pelajarannya jelas: baca definisi variabel dalam Schematron sebelum mengodekan kondisi PHP yang sesuai. Pola yang sama muncul di beberapa aturan lain di mana manipulasi aritmatika atau string tersembunyi di balik variabel $.
Pemicu penolakan umum
Meskipun aturan telah dikodekan dengan benar, pengembang sering mengabaikan elemen faktur yang dianggap sebagai kesalahan fatal oleh sistem pajak:
- Detail operator hilang – setiap faktur harus berisi nama lengkap operator dan OIB (nomor identifikasi pribadi Kroasia). Mengosongkan salah satu kolom akan memicu penolakan segera.
- Tag XML kosong – tag seperti
<cbc:Note></cbc:Note>menyebabkan validator crash. Menghapus elemen kosong atau mengisinya dengan string placeholder dapat menyelesaikan masalah ini. - Kode KPD salah – kode Klasifikacija proizvoda i usluga (KPD) harus setidaknya enam digit. Kode yang lebih pendek akan ditandai sebagai malformed.
- Tanggal tidak valid – faktur apa pun yang bertanggal sebelum 1 Januari 2026 akan gagal dalam aturan tanggal wajib, terlepas dari kebenaran elemen lainnya.
Jebakan pengujian
Administrasi Pajak menerbitkan contoh file e-Račun untuk pengembang. Contoh-contoh tersebut masih berisi tanggal tahun 2025 dan OIB yang tidak lolos perangkat aturan tahun 2026. Menggunakannya sebagai satu-satunya sumber kebenaran akan memberikan rasa kepatuhan yang palsu. Perlakukan sampel resmi sebagai pemeriksaan kewarasan parser (parser sanity check), lalu jalankan rangkaian penegakan aturan Anda sendiri terhadap data realistis yang dihasilkan oleh aplikasi Anda.
Solusi khusus PHP yang sudah tersedia
Seorang pengembang telah menyelesaikan jalur implementasi ulang, mengemas ke-62 aturan validasi sebagai library yang dapat diinstal melalui Composer untuk proyek Laravel. Library tersebut menangani aritmatika, cakupan variabel (variable scoping), dan pemeriksaan kasus tepi (edge-case) yang disembunyikan oleh Schematron, memungkinkan faktur divalidasi sepenuhnya di dalam runtime PHP. Dengan menghilangkan XSLT 2.0 dan panggilan eksternal, paket ini menawarkan jalur kepatuhan yang deterministik dan latensi rendah.
Kode sumber dan panduan penggunaan tersedia di repositori publik penulis (tautan disediakan dalam postingan asli).
Apa yang perlu diperhatikan selanjutnya
- Validator PHP berbasis komunitas – seiring semakin banyaknya pengembang yang mengadopsi pendekatan implementasi ulang, nantikan fork dan ekstensi yang menambahkan fixture unit-test, dukungan untuk framework lain, atau penyesuaian performa.
Intinya
Mandat e-invoice Kroasia tahun 2026 memaksa pengembang PHP untuk menghadapi ketidaksesuaian antara Schematron XSLT 2.0 yang modern dengan mesin XSLT 1.0 legacy milik bahasa tersebut. Menerjemahkan 62 aturan bisnis ke dalam PHP native, memperhatikan logika variabel tersembunyi, dan menghindari jebakan XML yang umum akan menjaga proses penagihan tetap dilakukan secara internal, menghindari kegagalan terkait jaringan, serta mempersiapkan perangkat lunak akuntansi untuk peluncuran yang lancar dan patuh saat tenggat waktu tiba.