Facturas y facturación electrónica

Spec Spec: EN 16931-1:2026, BT-24 EN 16931-1:2026 BT-24 Spec Spec: Factur-X 1.08 Factur-X 1.08 Spec Spec: ISO 32000-2:2020, §14.13 ISO 32000-2:2020 §14.13 Evidence ⊕ Mixed evidence Evidence: Mixed evidence

De un vistazo

Una factura moderna reúne dos documentos en un solo archivo: una página legible por una persona y una carga útil XML legible por máquina que analiza un sistema tributario. Esta página recorre el escenario de la factura híbrida desde la obligación hasta la salida: qué exigen realmente ZUGFeRD y Factur-X, cómo NextPDF adjunta y comprueba la carga útil estructurada, y la frontera en la que la conformidad deja de ser tarea del motor y pasa a ser responsabilidad del emisor.

Por qué importa

Varias jurisdicciones ya exigen facturas estructuradas para la facturación entre empresas o entre empresas y administraciones públicas. La trampa es que una factura híbrida puede verse perfecta en pantalla y, aun así, ser rechazada. El rechazo se produce por el XML incrustado, no por los píxeles. Si a la carga útil estructurada le falta el identificador de especificación, declara el perfil equivocado o se adjunta con la relación incorrecta, la plataforma receptora la rechaza. Desde el lado del emisor, el fallo suele ser silencioso y llega días después, con un pago retenido como consecuencia.

Hacerlo bien una sola vez, en la capa que produce el archivo, resulta mucho más barato que descubrir el problema una factura ya aprobada tras otra.

La versión breve

• Una factura híbrida conforme es un portador PDF/A con una carga útil XML conforme incrustada como archivo asociado. Los metadatos del portador deben declarar el perfil.
• El campo que con más frecuencia decide la aceptación es BT-24, el identificador de especificación. La regla de negocio BR-1 de EN 16931 exige que toda factura lo lleve. El valor es una URN que nombra el perfil exacto; por ejemplo, la del perfil EN 16931 (COMFORT): urn:cen.eu:en16931:2017.
• La tarea de NextPDF es la incrustación y la validación estructural del XML aportado por quien llama. No redacta el contenido de la factura y no es un validador de la autoridad tributaria.
• El emisor sigue siendo responsable de la corrección legal y fiscal. Un resultado de validación sin hallazgos es una entrada para esa decisión, no un certificado.

Cómo lo aborda NextPDF

NextPDF trata la factura estructurada como un contrato entre niveles, no como una funcionalidad única. El motor del núcleo define las interfaces —un incrustador, un descriptor de perfil, un validador— y el nivel Premium aporta las implementaciones. Esa separación es deliberada. La superficie pública queda congelada en el núcleo, de modo que los puntos de llamada y las pruebas se dirigen al perfil y al resultado del mismo modo, independientemente del nivel que haya detrás.

El flujo tiene cuatro etapas, y el orden importa porque cada etapa depende de la anterior.

1. Author the invoice XML You (or your ERP) produce a UN/CEFACT CII or Peppol UBL payload. NextPDF never synthesizes invoice content.
2. Produce the PDF/A carrier A PDF/A-3 or PDF/A-4f document is the human-readable face and the conformant container the standard requires.
3. Embed the payload The embedder attaches the XML as an associated file with the correct AFRelationship, and injects the Factur-X XMP profile declaration.
4. Validate, then ship A structural pass checks the root, the required sections, and BT-24 against the declared profile before the file leaves your system.

El escenario de la factura electrónica híbrida de principio a fin: usted redacta el XML y asume su corrección legal; NextPDF lo transporta y lo comprueba estructuralmente; la plataforma receptora toma la decisión final de aceptación.

El contrato del incrustador opera de bytes a bytes: entran un portador PDF/A y una carga útil XML, y salen los bytes del PDF híbrido. Antes de adjuntar nada, el XML se analiza a través de una protección reforzada que rechaza un DOCTYPE, limita el tamaño de entrada y rechaza los caracteres de control prohibidos por XML 1.0. Esto elimina desde el diseño los ataques de Entidad Externa XML y de Billion Laughs, porque el XML de las facturas suele llegar desde fuera de la frontera de confianza.

El descriptor de perfil responde a las cuatro preguntas que plantea un sistema posterior: la URN canónica del perfil, el valor de BT-24 que se debe afirmar, un nombre estable para los registros y un discriminante neutral entre niveles para que las pruebas de paridad puedan agrupar resultados. El descriptor explicita sus carencias. El perfil MINIMUM de ZUGFeRD no lleva ningún identificador de especificación BT-24, y el descriptor devuelve null para él en lugar de fabricar uno. Por esa misma razón, MINIMUM y BASIC WL tampoco son conformes con EN 16931. El motor codifica la cardinalidad real en lugar de ocultarla.

Human-factors note: Human-factors note

El validador tiene dos modos, y el predeterminado es el conservador. En el modo predeterminado, un BT-24 ausente se notifica como advertencia para que un flujo existente que decide a partir de un booleano no cambie de comportamiento en silencio. El modo estricto eleva el mismo hallazgo a un error grave, para alinearse con la semántica de los validadores externos. El modo se elige deliberadamente en cada llamada. El motor no escoge la postura de riesgo por quien llama, e indica qué postura está activa en lugar de hacer que tenga que deducirse.

Qué dice la evidencia

El comportamiento anterior se apoya en tres lugares, y cada uno aporta un tipo de evidencia distinto.

El estándar establece la obligación. Spec Spec: EN 16931-1:2026, BR-1 EN 16931-1:2026 BR-1 hace que el identificador de especificación sea obligatorio en toda factura. El apéndice técnico de Factur-X define los valores de la URN por perfil, incluida la del perfil EN 16931 urn:cen.eu:en16931:2017. El portador en sí es un asunto de PDF: Spec Spec: ISO 32000-2:2020, §9 ISO 32000-2:2020 §9 señala que la representación más predecible y fiable se produce cuando todas las fuentes están incrustadas —algo directamente relevante, porque una factura que debe poder leerse dentro de diez años no puede depender del entorno de fuentes del lector.

El código mantiene el contrato. Evidence { } Code-backed Evidence: Code-backed Las interfaces del núcleo EmbedderInterface, ProfileInterface y ValidatorInterface son interfaces reales y neutrales entre niveles. ProfileType::isEn16931Conformant() codifica la exclusión de MINIMUM / BASIC WL en el sistema de tipos. ValidationResult es un DTO inmutable cuyo isValid es la conjunción de «ningún hallazgo de error» y «ninguna violación fatal de reglas».

El comportamiento está documentado como capacidad del nivel Premium: Evidence § Standard-backed Evidence: Standard-backed el incrustador adjunta el XML CII ZUGFeRD 2.4 / Factur-X 1.08 o el UBL de Peppol que aporta quien llama a un portador PDF/A-4f o PDF/A-3b con la relación de archivo asociado correcta. El validador comprueba el modelo semántico de EN 16931 y el identificador BT-24. La etapa de Schematron ejecuta los conjuntos de reglas del CEN compilados a XSLT. Nada de ello genera ni corrige el contenido de la factura.

Ejemplo práctico

El siguiente fragmento ilustra el punto de integración; no es una integración para copiar y pegar. La construcción del portador y el incrustador provienen del nivel Premium, y el XML lo aporta quien llama.

<?php

declare(strict_types=1);

use NextPDF\Contracts\EInvoice\ProfileType;
use NextPDF\Contracts\EInvoice\ValidatorContext;
use NextPDF\Contracts\EInvoice\ValidatorInterface;
use NextPDF\Contracts\EInvoice\EmbedderInterface;
use NextPDF\Contracts\EInvoice\EmbedderOptions;
use Psr\Log\LoggerInterface;

/**
 * Validate first, embed second, never ship an invalid payload.
 *
 * @param non-empty-string $carrierPdf  PDF/A-3 or PDF/A-4f carrier bytes
 * @param non-empty-string $ciiXml      Caller-authored UN/CEFACT CII XML
 *
 * @return non-empty-string Hybrid invoice bytes, ready to deliver
 */
function buildHybridInvoice(
    ValidatorInterface $validator,
    EmbedderInterface $embedder,
    LoggerInterface $logger,
    string $carrierPdf,
    string $ciiXml,
): string {
    // STRICT mode: a missing BT-24 is a hard error, not a warning.
    $context = new ValidatorContext(
        profile: ProfileType::EN16931,
        strictMode: true,
    );

    $result = $validator->validate($ciiXml, $context);

    if (!$result->isValid) {
        foreach ($result->getErrors() as $finding) {
            $logger->error('invoice.structural_finding', [
                'message' => $finding->message,
            ]);
        }

        // A failed structural check is your signal to stop, not to ship.
        throw new \RuntimeException('Invoice XML failed structural validation.');
    }

    $options = new EmbedderOptions(profile: ProfileType::EN16931);

    return $embedder->embed($carrierPdf, $ciiXml, $options);
}

El orden es lo importante. La validación es barata en comparación con una factura rechazada y un pago retrasado, así que se ejecuta incluso antes de adjuntar la carga útil.

Concepto erróneo común

El concepto erróneo más caro es «NextPDF hace que mis facturas sean conformes.» No lo hace, y lo dice con claridad. El motor incrusta y comprueba estructuralmente el XML redactado por quien llama. Un resultado estructural satisfactorio significa que la carga útil tiene la forma que espera EN 16931 y declara el perfil solicitado. No significa que la factura sea legalmente suficiente, esté aprobada por la autoridad tributaria ni garantiza su aceptación por ninguna plataforma de clearance. Las extensiones nacionales y los transportes de clearance quedan fuera del alcance en el nivel del motor. Como la propia EN 16931-1 lo plantea, el modelo central contiene la información necesaria para sustentar la conformidad. El emisor es responsable de cumplir la legislación aplicable.

Una segunda trampa, más silenciosa: dar soporte a un estándar no equivale a ser conforme a él. La conformidad es una propiedad del archivo final más un validador, no una propiedad de la biblioteca que lo produjo.

Límites y fronteras

• NextPDF no redacta ni corrige el contenido de la factura. Quien llama aporta un XML válido y sigue siendo el emisor de la factura. Una lista de hallazgos vacía no convierte en conforme una carga útil no conforme.
• La incrustación estructurada y la validación Schematron son capacidades del nivel Premium. El núcleo define los contratos; las implementaciones requieren el paquete comercial. Consulte la frontera más abajo.
• El validador comprueba únicamente el modelo semántico de EN 16931 y el contenedor ZUGFeRD / Factur-X / UBL. No es un validador de la autoridad tributaria. El transporte por SDI, Chorus Pro y XRechnung queda fuera del alcance en la capa de transporte.
• Los perfiles MINIMUM y BASIC WL no son conformes con EN 16931 y no llevan identificador de especificación BT-24 —por diseño, reflejando la cardinalidad del estándar, no una limitación del motor.
• El motor de Schematron necesita ext-xsl. Los conjuntos de reglas se compilan en tiempo de compilación. El tiempo de ejecución ejecuta solo el XSLT precompilado, con la carga de recursos de red y de sistema de archivos deshabilitada.
• Esta página describe el comportamiento a nivel de capacidad. No afirma la aceptación por ninguna autoridad ni plataforma concreta.

Structured e-invoice embedding and validation — edition availability

Edition	Availability
Core	○ El núcleo define los contratos entre niveles (EmbedderInterface, ProfileInterface, ValidatorInterface) pero no incluye ninguna implementación de factura estructurada. Un portador PDF simple sin carga útil estructurada es el resultado del núcleo por sí solo.
Pro	○ La incrustación CII de Factur-X 1.08 en un portador PDF/A y los descriptores del perfil EN 16931 están disponibles.
Enterprise	○ Añade la incrustación UBL de Peppol BIS 3.0, el CIUS B2G de XRechnung, la validación XML COMPAT/STRICT y el motor de reglas Schematron dentro del proceso.

Documentos relacionados

• Archivado y PDF/A — por qué el portador de la factura es un archivo PDF/A y qué garantiza eso para la legibilidad a largo plazo.
• La guía de decisión de integración — qué paquete del ecosistema se ajusta a un flujo de facturación (generación en cola, puente de framework o Connect).
• Operar NextPDF en producción — cómo observar los hallazgos y los fallos de validación una vez que las facturas fluyen a gran volumen.

Glosario

• Factura híbrida — un único archivo PDF que es a la vez una página legible por una persona y una carga útil XML de factura incrustada, legible por máquina.
• ZUGFeRD / Factur-X — las denominaciones alemana y francesa del mismo enfoque de factura híbrida: una carga útil XML Cross Industry Invoice (CII) de UN/CEFACT incrustada en un portador PDF/A.
• EN 16931 — el estándar europeo que define el modelo semántico de datos de los elementos centrales de una factura electrónica.
• BT-24 (Identificador de especificación) — el término de negocio de EN 16931 cuyo valor es una URN que nombra el perfil exacto al que se ajusta la factura. Exigido por la regla de negocio BR-1.
• Perfil — también llamado nivel de conformidad (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED, XRECHNUNG). Determina qué términos de negocio debe contener una factura.
• Archivo asociado — un archivo adjunto dentro de un PDF con una relación declarada (AFRelationship) que describe cómo se relaciona con el documento visible; el mecanismo que transporta el XML de la factura.
• Schematron — un lenguaje de reglas usado para expresar las reglas de negocio de EN 16931. NextPDF ejecuta los conjuntos de reglas del CEN compilados a XSLT.