Facturae 3.2.2 en el ERP de una pyme distribuidora: obligaciones y requisitos técnicos

Si tu empresa distribuye a administraciones públicas o estás preparando la transición a la factura electrónica obligatoria, Facturae 3.2.2 ya no es algo que puedas dejar para después. Este artículo explica cuándo estás obligado a emitirla, qué datos exige el formato y qué funciones concretas debe tener tu ERP para generarla correctamente.

Qué es Facturae 3.2.2 y por qué importa en distribución

Facturae es el formato de factura electrónica estructurada que define el Ministerio de Hacienda español. La versión 3.2.2 es la última especificación estable del esquema XML y la única aceptada en los portales de facturación de las administraciones públicas desde 2015.

Una distribuidora que entrega a un ayuntamiento, a una consellería autonómica o a cualquier organismo público receptor de facturas en FACe o en portales equivalentes tiene que enviar exactamente este formato, con firma electrónica XAdES incluida. No es opcional y no hay sustituto válido: un PDF, aunque esté firmado, no cumple.

Facturae 3.2.2 es el único formato de factura electrónica aceptado por la Administración General del Estado y por la mayoría de administraciones autonómicas y locales españolas.

Cuándo está obligada tu distribuidora a usar Facturae 3.2.2

Ventas a administraciones públicas: ya es obligatorio

Desde enero de 2015, la Ley 25/2013 obliga a emitir facturas electrónicas a proveedores de la Administración General del Estado. La mayoría de comunidades autónomas y ayuntamientos han extendido esa obligación a sus propios proveedores mediante normativa propia.

Si facturáis a un cliente que es un ente público —hospital, colegio público, organismo municipal, diputación— la obligación es inmediata e incondicional, independientemente del importe y del tamaño de tu empresa.

Ventas entre empresas privadas: la fecha se acerca

La Ley Crea y Crece (Ley 18/2022) establece la factura electrónica obligatoria entre empresas privadas. Según el reglamento técnico en tramitación, las empresas con facturación anual superior a 8 millones de euros deberán cumplir en 2025 y el resto de pymes en 2026, aunque los plazos definitivos dependen de la aprobación del reglamento.

El formato para el canal B2B todavía admite alternativas estructuradas, pero Facturae 3.2.2 es la referencia más consolidada y la que el ecosistema de plataformas de intercambio ya soporta.

Resumen de obligaciones por tipo de destinatario

• Administración pública (AGE, CC. AA., entidades locales): obligatorio desde 2015, formato Facturae 3.2.2 con firma XAdES, envío por FACe o portal equivalente.
• Empresa privada grande (> 8 M € facturación): obligatorio previsiblemente desde 2025 según reglamento pendiente.
• Empresa privada pyme: obligatorio previsiblemente desde 2026, con posibilidad de formatos alternativos si la plataforma los acepta.

Qué contiene un XML de Facturae 3.2.2

El archivo XML tiene una estructura jerárquica con tres bloques principales:

1. FileHeader: versión del esquema, modalidad (individual o por lotes), número de facturas y totales generales.
2. Parties: datos completos del emisor y del receptor, incluyendo NIF, nombre fiscal, dirección, código CNAE y, en facturas a la administración, los códigos de unidad orgánica, oficina contable y órgano gestor del DIR3.
3. Invoices: una o varias facturas, cada una con cabecera, líneas de detalle, impuestos desglosados, totales y, opcionalmente, datos de pago.

El archivo completo se firma con un certificado digital reconocido usando el estándar XAdES-EPES. Sin esa firma, el portal receptor rechaza el archivo.

Campos que generan más rechazos en distribuidoras

• Códigos DIR3 incorrectos o desactualizados: cada administración tiene su propio código de oficina contable. Si el ERP no los almacena por cliente, el error es manual y recurrente.
• Descripción de líneas de factura demasiado genérica: algunos organismos exigen una descripción mínima de los bienes o servicios. Una línea como “mercancía” puede provocar rechazo.
• Forma de pago ausente o errónea: el bloque de condiciones de pago es obligatorio en las facturas a la administración.
• NIF del receptor sin verificación: un NIF mal introducido invalida la factura.

Qué debe soportar el ERP para generar Facturae 3.2.2 sin intervención manual

Un ERP que obligue al equipo de facturación a corregir el XML a mano no es una solución, es un riesgo. Estos son los requisitos mínimos que el módulo de facturación debe cubrir:

1. Generación nativa del XML conforme al esquema oficial 3.2.2, sin exportaciones intermedias ni plugins externos.
2. Almacén de códigos DIR3 por cliente, editable y con validación de formato, para que el dato se aplique automáticamente en cada factura al organismo correspondiente.
3. Firma electrónica XAdES integrada, con el certificado cargado en el sistema, de modo que la firma se aplique en el momento de emitir.
4. Envío directo a FACe o portal autonómico equivalente, o al menos exportación en el formato que esos portales aceptan sin conversión adicional.
5. Registro de estado de la factura: aceptada, rechazada, pagada. Saber que el XML salió del ERP no basta; necesitas saber si la administración la aceptó.
6. Compatibilidad con Verifactu: si el ERP también gestiona facturas a clientes privados, el registro de facturas debe cumplir el Reglamento de Facturación (RD 1007/2023) y conectar con la AEAT.

Un ERP que genera Facturae 3.2.2 pero no almacena los códigos DIR3 por cliente ni devuelve el estado de aceptación transfiere el trabajo manual al equipo de administración.

El problema específico de las distribuidoras con flota

Una distribuidora con reparto propio tiene una particularidad: la factura no siempre refleja exactamente lo que salió del almacén. Los albaranes cambian en ruta —una parada puede rechazar parte del pedido, otra puede añadir una unidad— y esas diferencias tienen que consolidarse antes de facturar.

Si el ERP no conecta el cierre de ruta con el módulo de facturación, alguien tiene que reconciliar esas diferencias a mano antes de generar el XML. Ese proceso manual es donde se introducen errores de cantidad, de referencia o de precio que después provocan rechazos o reclamaciones.

El flujo correcto en un ERP para distribución es:

1. El conductor cierra la parada en la app (con firma del destinatario si aplica).
2. El sistema consolida las diferencias entre pedido y entrega real.
3. El módulo de facturación recoge los datos consolidados y genera el albarán definitivo.
4. Sobre ese albarán se emite la factura —o la factura agrupada por cliente— en formato Facturae 3.2.2 si el destinatario es una administración pública.

Sin ese encadenamiento, Facturae 3.2.2 es un trámite que se hace fuera del ERP, con los datos copiados a mano, y eso acaba en errores.

Cómo aborda Rowan ERP este proceso

En Rowan ERP el módulo de facturación está conectado directamente con el cierre de rutas y con el SGA. Cuando el conductor confirma una parada —con o sin conexión, la app sincroniza al recuperar cobertura— los datos de entrega real pasan automáticamente al albarán. Desde ahí, el responsable de facturación genera la factura con un solo paso, y si el cliente es una administración pública el sistema produce el XML Facturae 3.2.2 firmado con el certificado de la empresa.

Los códigos DIR3 se almacenan en la ficha de cada cliente de la administración y se aplican sin intervención adicional. El estado de la factura —aceptada, rechazada, pendiente— queda registrado en el historial del cliente.

Si gestionas reparto a organismos públicos y quieres ver cómo funciona el ciclo completo —desde la parada hasta el XML enviado— puedes escribirnos desde rowanerp.com.