La norma de facturación electrónica de Croacia para 2026 obliga a los desarrolladores de PHP a reinventar la validación – el archivo Schematron de la autoridad fiscal depende de XSLT 2.0, pero el motor XSLT dominante en PHP solo admite XSLT 1.0. El resultado: la mayoría de las aplicaciones de contabilidad no pueden ejecutar las 62 comprobaciones obligatorias de reglas de negocio sin una solución alternativa, y una factura rechazada puede detener el flujo de caja B2B.
Por qué importa este obstáculo técnico
A partir del 1 de enero de 2026, todas las transacciones B2B en Croacia deberán intercambiarse como un e-Račun que cumpla con 62 reglas de validación específicas. La Administración Tributaria publica esas reglas en un archivo Schematron, que es esencialmente una hoja de estilos XSLT 2.0 que señala las infracciones. La biblioteca integrada libxslt de PHP, que impulsa el popular xsltproc y la mayoría de los paquetes de Composer, solo implementa XSLT 1.0. Sin el soporte de XSLT 2.0, no se puede aplicar el Schematron, lo que significa que un sistema de facturación basado en PHP producirá facturas que el portal fiscal rechazará o tendrá que recurrir a otro lenguaje o servicio.
Tres caminos que pueden tomar los desarrolladores
| Opción | En qué consiste | Desventajas prácticas |
|---|---|---|
| Extensión SaxonC PECL | Instalar el procesador Saxon-C como una extensión nativa de PHP y luego invocar el Schematron directamente. | La extensión no forma parte del flujo de trabajo típico de Composer; la compilación y el despliegue de binarios nativos en diferentes servidores añade complejidad. |
| Servicio de validación externo | Enviar el XML a un servicio web que ejecute el Schematron en su nombre. | Cada factura depende ahora de la latencia de la red y de la disponibilidad del servicio; una interrupción temporal puede bloquear la facturación por completo. |
| Reimplementar las reglas en PHP | Traducir las 62 aserciones de Schematron a código PHP nativo. | Requiere un esfuerzo inicial, pero una vez codificado, el validador se ejecuta localmente, se integra limpiamente con cualquier stack de PHP y elimina las dependencias externas. |
La lógica oculta que hace fallar las implementaciones simples
Una traducción ingenua del Schematron aún puede pasar por alto semánticas sutiles. Tomemos la regla HR-BR-4: “Debe existir una fecha de vencimiento si el importe a pagar es superior a cero”. El Schematron define una variable que multiplica el importe de la factura por –1 para las notas de crédito. En el XML puro, una nota de crédito muestra un importe positivo, pero la variable lo convierte en negativo, por lo que la condición “mayor que cero” resulta falsa. Si el validador solo lee el texto de la aserción, rechazará todas las notas de crédito.
La lección es clara: lea las definiciones de las variables en el Schematron antes de codificar la condición PHP correspondiente. El mismo patrón aparece en varias otras reglas donde la manipulación aritmética o de cadenas se oculta tras una variable $.
Desencadenantes comunes de rechazo
Incluso con reglas correctamente codificadas, los desarrolladores suelen pasar por alto elementos de la factura que el sistema fiscal trata como errores fatales:
- Falta de detalles del operador – cada factura debe contener el nombre completo del operador y el OIB (número de identificación personal croata). Dejar cualquiera de los campos vacío provoca un rechazo inmediato.
- Etiquetas XML vacías – etiquetas como
<cbc:Note></cbc:Note>hacen que el validador falle. Eliminar los elementos vacíos o completarlos con una cadena de marcador de posición (placeholder) resuelve el problema. - Códigos KPD incorrectos – el código Klasifikacija proizvoda i usluga (KPD) debe tener al menos seis dígitos. Los códigos cortos se marcan como malformados.
- Fechas inválidas – cualquier factura con fecha anterior al 1 de enero de 2026 incumple la regla de fecha obligatoria, independientemente de su otra corrección.
Errores comunes en las pruebas
La Administración Tributaria publica archivos de ejemplo de e-Račun para los desarrolladores. Esos ejemplos todavía contienen fechas de 2025 y OIB que no pasan el conjunto de reglas de 2026. Utilizarlos como única fuente de verdad genera una falsa sensación de cumplimiento. Trate los ejemplos oficiales como una comprobación de integridad del analizador (parser sanity check) y luego ejecute su propia suite de aplicación de reglas con datos realistas generados por su aplicación.
La solución exclusiva de PHP que ya está disponible
Un desarrollador llevó a cabo la reimplementación por completo, empaquetando las 62 reglas de validación como una biblioteca instalable mediante Composer para proyectos Laravel. La biblioteca gestiona la aritmética, el alcance de las variables y las comprobaciones de casos límite que el Schematron oculta, lo que permite validar las facturas enteramente dentro del tiempo de ejecución de PHP. Al eliminar XSLT 2.0 y las llamadas externas, el paquete ofrece un camino determinista y de baja latencia hacia el cumplimiento normativo.
El código fuente y la guía de uso están disponibles en el repositorio público del autor (enlace proporcionado en la publicación original).
Qué observar a continuación
- Validadores de PHP impulsados por la comunidad – a medida que más desarrolladores adopten el enfoque de reimplementación, se esperan forks y extensiones que añadan fixtures de pruebas unitarias, soporte para otros frameworks o ajustes de rendimiento.
Conclusión
El mandato de facturación electrónica de Croacia para 2026 obliga a los desarrolladores de PHP a enfrentarse a una discrepancia entre un Schematron XSLT 2.0 moderno y el motor heredado XSLT 1.0 del lenguaje. Traducir las 62 reglas de negocio a PHP nativo, vigilar la lógica de variables ocultas y evitar los errores comunes de XML permite gestionar la facturación internamente, evita fallos relacionados con la red y prepara el software de contabilidad para un despliegue fluido y conforme a la normativa cuando llegue la fecha límite.