Fatura

Em resumo

O NextPDF Enterprise produz faturas híbridas estruturadas ZUGFeRD / Factur-X / Peppol-UBL e valida o XML da fatura em relação ao modelo de dados EN 16931 e a conjuntos de regras Schematron. Ele produz faturas estruturadas em conformidade com o modelo de dados definido na EN 16931; ele não é um validador de autoridade fiscal e não certifica nenhum documento.

Disponibilidade e licenciamento

Este recurso é entregue no NextPDF Enterprise (nextpdf/enterprise) e é ativado com um envelope de licença de nível Enterprise. Uma implantação sem essa titularidade não carrega as classes do recurso. Compare as edições e obtenha uma licença.

Instalação

composer require nextpdf/enterprise:^3

O motor Schematron usa a extensão PHP ext-xsl. Instale-a e habilite-a antes de executar a validação Schematron.

Visão conceitual

O módulo Invoice tem três superfícies independentes: incorporação de fatura estruturada, validação de XML EN 16931 e execução de regras Schematron.

Incorporação. O ZugferdEmbedder anexa um payload XML UN/CEFACT CII ZUGFeRD 2.4 / Factur-X 1.08 fornecido pelo chamador a um portador PDF/A, produzindo uma fatura híbrida. Dois formatos de portador são suportados: PDF/A-4f (ISO 19005-4:2020), o portador moderno preferido, e PDF/A-3b (ISO 19005-3:2012) para compatibilidade retroativa. O ZugferdXmpSchema injeta a declaração de esquema de extensão XMP do Factur-X de que o portador precisa. O PeppolEmbedder desempenha o mesmo papel para XML de fatura ou nota de crédito Peppol BIS Billing 3.0 UBL 2.1 fornecido pelo chamador, anexando-o com o relacionamento de arquivo associado e o tipo MIME corretos. O NextPDF não sintetiza o XML da fatura; o chamador fornece um XML válido e permanece o emissor da fatura.

Validação. O InvoiceXmlValidator verifica o XML da fatura em relação ao modelo de dados semântico EN 16931 e às expectativas do contêiner ZUGFeRD / Factur-X, incluindo o identificador de especificação BT-24 que a regra de negócio BR-1 da EN 16931 exige. Ele é executado em um de dois modos: COMPAT (o padrão; achados de cardinalidade limítrofes da EN 16931 são relatados como avisos para preservar a compatibilidade retroativa de fixtures existentes) e STRICT (a cardinalidade do BT-24 é um erro grave, espelhando a semântica de validadores externos). O modo é selecionável por chamada, por sobrescrita de ambiente ou por política de conformidade.

Schematron. O SchematronValidator executa conjuntos de regras Schematron pré-compilados (as regras .sch CEN EN 16931 compiladas para XSLT em tempo de build) sobre o XML da fatura usando o processador XSLT PHP em processo, e analisa o relatório SVRL convertendo-o em achados estruturados. O enum ZugferdProfile modela os perfis de conformidade — MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED e o XRechnung B2G CIUS alemão sobre a EN 16931.

O que este módulo afirma e o que não afirma

Este módulo produz e verifica dados de fatura estruturados. Ele não afirma que algum documento é uma fatura legalmente conforme, que ele é aprovado por autoridade fiscal ou que é garantido que será aceito por alguma autoridade.

• O validador verifica apenas o modelo semântico EN 16931 e o contêiner ZUGFeRD / Factur-X / UBL. Ele não é um validador de autoridade fiscal. Extensões nacionais e plataformas de clearance — por exemplo, o SDI italiano, o Chorus Pro francês, o transporte XRechnung alemão — estão fora do escopo no nível de transporte.
• Como a própria EN 16931-1 afirma, o modelo semântico central carrega as informações essenciais de que uma fatura eletrônica precisa para dar suporte à conformidade legal e fiscal; o emissor da fatura é responsável por atender às regras da legislação pertinente. Este não é um validador de autoridade fiscal.
• O suporte a um padrão não é o mesmo que a conformidade com ele. Consulte seus assessores fiscais e de conformidade para avaliar a suficiência regulatória na sua jurisdição.

Por que funciona assim

O módulo deliberadamente nunca sintetiza o XML da fatura. Incorporação, validação EN 16931 e execução Schematron são três superfícies independentes sobre o XML que o chamador fornece e possui. Isso mantém o NextPDF como um produtor e verificador, nunca o emissor, porque a responsabilidade legal não pode ser delegada a uma biblioteca. A validação usa COMPAT por padrão, então um achado de cardinalidade limítrofe é um aviso em vez de uma regressão. O STRICT é opcional quando você precisa da semântica de validadores externos. O resultado é uma separação limpa: o NextPDF relata o que observa, e o emissor decide se o documento atende à lei. Contexto de design: Faturas e faturamento eletrônico.

Superfície de API

Classe	Responsabilidade
ZugferdEmbedder	Anexa XML CII ZUGFeRD / Factur-X a um portador PDF/A-4f ou PDF/A-3b.
ZugferdXmpSchema	Injeta a declaração de esquema de extensão XMP do Factur-X.
ZugferdProfile	Enum de perfil de conformidade (MINIMUM … EXTENDED, XRECHNUNG).
PeppolEmbedder	Anexa XML UBL de fatura / nota de crédito Peppol BIS 3.0 a um portador PDF/A.
InvoiceXmlValidator	Verifica o XML em relação ao modelo de dados EN 16931; modo COMPAT ou STRICT.
InvoiceValidatorMode	Enum de modo de validação: COMPAT (padrão) ou STRICT.
SchematronValidator	Executa conjuntos de regras Schematron pré-compilados; analisa achados SVRL.
InvoiceValidationResult / SchematronResult	Resultados estruturados: perfil, achados, severidades.

Exemplo de código — Início rápido

use NextPDF\Enterprise\Invoice\ZugferdEmbedder;
use NextPDF\Enterprise\Invoice\ZugferdProfile;

$pdf = ZugferdEmbedder::basic($pdfAManager, $fileAttachment, $ciiXml)
    ->embed(ZugferdProfile::EN16931);

Exemplo de código — Produção

use NextPDF\Enterprise\Invoice\InvoiceXmlValidator;
use NextPDF\Enterprise\Invoice\InvoiceValidatorMode;

$result = $validator->validate($ciiXml, InvoiceValidatorMode::STRICT);

foreach ($result->findings as $finding) {
    $logger->warning('invoice.finding', [
        'rule'     => $finding->ruleId,
        'severity' => $finding->severity->value,
    ]);
}
// A clean result is one input to your decision, not a compliance verdict.
// The invoice issuer remains responsible for relevant legislation.

Casos extremos e pegadinhas

• Um PDF bem-formado que não carrega nenhum payload de fatura reconhecível resulta em um resultado “não é uma fatura” em vez de lançar uma exceção.
• COMPAT é o modo de validação padrão: um identificador de especificação BT-24 ausente é relatado como um aviso, de modo que pontos de chamada que dependem de uma flag booleana de validade não sofram regressão. Use STRICT para tornar o BT-24 um erro grave que corresponda à semântica externa do KoSIT / Mustang.
• O chamador fornece o XML da fatura. O NextPDF não o gera nem o corrige; uma lista de achados vazia não torna conforme um payload não conforme.
• O motor Schematron requer ext-xsl. Os conjuntos de regras são compilados em tempo de build; o runtime executa apenas o XSLT pré-compilado.

Desempenho

O custo de validação escala com o tamanho do XML incorporado e o número de regras Schematron. O custo de incorporação escala com o tamanho do portador e é dominado pela serialização PDF/A. O orçamento de desempenho da página reflete a renderização da documentação, não o throughput de faturas.

Notas de segurança

Toda a análise de XML passa pelo guarda de XML reforçado: a resolução de entidades externas é desabilitada (seguro contra XXE), o DOCTYPE é rejeitado e a descompressão é limitada. O processador XSLT é executado com o carregamento de recursos de rede e de sistema de arquivos desabilitado e nunca registra funções PHP, de modo que document(), xsl:include, xsl:import e result-document não conseguem alcançar a rede ou o disco. Trate o XML de fatura de origens não confiáveis como hostil.

Residência de dados e mitigações de PII

O XML da fatura pode conter dados pessoais, comerciais e financeiros. O processamento é em processo e local; o módulo não faz nenhuma chamada de rede de saída durante a incorporação ou a validação. Aplique seus próprios controles de retenção e minimização ao XML extraído e aos achados.

Telemetria segura e limpeza de logs

Os achados e os logs de validação podem incluir identificadores de regra e valores de tag. Eles não incluem payloads completos de fatura. Limpe ou redija os valores dos campos antes de encaminhar logs para sinks compartilhados, caso esses valores sejam sensíveis.

Conformidade

Comportamento	Referência	Status
Modelo semântico central de fatura	EN 16931-1:2026 §4	Construído em conformidade; o emissor permanece responsável pela legislação pertinente
Identificador de especificação (BT-24)	EN 16931-1:2026 BR-1	Verificado (aviso em COMPAT, erro em STRICT)
Ligação de sintaxe UN/CEFACT CII	CEN/TS 16931-3-3:2020	Incorporação suportada
Ligação de sintaxe UBL 2.1	CEN/TS 16931-3-2:2020	Incorporação suportada
Arquivo associado PDF/A-3	ISO 19005-3:2012 §6.7.8	Portador suportado
Arquivo incorporado PDF/A-4f	ISO 19005-4:2020 Annex A	Portador suportado

Esta tabela registra as especificações em conformidade com as quais o NextPDF Enterprise é construído e o que ele verifica. Ela não é uma declaração de certificação, de aprovação por autoridade fiscal ou de suficiência regulatória. O emissor da fatura é responsável por atender às regras da legislação pertinente; este não é um validador de autoridade fiscal.

Comportamento em modo FIPS

Este módulo não realiza nenhuma assinatura criptográfica. A assinatura de uma fatura híbrida e a custódia de chaves em modo FIPS estão fora do escopo aqui; consulte o módulo Signature.

Modelo de ameaças

O XML de fatura não confiável é a entrada principal. Mitigações: análise segura contra XXE, rejeição de DOCTYPE, descompressão limitada, um processador XSLT com o carregamento de recursos de rede e de arquivo desabilitado e nenhuma síntese de afirmações — o chamador fornece e é dono do conteúdo da fatura.

Contrato de comportamento

• O ZugferdEmbedder / PeppolEmbedder anexa o XML de fatura fornecido pelo chamador a um portador PDF/A-4f ou PDF/A-3b; o NextPDF nunca sintetiza o XML da fatura.
• O InvoiceXmlValidator é executado em COMPAT (padrão; a cardinalidade limítrofe da EN 16931 é um aviso) ou STRICT (a cardinalidade do BT-24 é um erro grave).
• O SchematronValidator executa conjuntos de regras pré-compilados por meio do processador XSLT em processo e analisa os achados SVRL; uma lista de achados vazia não torna conforme um payload não conforme.
• Toda a análise de XML é segura contra XXE: resolução de entidades externas desabilitada, DOCTYPE rejeitado, descompressão limitada.

Limite de publicação

Esta página documenta apenas o comportamento observável externamente e a superfície pública de API suportada. Caminhos de namespace internos, classes auxiliares, tabelas de mecanismos, nomes de arquivos de runbook e prefixos de tickets estão fora do escopo.

Fallback no Core

O NextPDF Core não gera nem valida faturas estruturadas. Uma implantação somente Core pode produzir um PDF, mas não tem incorporação ZUGFeRD / Factur-X / Peppol, nem validador EN 16931, nem motor Schematron.

Fallback no Pro

Em uma implantação somente Pro, a superfície suportada é a detecção e validação de fatura eletrônica de nível Pro de payloads Factur-X / ZUGFeRD. O Pro não gera portadores híbridos ZUGFeRD / Factur-X ou Peppol-UBL, não acrescenta o perfil XRechnung CIUS e não executa o motor Schematron em processo; uma configuração que solicite geração, o perfil XRechnung CIUS ou Schematron em uma implantação somente Pro não tem nenhum componente Enterprise para satisfazê-la. Consulte Pro Compliance para conhecer a superfície de detecção e validação do Pro.

Nota sobre o limite do Enterprise

O detalhe interno de mecanismos permanece na documentação interna do repositório de origem e está fora do escopo deste manual.

Limite de implantação

O motor Schematron requer a extensão PHP ext-xsl; provisioná-la e habilitá-la é responsabilidade do operador. O processamento é em processo e local; o módulo não faz nenhuma chamada de rede de saída durante a incorporação ou a validação. O transporte nacional de fatura eletrônica, as plataformas de clearance e os sistemas de arquivamento são externos a este módulo e são responsabilidade do operador.

Limite legal e de conformidade

O NextPDF produz faturas estruturadas em conformidade com o modelo de dados definido na EN 16931 e relata achados de regras. Ele não produz “faturas legalmente conformes”, não fornece saída “aprovada por autoridade fiscal” e não garante que alguma fatura será aceita por uma autoridade fiscal, um tribunal ou um registro. O emissor da fatura é responsável por atender às regras da legislação pertinente; este não é um validador de autoridade fiscal. As plataformas nacionais de fatura eletrônica, os modelos de clearance, os mandatos de arquivamento e os requisitos de assinatura digital variam por jurisdição e são responsabilidade do emissor. Consulte seus assessores fiscais e jurídicos.

Veja também

• Referência de Invoice — referência em nível de API para os embedders, validadores e o motor Schematron.
• Pro Compliance — detecção e validação de fatura eletrônica de nível Pro.
• Document E-Filing — otimização de entrega a tribunais/registros.
• Visão geral do Enterprise
• Matriz de recursos Core vs Pro vs Enterprise