A regra de faturamento eletrônico da Croácia para 2026 força desenvolvedores PHP a reinventar a validação – o arquivo Schematron da autoridade fiscal depende de XSLT 2.0, mas o motor XSLT dominante no PHP só suporta XSLT 1.0. O resultado: a maioria dos aplicativos de contabilidade não consegue executar as 62 verificações obrigatórias de regras de negócio sem uma solução alternativa, e uma fatura rejeitada pode interromper o fluxo de caixa B2B.
Por que o obstáculo técnico é importante
A partir de 1º de janeiro de 2026, todas as transações B2B na Croácia devem ser trocadas como um e-Račun que cumpra 62 regras de validação específicas. A Administração Fiscal publica essas regras como um arquivo Schematron – essencialmente uma folha de estilo XSLT 2.0 que sinaliza violações. A biblioteca integrada libxslt do PHP, que alimenta o popular xsltproc e a maioria dos pacotes Composer, implementa apenas XSLT 1.0. Sem o suporte ao XSLT 2.0, o Schematron não pode ser aplicado, o que significa que um sistema de faturamento baseado em PHP produzirá faturas que o portal fiscal rejeitará ou terá que recorrer a outra linguagem ou serviço.
Três caminhos que os desenvolvedores podem seguir
| Opção | O que envolve | Desvantagens práticas |
|---|---|---|
| Extensão SaxonC PECL | Instalar o processador Saxon-C como uma extensão nativa do PHP e, em seguida, invocar o Schematron diretamente. | A extensão não faz parte do fluxo de trabalho típico do Composer; compilar e implantar binários nativos em diferentes servidores adiciona complexidade. |
| Serviço de validação externo | Enviar o XML para um web service que executa o Schematron em seu nome. | Cada fatura agora depende da latência da rede e da disponibilidade do serviço; uma interrupção temporária pode bloquear totalmente o faturamento. |
| Reimplementar as regras em PHP | Traduzir as 62 asserções do Schematron para código PHP nativo. | Requer esforço inicial, mas, uma vez codificado, o validador roda localmente, integra-se perfeitamente a qualquer stack PHP e elimina dependências externas. |
A lógica oculta que derruba implementações simples
Uma tradução ingênua do Schematron ainda pode perder semânticas sutis. Considere a regra HR-BR-4: “Uma data de vencimento deve existir se o valor a pagar for maior que zero.” O Schematron define uma variável que multiplica o valor da fatura por –1 para notas de crédito. No XML bruto, uma nota de crédito mostra um valor positivo, mas a variável o torna negativo, de modo que a condição “maior que zero” é falsa. Se o validador ler apenas o texto da asserção, ele rejeitará todas as notas de crédito.
A lição é clara: leia as definições de variáveis no Schematron antes de codificar a condição PHP correspondente. O mesmo padrão aparece em várias outras regras onde manipulações aritméticas ou de strings se escondem atrás de uma variável $.
Gatilhos comuns de rejeição
Mesmo com regras codificadas corretamente, os desenvolvedores costumam ignorar elementos da fatura que o sistema fiscal trata como erros fatais:
- Detalhes do operador ausentes – cada fatura deve conter o nome completo do operador e o OIB (número de identificação pessoal croata). Deixar qualquer um dos campos vazio aciona uma rejeição imediata.
- Tags XML vazias – tags como
<cbc:Note></cbc:Note>fazem o validador travar. Remover elementos vazios ou preenchê-los com uma string de placeholder resolve o problema. - Códigos KPD incorretos – o código Klasifikacija proizvoda i usluga (KPD) deve ter pelo menos seis dígitos. Códigos curtos são sinalizados como malformados.
- Datas inválidas – qualquer fatura com data anterior a 1º de janeiro de 2026 falha na regra de data obrigatória, independentemente de outras correções.
Armadilhas de teste
A Administração Fiscal publica arquivos de exemplo de e-Račun para desenvolvedores. Esses exemplos ainda contêm datas de 2025 e OIBs que não passam no conjunto de regras de 2026. Usá-los como única fonte de verdade gera uma falsa sensação de conformidade. Trate os exemplos oficiais como um teste de sanidade do parser e, em seguida, execute sua própria suíte de aplicação de regras contra dados realistas gerados por sua aplicação.
A solução apenas em PHP que já está disponível
Um desenvolvedor seguiu o caminho da reimplementação até o fim, empacotando todas as 62 regras de validação como uma biblioteca instalável via Composer para projetos Laravel. A biblioteca lida com a aritmética, o escopo de variáveis e as verificações de casos extremos que o Schematron esconde, permitindo que as faturas sejam validadas inteiramente dentro do tempo de execução do PHP. Ao eliminar o XSLT 2.0 e as chamadas externas, o pacote oferece um caminho determinístico e de baixa latência para a conformidade.
O código-fonte e o guia de uso estão disponíveis no repositório público do autor (link fornecido no post original).
O que observar a seguir
- Validadores PHP impulsionados pela comunidade – à medida que mais desenvolvedores adotam a abordagem de reimplementação, espere por forks e extensões que adicionem fixtures de testes unitários, suporte para outros frameworks ou ajustes de desempenho.
Conclusão
O mandato de faturamento eletrônico da Croácia para 2026 força os desenvolvedores PHP a confrontar uma incompatibilidade entre um Schematron XSLT 2.0 moderno e o motor XSLT 1.0 legado da linguagem. Traduzir as 62 regras de negócio para PHP nativo, monitorar a lógica de variáveis ocultas e evitar armadilhas comuns de XML mantém o faturamento internamente, evita falhas relacionadas à rede e posiciona o software de contabilidade para uma implementação suave e em conformidade quando o prazo chegar.