fiskaly.

10 min tiempo de lectura

Factura electrónica vs. PDF vs. papel: ¿qué cuenta de verdad como «electrónica»?

Aclaramos un error habitual: por qué las facturas en PDF y en papel no cumplen la mayoría de obligaciones de facturación electrónica aunque parezcan digitales.

woman working on an electronic invoice on a laptop

TL;DR

  • Una factura en papel, una factura en PDF y una factura escaneada son funcionalmente lo mismo según la normativa de facturación electrónica de la UE: ninguna es un dato estructurado, así que ninguna cuenta como factura electrónica.
  • Solo una factura emitida, transmitida y recibida en un formato estructurado, como UBL o CII XML, según define la Directiva 2014/55/UE, cuenta como electrónica a efectos de las obligaciones.
  • Un PDF con un archivo XML incrustado, como ZUGFeRD o Factur-X, puede contar como factura electrónica real, pero solo si esos datos incrustados usan un perfil que incluya todos los datos estructurados de la norma EN 16931.
  • Los perfiles de datos reducidos de ZUGFeRD/Factur-X, como MINIMUM y BASIC WL, no cumplen el requisito de facturación electrónica B2B de Alemania a partir de enero de 2026, aunque el archivo en sí sea técnicamente electrónico.
  • Enviar una factura por correo electrónico, subirla a un portal o mandarla como HTML no cambia su formato subyacente; el canal de envío no puede convertir una factura no estructurada en una estructurada.

¿Qué distingue realmente el papel, el PDF y una factura electrónica real?

La diferencia entre una factura en papel, una factura en PDF y una factura electrónica real se reduce a una sola propiedad: si los datos están estructurados para que los lea una máquina, no cómo viaja el archivo.

Una factura en papel lleva sus datos incrustados en un diseño impreso pensado para los ojos de una persona.

Una factura en PDF hace lo mismo en formato digital: los importes, las fechas y las líneas de detalle están dentro de un diseño visual, y un ordenador que recibe ese PDF no tiene forma fiable de extraerlos sin OCR o introducción manual.

Una factura electrónica real elimina el diseño como portador del significado. Los datos viven en campos XML etiquetados, en un esquema que un sistema receptor puede procesar directamente, y cualquier versión legible por humanos es una representación generada a partir de esos datos, no su origen.

Por eso la guía de fiskaly sobre qué es una factura electrónica toma la definición legal (emitida, transmitida y recibida en formato estructurado) como prueba, en lugar de preguntarse si un documento se envió por correo electrónico o por correo postal.

¿Por qué una factura en PDF no cuenta como factura electrónica, aunque se envíe por correo electrónico?

Un PDF enviado por correo electrónico es digital, pero digital y estructurado son propiedades distintas, y solo las facturas estructuradas cumplen las obligaciones de facturación electrónica de la UE. El componente eInvoicing de la Comisión Europea es explícito en este punto: los archivos PDF y Word, los formatos de imagen como JPG o TIFF, las facturas HTML no estructuradas y el resultado de OCR de facturas en papel escaneadas quedan todos excluidos de la definición legal de factura electrónica, con independencia de cómo se hayan entregado.

La razón práctica es la automatización. Un sistema receptor no puede extraer de forma fiable el número de factura, el importe del IVA y las líneas de detalle del diseño visual de un PDF sin que una persona compruebe el resultado, y ese paso manual es justo lo que la facturación electrónica estructurada existe para eliminar. Enviar la misma factura como archivo adjunto de correo en lugar de imprimirla cambia el canal, no el formato de datos subyacente.

¿Y un PDF con un archivo XML incrustado, como ZUGFeRD o Factur-X?

Los formatos híbridos complican el panorama, porque sí pueden contar como facturas electrónicas, según el perfil que usen. ZUGFeRD y Factur-X incrustan un archivo CII XML estructurado dentro de un documento PDF/A-3 legible por humanos y, desde ZUGFeRD 2.1 en 2020, las especificaciones alemana y francesa son técnicamente idénticas, hasta el nombre de archivo incrustado compartido, factur-x.xml.

La trampa está en que ambos formatos definen varios perfiles, y no todos los perfiles incluyen datos estructurados completos. MINIMUM y BASIC WL son perfiles de datos reducidos, creados originalmente en torno a los requisitos franceses de ayuda contable; solo incluyen un subconjunto de los campos de la factura y no cumplen el requisito de facturación electrónica B2B de Alemania a partir de enero de 2026. Para facturar en modo B2B hacia Alemania, un perfil de nivel COMFORT o superior, alineado con la norma EN 16931, es la base práctica. Un PDF que técnicamente contiene XML incrustado pero usa uno de los perfiles reducidos sigue sin ser una factura electrónica conforme para esa obligación, aunque el formato del archivo parezca idéntico desde fuera.

¿Una factura escaneada o un PDF con OCR cuentan como electrónicas?

No. Una factura escaneada es una imagen de un documento, y aplicarle OCR después no la convierte de forma retroactiva en una factura electrónica estructurada; el resultado de OCR es una extracción de texto que hace lo que puede y es propensa a errores de lectura, no un formato de datos legalmente estructurado en el que un sistema receptor pueda confiar sin verificación. La propia guía de eInvoicing de la Comisión Europea señala el resultado de OCR de facturas en papel escaneadas como una de las categorías excluidas precisamente por esta falta de fiabilidad.

¿Cambia algo enviarla por correo electrónico, subirla a un portal o mandarla como HTML?

No. La estructura y el canal son cuestiones distintas, y acertar con el canal no arregla un archivo no estructurado. La Directiva 2014/55/UE exige que una factura se emita, se transmita y se reciba en formato estructurado, las tres cosas, y la mayoría de las obligaciones nacionales también especifican qué redes cumplen el paso de transmisión (Peppol, el Sistema di Interscambio de Italia, el OZG-RE de Alemania para facturas al sector público federal). Enviar un archivo XML correctamente estructurado por un canal no autorizado puede crear su propia brecha de cumplimiento, pero enviar un PDF no estructurado por el canal correcto tampoco lo convierte en factura electrónica. Para el desglose completo de lo que exige «emitida, transmitida y recibida en formato estructurado», consulta la guía de fiskaly sobre qué es una factura electrónica.

Tabla comparativa: ¿qué cuenta como factura electrónica según las obligaciones de la UE?

Tabla comparativa: ¿qué cuenta como factura electrónica según las obligaciones de la UE?

Tipo de documentoDatos estructuradosCumple las obligaciones de facturación electrónica de la UENotas
Factura en papelNo incluidoNo incluidoSolo diseño impreso
Factura escaneada o PDF con OCRNo incluidoNo incluidoDatos de imagen; el OCR no crea estructura legal
Factura en PDF simple (por correo o descargada)No incluidoNo incluidoDigital, pero sin estructura legible por máquina
Factura HTML por correo o webNo incluidoNo incluidoTexto no estructurado, sea cual sea el canal
ZUGFeRD/Factur-X, perfil MINIMUM o BASIC WLParcialmente incluidoNo incluidopara el B2B alemán desde enero de 2026Perfil de datos reducidos, campos insuficientes
ZUGFeRD/Factur-X, perfil COMFORT o superiorIncluidoIncluidosi está alineado con EN 16931CII XML estructurado incrustado en un PDF/A-3
UBL o CII XML nativo (XRechnung, Peppol BIS)IncluidoIncluidosi cumple la norma EN 16931 o una CIUS nacionalNo requiere capa visual

Puntos clave

  • «Electrónica» y «estructurada» son pruebas distintas. Un archivo puede ser totalmente digital y aun así no superar la definición legal de factura electrónica si una persona todavía tiene que leer y volver a introducir sus datos.
  • Los híbridos en PDF pueden ir en cualquier dirección. ZUGFeRD y Factur-X solo cuentan como facturas electrónicas reales cuando su perfil incrustado incluye todos los datos estructurados de la norma EN 16931, no cuando es un perfil reducido como MINIMUM o BASIC WL.
  • La elección del perfil es un riesgo de cumplimiento vigente en Alemania. Los perfiles MINIMUM y BASIC WL dejan de ser suficientes para la facturación B2B alemana a partir de enero de 2026, aunque el formato de archivo subyacente no haya cambiado.
  • El canal de envío no arregla el formato. Enviar por correo, subir a un portal o encaminar por Peppol cambia cómo viaja un archivo, no si sus datos están estructurados.
  • Los escaneos y el OCR nunca cumplen, sea cual sea el formato de origen o lo convincente que parezca la extracción por OCR.

Cómo saber si lo que envías es de verdad una factura electrónica

  1. Comprueba si el archivo subyacente es XML o contiene XML incrustado. Un documento visual sin capa de datos estructurados (PDF, escaneo o HTML) falla en este paso al margen de todo lo demás.
  2. Confirma que valida contra la norma EN 16931 o la CIUS nacional correspondiente. Un XML estructurado al que le faltan campos obligatorios o que usa el esquema equivocado no pasará la validación de un sistema receptor; una integración por API de facturación electrónica como E-INVOICE de fiskaly puede ejecutar esa validación de forma automática dentro de un sistema ERP, de facturación o de TPV existente, en lugar de exigir que ese sistema implemente la lógica de validación por su cuenta.
  3. Confirma que el perfil incluye datos estructurados completos. Para ZUGFeRD/Factur-X, eso significa COMFORT o superior, no MINIMUM ni BASIC WL, si la factura va a una contraparte B2B alemana.
  4. Confirma que la transmisión pasa por una red contra la que el sistema del receptor valida de verdad. Un archivo estructurado enviado por el canal equivocado puede crear brechas de cumplimiento bajo obligaciones que exigen Peppol, SDI o una plataforma nacional.
  5. Confirma que el sistema receptor la contabiliza automáticamente. Si el equipo de cuentas a pagar todavía tiene que abrir el archivo y volver a teclear algún campo, algo anterior en el proceso no está bien estructurado.

En resumen

El papel, el PDF, una factura escaneada y una factura HTML enviada por correo fallan todos la misma prueba: ninguno lleva datos que un ordenador pueda leer y contabilizar sin ayuda de una persona. Una factura electrónica real supera esa prueba tanto si llega como XML nativo como si llega como archivo estructurado incrustado en un PDF, y los detalles del perfil y del canal, no el aspecto exterior del archivo, deciden a qué lado de la línea cae. Para la definición legal completa que hay detrás de esta prueba, consulta la guía de fiskaly sobre qué es una factura electrónica, y para ver cómo se comparan UBL, XRechnung, FatturaPA y Facturae formato a formato, consulta la guía de formatos de factura electrónica de fiskaly. fiskaly E-INVOICE genera y valida formatos conformes en varios mercados de la UE desde una única integración.

Preguntas frecuentes

No. Una factura en PDF simple es un documento digital pensado para que lo lea una persona, y la guía de eInvoicing de la Comisión Europea excluye expresamente los archivos PDF de la definición legal de factura electrónica, con independencia del canal usado para enviarla.

No, no por sí solo. La Directiva 2014/55/UE exige que la factura se emita, se transmita y se reciba en un formato de datos estructurado. El correo cambia el canal de transmisión, no si el archivo subyacente contiene esa estructura.

No. Una factura escaneada son datos de imagen, y la extracción por OCR posterior es una conversión de texto que hace lo que puede, no un formato legalmente estructurado que un sistema receptor pueda validar y en el que pueda confiar.

Depende del perfil. ZUGFeRD y Factur-X incrustan CII XML estructurado dentro de un PDF, y los perfiles de nivel COMFORT o superior, alineados con la norma EN 16931, cuentan como facturas electrónicas reales. Los perfiles de datos reducidos como MINIMUM y BASIC WL no incluyen suficientes datos estructurados para cumplir.

COMFORT o un perfil superior alineado con la norma EN 16931. Los perfiles MINIMUM y BASIC WL no cumplen el requisito de facturación electrónica B2B de Alemania a partir de enero de 2026, aunque el formato de archivo parezca igual desde fuera.

El método de entrega es un requisito independiente del formato de datos. Una factura estructurada enviada por el canal equivocado aún puede crear una brecha de cumplimiento bajo obligaciones que exigen una red concreta, pero ningún método de entrega hace conforme un archivo no estructurado.

No. Una firma digital confirma la autenticidad y la integridad del documento; no dice nada sobre si los datos de la factura están estructurados. Un PDF firmado sin XML estructurado incrustado sigue siendo un PDF a efectos de facturación electrónica.