Facturae 3.2.2 y 3.2.x: qué versión usar, campos obligatorios y firma XAdES

Facturae lleva más de una década en el mercado, pero la mayoría de equipos AP la conocen solo de oídas. Cuando una factura Facturae llega al buzón, lo habitual es abrirla en el visor, leer el PDF de presentación y reteclear los datos. El XML va a la papelera.

Ese es el error que Crea y Crece va a hacer muy caro. Si los datos están en el XML estructurado y tú trabajas desde el PDF, estás añadiendo fricción donde el formato fue diseñado para eliminarla.

Este artículo explica qué añade cada versión de la familia 3.2.x, qué campos son obligatorios, cómo funciona la firma XAdES y qué errores concretos provocan el rechazo de una factura. Sin teoría de más.

Qué es Facturae y de dónde viene

Facturae es el formato de factura electrónica oficial de la Administración Española. Lo define el Ministerio de Hacienda y su documentación técnica, incluyendo el schema XSD, está disponible en facturae.gob.es.

Nació principalmente para la facturación entre empresas y administraciones públicas (B2G). FACe (la Plataforma de Facturación Electrónica del Estado) usa Facturae como formato obligatorio para proveedores que facturan a la Administración General del Estado. Desde que se aprobó la Ley Crea y Crece, Facturae es uno de los dos formatos reconocidos también para la facturación B2B privada, junto con Peppol BIS 3.0.

El formato es XML con un schema propio. No es UBL estándar. No es CII. Es el schema MINHAC (Ministerio de Hacienda). Esto tiene implicaciones prácticas: un sistema que lee Peppol UBL no lee Facturae sin un mapper de campos específico. Esta información es orientativa. Consulte con su asesor fiscal.

Facturae 3.2, 3.2.1 y 3.2.2: qué añade cada versión

«3.2.x» no es una versión concreta: es la familia formada por 3.2, 3.2.1 y 3.2.2. Comparten esquema base y firma XAdES-EPES, y cada revisión añade etiquetas nuevas sin romper las anteriores. Esta es la referencia rápida:

Versión	Qué aporta	Cuándo usarla
3.2	Base de la familia 3.2.x. Esquema XSD estable con firma XAdES-EPES.	Solo si tu receptor la exige expresamente. Sigue aceptada.
3.2.1	Revisión intermedia sobre 3.2.	Sin ventaja frente a 3.2.2 en emisiones nuevas.
3.2.2	Versión vigente. Añade sobre 3.2.1 los campos de cesión de crédito (FactoringAssignmentDocument, DocumentType, Repository, Reference…), InvoiceIssueDate para identificar la factura rectificada, InvoiceDescription, las referencias ReceiverTransactionReference, FileReference y ReceiverContractReference, y el pago en especie (PaymentInKind). Suma la unidad KWh y el formato HTML como adjunto admitido.	La opción por defecto para emisiones nuevas.

El listado completo de campos y el esquema XSD de cada versión están publicados en Últimas versiones Facturae.

Para cuentas a pagar, las incorporaciones más útiles de la 3.2.2 son las referencias a nivel de factura (ReceiverTransactionReference, FileReference, ReceiverContractReference): permiten que el emisor traslade tu propio identificador de pedido o de contrato dentro del XML, en lugar de dejarlo enterrado en el texto libre de la línea. Cuando ese campo viene relleno, casar la factura con el pedido deja de ser una inferencia y pasa a ser una lectura directa.

Estructura XML: qué viene en una factura Facturae

Un archivo Facturae es un XML con tres bloques principales:

1. Cabecera (FileHeader). Versión del formato, número de facturas en el archivo (un XML puede contener múltiples facturas), modalidad (individual o por lotes), esquema de moneda.
2. Partes (Parties). Datos del emisor (NIF, razón social, dirección) y del receptor. Cada campo tiene su etiqueta propia: TaxIdentificationNumber, CorporateName, AddressInSpain.
3. Facturas (Invoices). Una o varias facturas. Cada una contiene:
   • InvoiceHeader: número, serie, tipo (completa, abreviada, resumen), clase (original, duplicado, rectificativa).
   • InvoiceDates: fecha de emisión, fecha de operación.
   • InvoiceTotals: base imponible, cuota IVA, total bruto, descuentos globales, total a pagar.
   • Items: lista de líneas. Cada línea tiene Description, Quantity, UnitPriceWithoutTax, TotalCost, DiscountsAndRebates, GrossAmount.
   • TaxesOutputs: tipos de IVA aplicados, base de cada tipo, cuota.
   • PaymentDetails: IBAN, fecha de vencimiento, método de pago.

Lo que esto significa para AP: todos los datos que necesitas para el three-way matching están en campos etiquetados. UnitPriceWithoutTax es el precio unitario sin IVA, que es el que debes comparar con el precio del pedido de compra. Quantity es la cantidad facturada. TotalCost es el importe de línea antes de descuentos.

Campos obligatorios: qué no puede faltar en el XML

Un XML puede validar contra el XSD y aún así ser rechazado si falta información exigida al destinatario. Conviene separar dos niveles: lo que exige el esquema Facturae y lo que añade el receptor público cuando facturas a la Administración vía FACe.

Bloque	Campos que no pueden faltar	Etiqueta XML
Emisor y receptor	NIF de ambas partes, razón social y domicilio	TaxIdentificationNumber, CorporateName, AddressInSpain
Cabecera de factura	Número de factura, tipo y clase	InvoiceNumber, InvoiceDocumentType, InvoiceClass
Fechas	Fecha de expedición	IssueDate
Líneas	Descripción, cantidad y precio unitario sin impuestos	Description, Quantity, UnitPriceWithoutTax
Impuestos y totales	Base imponible, tipo y cuota de IVA, total a pagar	TaxesOutputs, InvoiceTotals
Solo B2G (FACe)	Los tres códigos DIR3: oficina contable, órgano gestor y unidad tramitadora	AdministrativeCentres

El NIF del receptor es el campo que más rechazos provoca. No basta con que esté presente: debe corresponder al NIF real de la entidad destinataria y estar en el bloque correcto. Un NIF válido sintácticamente pero de otra entidad del grupo, o colocado en ThirdParty en lugar de en el receptor, produce un rechazo que el emisor suele tardar días en detectar.

Los tres códigos DIR3 solo aplican a la facturación a Administraciones Públicas: los facilita el propio organismo y sin ellos FACe no admite la factura. En B2B privado no se usan. Esta información es orientativa. Consulte con su asesor fiscal.

XAdES: qué es y por qué importa

XAdES (XML Advanced Electronic Signatures) es el estándar europeo de firma electrónica avanzada sobre documentos XML. Está definido en el estándar ETSI EN 319 132 y es el mecanismo que Facturae usa para garantizar la integridad y autenticidad de la factura.

Hay varios niveles de XAdES. Facturae usa XAdES-EPES (Explicit Policy Electronic Signature), que incluye una referencia explícita a la política de firma aplicada. En la práctica esto significa que la firma incorpora:

• El certificado del firmante (NIF del emisor vinculado a la firma).
• El timestamp de la firma.
• Una referencia criptográfica a la política de firma publicada por el Ministerio de Hacienda.
• El hash SHA-256 del contenido del documento.

Por qué la política de firma es la v3.1 y el formato la 3.2.2

Es la duda técnica que más se repite, y la respuesta es sencilla: el formato y la política de firma se versionan por separado. En Políticas de firma electrónica el Ministerio publica únicamente dos: la versión 3.1 (Politica_Firma_formato_facturae_v3_1.pdf) y la 3.0, anterior. No existe una «política de firma 3.2.2».

Es decir: una factura en formato 3.2.2 se firma aplicando la política v3.1, y eso es lo correcto. Si tu librería de firma te pide la URL o el hash de la política, el valor que debes referenciar es el del documento v3.1, no el número de versión del esquema XML. Junto al PDF se publica su hash para que puedas incrustar la referencia criptográfica exacta en el elemento SignaturePolicyIdentifier.

Para AP, la consecuencia práctica es doble. Primero: puedes verificar que el contenido XML no ha sido modificado desde que el emisor lo firmó. Si el hash del XML que recibes coincide con el hash encapsulado en la firma, el documento es íntegro. Segundo: el NIF del emisor está vinculado criptográficamente a la firma. No es posible suplantar a un emisor sin acceso a su certificado.

Esto es relevante para la detección de fraude en AP. Una factura Facturae con firma XAdES válida del NIF de un proveedor conocido es más difícil de falsificar que un PDF enviado por correo.

FACe: la plataforma pública de facturas electrónicas

FACe (Punto General de Entrada de Facturas Electrónicas de la Administración General del Estado) es la plataforma pública para recibir facturas de proveedores dirigidas a la Administración. Si tu empresa provee a organismos públicos, ya conoces FACe. Si tu empresa recibe facturas de proveedores que también tienen contratos públicos, es posible que esos proveedores usen FACe para todas sus emisiones, incluyendo las B2B privadas.

Para el receptor en un contexto B2B privado, FACe no es una plataforma obligatoria. Las facturas Facturae pueden llegar por correo, por portal del proveedor, o por plataformas intermediarias privadas. FACe es la vía obligatoria solo para facturas dirigidas a la Administración. Esta información es orientativa. Consulte con su asesor fiscal.

Lo que sí es relevante para AP: si recibes una factura generada desde FACe, el XML viene con estructura Facturae estándar y con firma XAdES. Tu sistema AP puede procesarla exactamente igual que cualquier otra Facturae.

Cómo procesar Facturae en tu flujo AP

El flujo correcto para una factura Facturae recibida tiene cuatro pasos:

1. Recepción e identificación del formato. El archivo tiene extensión .xsig o .xml. El sistema AP debe detectar que es Facturae leyendo el namespace del XML (http://www.facturae.es/Facturae/2009/v3.2/Facturae para 3.2, con variante para 3.2.x).
2. Validación de la firma XAdES. Verificar que el hash del contenido coincide con el encapsulado en la firma y que el certificado es válido. Esto puede hacerse con librerías estándar o delegarse en una plataforma intermediaria.
3. Extracción de campos por etiqueta. Leer UnitPriceWithoutTax, Quantity, TaxIdentificationNumber y el campo de referencia de pedido. Sin OCR. Sin interpretación de píxeles.
4. Three-way matching. Comparar los campos extraídos con el pedido de compra y el albarán de entrega. Con datos limpios, la precisión del matching sube significativamente.

El punto crítico es el paso 3. Si tu sistema AP no tiene un parser Facturae, los pasos 2 y 4 también fallan. El parser debe conocer el schema XSD de Facturae 3.2.x para mapear correctamente los campos.

Formatos aceptados en AP: tabla de referencia

Formato	Tipo	Firma	Parser requerido	Uso típico
Facturae 3.2.x	XML XSD MINHAC	XAdES-EPES	Parser Facturae específico	B2G y B2B ES
Peppol BIS 3.0	XML UBL 2.1	Firma Peppol (red 4-corner)	Parser UBL/EN16931	B2B cross-border EU
PDF/A firmado	PDF + firma digital	PAdES o XAdES	OCR + extractor PDF	No válido bajo Crea y Crece como formato principal
PDF sin firma	PDF	Sin firma	OCR	Período de transición, proveedores sin adaptar

Errores frecuentes al procesar Facturae

Cuatro problemas que aparecen una y otra vez en equipos AP que empiezan a recibir facturas electrónicas en formato Facturae:

Problema 1: usar el PDF de presentación en lugar del XML. Muchas facturas Facturae se envían con un PDF de representación visual adjunto. El PDF es para que el lector humano entienda la factura. El XML es la fuente oficial de datos. Procesar el PDF con OCR y descartar el XML es desperdiciar el formato.

Problema 2: no validar la firma XAdES. Si tu sistema extrae datos del XML sin verificar la firma, no puedes saber si el documento ha sido modificado en tránsito. Para facturas de importe elevado, esto es un riesgo de fraude significativo.

Problema 3: confundir el precio unitario con el precio total de línea. UnitPriceWithoutTax es el precio por unidad sin IVA. TotalCost es el importe total de la línea antes de descuentos. Para el three-way matching, debes comparar precio unitario de la factura contra precio unitario del pedido, no totales. El total de línea depende de la cantidad y puede enmascarar discrepancias de precio.

Problema 4: ignorar las rectificativas. Facturae tiene un campo InvoiceClass que puede ser OO (original), OR (rectificativa por reemplazo) o OC (rectificativa por diferencias). Si recibes una rectificativa y tu sistema la trata como factura original, vas a duplicar o confundir importes en el libro de facturas recibidas.

Ejemplo práctico: de una línea XML a la desviación contra el pedido

Esta es una línea típica del bloque Items de una factura Facturae:

<InvoiceLine>
  <ItemDescription>Cable H07V-K 2,5mm negro</ItemDescription>
  <Quantity>120</Quantity>
  <UnitOfMeasure>01</UnitOfMeasure>
  <UnitPriceWithoutTax>4.180000</UnitPriceWithoutTax>
  <TotalCost>501.60</TotalCost>
  <GrossAmount>501.60</GrossAmount>
</InvoiceLine>

Si el pedido de compra recoge esa misma referencia a 4,00 €/unidad y 120 unidades, la comparación correcta es precio unitario contra precio unitario, nunca total contra total:

• Desviación de precio = (4,18 − 4,00) × 120 = 21,60 €
• Desviación de cantidad = (120 − 120) × 4,00 = 0 €

El detalle importante: TotalCost (501,60 €) es coherente consigo mismo, así que una validación que solo compruebe que la factura «cuadra» no detecta nada. La desviación solo aparece al comparar línea a línea contra el pedido. Por eso comparar totales de cabecera no sirve: incluyen IVA, absorben descuentos globales y no distinguen una subida de precio de una entrega parcial.

Con el XML estructurado esta comprobación es determinista — los valores vienen etiquetados, no interpretados. Es exactamente el cálculo que hace la triple conciliación entre factura, pedido y albarán.

Preguntas frecuentes

¿Qué versión de Facturae debo usar?

La 3.2.2: es la última versión publicada del formato y la opción por defecto para emisiones nuevas. Las versiones 3.2 y 3.2.1 siguen siendo válidas y forman con ella la familia 3.2.x. Verifica siempre el listado vigente en facturae.gob.es. [Consulte con su asesor fiscal]

¿Por qué la política de firma es la v3.1 si el formato es la 3.2.2?

Porque el formato XML y la política de firma se versionan de forma independiente. El Ministerio publica la política de firma en versión 3.1 (Politica_Firma_formato_facturae_v3_1.pdf) y no existe una política 3.2.2. Una factura en formato 3.2.2 firmada bajo la política v3.1 es correcta: es justamente lo esperado.

¿Facturae 3.4 es una versión del formato?

No. 3.4 es la versión de la aplicación de escritorio gratuita del Ministerio para generar y gestionar facturas. El formato XML va por otra numeración y su versión vigente es la 3.2.2. Confundir ambas es habitual porque la aplicación se descarga desde el mismo portal.

¿Es obligatorio el NIF del receptor?

Sí. El NIF del receptor (TaxIdentificationNumber dentro del bloque del destinatario) es obligatorio, y debe ser el de la entidad realmente destinataria. Un NIF correcto pero de otra sociedad del grupo, o informado en ThirdParty en lugar de en el receptor, es una de las causas más frecuentes de rechazo.

¿Cómo valido que una firma XAdES es correcta?

Hay librerías de código abierto (Java, .NET, Python) que validan XAdES-EPES. También puedes usar el validador de FACe o plataformas intermediarias que lo hacen automáticamente en el flujo de ingesta.

¿Un PDF enviado por correo con firma digital es Facturae?

No. Facturae es el formato XML con schema XSD de Hacienda. Un PDF firmado digitalmente es un PDF con firma, no es Facturae aunque incluya firma electrónica.

¿Puede haber múltiples facturas en un solo archivo Facturae?

Sí. El formato permite incluir varias facturas en un único archivo XML. El campo BatchIdentifier en la cabecera identifica el lote. Tu sistema AP debe iterar sobre el bloque Invoices para procesar cada factura del lote.

¿Cómo trato una factura rectificativa en AP?

Lee el campo InvoiceClass. Si es OR o OC, es una rectificativa. Debes identificar la factura original que rectifica (campo ReasonDescription y referencia a la factura original) y aplicar el ajuste correspondiente en el libro de facturas recibidas. No la trates como factura nueva.

¿Facturae sirve para facturas intracomunitarias?

Sí, el formato tiene campos específicos para IVA intracomunitario e inversión del sujeto pasivo. Para proveedores europeos, sin embargo, es más probable recibir Peppol BIS 3.0. [Consulte con su asesor fiscal]

Lo que necesita saber tu equipo AP

Facturae 3.2.x es el formato XML con firma XAdES que llegará a tu correo cuando tus proveedores adopten Crea y Crece. Tres cosas concretas:

1. El XML es la fuente de datos oficial. El PDF adjunto es para visualización. Tu sistema AP debe leer el XML, no el PDF.
2. La firma XAdES garantiza que los datos no han sido alterados. Validarla es una capa de seguridad contra facturas fraudulentas.
3. Las rectificativas tienen su propia clase (InvoiceClass). Un parser que no las distinga de las originales genera errores en el libro de IVA.

Esta información es orientativa. Consulte con su asesor fiscal.

Contenido relacionado

• Three-way matching: cómo cruzar factura, pedido y albarán línea a línea
• Ley Crea y Crece: e-factura B2B obligatoria y AP automation
• Operaciones intracomunitarias e IVA con inversión del sujeto pasivo