Formatos de factura y conversión: formatos, perfiles y transformación

Resumen de los formatos compatibles

faktoora es compatible con una amplia gama de formatos de factura electrónica. La elección del formato adecuado depende del tipo de destinatario de la factura y de los requisitos legales o contractuales.

ZUGFeRD: perfiles y versiones

faktoora crea facturas ZUGFeRD con el perfil Extended, que ofrece la máxima funcionalidad. Existen dos versiones:

• ZUGFeRD 1.0 (zf:1:extended): la versión original basada en el estándar CII. Sigue siendo compatible.
• ZUGFeRD 2.1 (zf:2:extended): la versión actual conforme a EN 16931 y la recomendada para facturas nuevas.

El perfil Extended es el perfil más completo y cumple la norma EN 16931. El mensaje "Solo puede descargar como PDF y como XRechnung" significa que el perfil seleccionado solo ofrece estos dos formatos para descargar; esto está previsto para determinadas configuraciones y tipos de factura.

XRechnung y CII/UBL

La XRechnung es la factura electrónica estándar alemana para la administración pública. faktoora la genera automáticamente en la versión vigente en cada momento. Qué versión es obligatoria actualmente lo determina la Coordinadora de Estándares TI (KoSIT); la relación vinculante se encuentra en xeinkauf.de.

Técnicamente, XRechnung se basa en CII (Cross Industry Invoice), no en UBL (Universal Business Language). CII es el formato XML preferido por Alemania y Austria, mientras que UBL predomina sobre todo en la red Peppol (norte de Europa, Países Bajos).

Los dos esquemas se diferencian en su estructura:

• CII: estructura estricta y jerárquica; la utilizan Alemania, Austria y la especificación EN 16931 para XRechnung.
• UBL: estructura más modular y abierta; estándar en la red Peppol.

ZUGFeRD utiliza siempre CII, por lo que al crear una factura ZUGFeRD la opción de esquema se establece en CII (no es seleccionable).

Peppol (UBL) para facturas B2B internacionales

Peppol (Pan-European Public Procurement Online) es una red de ámbito europeo para facturas estructuradas. faktoora crea facturas Peppol como facturas EN 16931 basadas en UBL y, con el envío por Peppol activado, puede enviarlas automáticamente a través de la red Peppol. Es ideal para facturas B2B a empresas europeas que disponen de un punto de acceso Peppol.

PDF y la conversión de formatos

De PDF a formato electrónico: qué es posible y qué no

Las facturas en PDF no se pueden convertir automáticamente a un formato electrónico (XRechnung, ZUGFeRD, etc.). Esto se debe a que:

1. Falta información estructural: un PDF solo contiene una representación visual, no datos estructurados.
2. El OCR no es fiable: faktoora utiliza OCR para extraer textos de facturas escaneadas (facturas recibidas), pero el OCR no puede garantizar una detección de campos 100 % fiable. Por eso el reconocimiento es una ayuda, no una automatización completa.
3. Pérdida de datos: la información compleja, como categorías fiscales, descuentos a nivel de línea o condiciones de pago, no se puede reconstruir automáticamente a partir de un PDF.

Excepción: si el PDF tiene formato XRechnung o ZUGFeRD (es decir, un PDF/A-3 con XML incrustado), faktoora puede extraer el XML y convertirlo a otros formatos.

De Excel/CSV a formato electrónico

faktoora no ofrece una importación automatizada directa de Excel o CSV para crear facturas electrónicas a través de la interfaz web. La API ofrece posibilidades para transmitir datos estructurados, pero es necesario estructurar los datos manualmente o escribir un script de integración.

Alternativa: puede importar datos de clientes y productos mediante CSV (consulte Importar contactos, Importar productos) y después crear las facturas manualmente o a través de la API.

De Word a formato electrónico

Un archivo de Word (DOCX) no se puede convertir automáticamente a XRechnung ni a otro formato de factura electrónica. Está sujeto a las mismas limitaciones que el PDF: el formato solo contiene información visual y formal, no los datos estructurados que necesita un formato de factura electrónica.

Procedimiento: cree la factura directamente en faktoora o introduzca manualmente los datos relevantes (cliente, líneas, impuestos).

Facturas extranjeras y números fiscales

Números fiscales e IBAN extranjeros

faktoora admite facturas que no emite una empresa alemana. Puede introducir en los ajustes de su perfil un número fiscal extranjero (p. ej., UID austriaco, NIF español) y un IBAN extranjero, pero esto debe configurarse mediante una solicitud de contacto o con acceso de administrador, ya que la interfaz web está preconfigurada para datos alemanes.

Formatos para el extranjero

• Internacional: Peppol (UBL) es el estándar para facturas electrónicas B2B en toda Europa.
• España: formato Verifactu para organismos públicos y B2B.
• Francia: Factur-X para empresas; France-PA para la administración pública (a través de una Plateforme Agréée).
• Italia: FatturaPA para organismos públicos y envío B2B a través de la red SdI.
• Polonia: KSeF (FA(3)) para organismos públicos y B2B.

Limitaciones de las facturas electrónicas

Importes negativos a nivel de línea

En los formatos de factura electrónica (XRechnung, ZUGFeRD, Peppol) no se pueden introducir importes negativos a nivel de línea. Es un requisito de la norma EN 16931.

Motivo: EN 16931 prevé que las correcciones se realicen mediante notas de crédito independientes (código de tipo de factura 381) o facturas rectificativas (código 384), no mediante líneas negativas en una factura normal.

Solución: en su lugar, cree una nota de crédito (tipo de factura 381) o una factura rectificativa (384) como factura independiente.

Fecha de entrega en ZUGFeRD 2.x

La fecha de entrega (BT-72 en EN 16931) se registra en los datos XML en ZUGFeRD 2.x, pero por defecto no es visible en la representación PDF. Puede activarla en la interfaz de la factura para que se muestre en el diseño del PDF.

Fecha de prestación sin fecha propia por línea

Para líneas de factura individuales (p. ej., servicios sin fecha de entrega propia) se puede establecer adicionalmente una fecha de entrega a nivel de producto; esto es opcional. Si no define una fecha de prestación ni un periodo de prestación propios para la factura, se aplica automáticamente: la fecha de prestación coincide con la fecha de factura. Este valor predeterminado también se indica así en la factura y no requiere ninguna introducción adicional.

Validación y gestión de errores

Errores de validación al exportar o descargar

Si la exportación de una factura como PDF o CSV falla con un error de validación, las causas más habituales son:

• Incumplimiento de un campo BT: un campo obligatorio según EN 16931 no está definido o tiene un formato no válido.
• Incoherencia fiscal: tipos impositivos negativos, categorías fiscales no compatibles o combinaciones de categorías no válidas.
• Formato de campo: una fecha no tiene el formato esperado, un número de teléfono contiene caracteres no válidos, etc.

Procedimiento: revise detenidamente el mensaje de error; normalmente indica el campo BT afectado o la regla de validación. Ajuste los datos y vuelva a intentarlo.

Errores al generar el PDF en ZUGFeRD

Si una factura ZUGFeRD descargada como PDF falla o no se muestra al abrirla, las causas pueden ser:

• Conformidad PDF/A-3: el PDF no es conforme a PDF/A-3, lo que provoca problemas en algunos lectores. Intente abrirlo con Acrobat Reader u otro lector de PDF.
• Problema con el XML incrustado: el XML incrustado está dañado. Es poco frecuente y la validación lo detecta.

Solución: utilice la función de validación (validate: true al crear la factura por API) para detectar errores antes de la descarga.

Persona de contacto en facturas ZUGFeRD

Si define una persona de contacto en el XML (p. ej., a través de la API), esta no se muestra automáticamente en el diseño del PDF. Normalmente, el PDF muestra un contacto estándar o la propia empresa. Aun así, la persona de contacto está presente en los datos estructurados (XML) y la tienen en cuenta los sistemas que leen el XML.

Generación automática del PDF en integraciones por API

Si una factura se crea mediante una integración de API externa (p. ej., mediante un proceso en segundo plano o un proceso por lotes), es posible que la representación PDF se genere con un diseño estándar en lugar de con su plantilla de factura personalizada. Esto ocurre cuando:

• La llamada a la API no transmite ningún ID de plantilla.
• El sistema recurre a una plantilla alternativa (p. ej., en facturas generadas por el sistema).

Solución: asegúrese de que la carga útil (payload) de su API contiene el ID de plantilla correcto o las referencias de configuración adecuadas.

Campo BT-18: referencia de documento

El campo BT-18 (referencia a un documento comercial) se gestiona en faktoora mediante el campo buyerReference o contextos similares. En la API puede utilizar invoiceReferencedDocument.IssuerAssignedID para establecer una referencia a otra factura (p. ej., en correcciones). La asignación exacta del campo BT-18 depende del tipo de factura y del contexto.

Funciones de prueba

Para probar facturas ZUGFeRD, puede:

1. Crear una factura en la interfaz web, guardarla como borrador y mostrársela después a un cliente.
2. Crear la factura con los datos del cliente en la cuenta de pruebas del cliente (con su clave de API).
3. Crear una factura de prueba a través de la API con draftOnly: true.

Todas las opciones permiten mostrar un ejemplo funcional sin enviarlo en producción.

Combinar ZUGFeRD y XRechnung

Una factura creada como ZUGFeRD 2.1 (Extended) no se puede descargar automáticamente como XRechnung. Esto se debe a que ZUGFeRD 2.1 se construye con el esquema CII (PDF + XML CII), mientras que la XRechnung, aunque también utiliza CII, tiene reglas de validación propias y un formato de salida diferente.

Procedimiento correcto:

• Para clientes privados: crear ZUGFeRD 2.1 (Extended).
• Para la administración pública: seleccionar XRechnung explícitamente.
• ZUGFeRD con el perfil zf:2:xrechnung ofrece un perfil híbrido entre ZUGFeRD y XRechnung, pero no permite elegir libremente a posteriori.

Si desea crear una XRechnung auténtica, seleccione Formato: xrechnung al crearla. Si desea un híbrido ZUGFeRD compatible con XRechnung, utilice zf:2:xrechnung. No es posible convertir entre ellos a posteriori: el formato se fija en el momento de la creación.