Facturación electrónica obligatoria: qué sistemas tuyos tienen que hablar entre sí

La facturación electrónica obligatoria es la exigencia de que las facturas entre empresas y profesionales se emitan, se envíen y se reciban en un formato estructurado que las máquinas puedan leer, a través de plataformas que cumplen unos requisitos técnicos. No es enviar un PDF por email: es que la factura viaje como dato, con su ciclo de vida registrado.

Y ese matiz es todo el problema. Porque si la factura deja de ser un documento que alguien redacta y pasa a ser un dato que circula, la pregunta deja de ser “¿qué programa de facturas compro?” y pasa a ser “¿qué sistemas míos tienen que hablar entre sí para que la factura salga sola y con los datos correctos?”.

Esa es la parte de la que casi nadie habla, y es la que te va a costar dinero si la dejas para el final. Este artículo va de eso. No es asesoramiento fiscal: en FCG Systems integramos sistemas, no llevamos tu contabilidad. Para saber qué te obliga y desde cuándo, tu asesor.

Las dos obligaciones que se están mezclando

Antes de tocar nada conviene separar dos cosas que circulan juntas y no lo son:

Son obligaciones acumulativas. Cumplir una no te libra de la otra. Si lo que te interesa ahora es la primera, la tienes desarrollada en qué es Verifactu y qué tiene que hacer tu software.

Qué dice la norma de la factura electrónica, con fuentes

El punto de partida es el artículo 12 de la Ley 18/2022, de 28 de septiembre, la llamada “Crea y Crece”, que extendió a todas las relaciones entre empresas y profesionales la obligación de factura electrónica que hasta entonces solo existía frente a la Administración.

Su desarrollo reglamentario es el Real Decreto 238/2026, de 25 de marzo, publicado en el BOE el 31 de marzo de 2026. La Agencia Tributaria lo resume en su ficha de novedades de normativa (consultado en septiembre de 2026). Lo que fija, en lo que nos afecta:

• Plazos. Doce meses para empresarios y profesionales cuyo volumen de operaciones haya excedido de 8 millones de euros, y veinticuatro meses para el resto. Ambos se cuentan desde la entrada en vigor de la orden ministerial que desarrolle la solución pública de facturación electrónica, no desde la publicación del real decreto.
• Sintaxis admitidas. CII, UBL, EDIFACT y Facturae. Los mensajes Peppol BIS se consideran válidos porque emplean UBL, que además es la sintaxis de referencia de la solución pública.
• Estados obligatorios. El destinatario debe informar de la aceptación o rechazo comercial de la factura y del pago efectivo completo, con sus fechas, en un plazo máximo de cuatro días naturales, excluyendo sábados, domingos y festivos. El pago efectivo completo se comunica siempre a la solución pública, uses la plataforma que uses.
• Solución pública. La AEAT pondrá a disposición una herramienta gratuita para emitir facturas electrónicas y comunicar estados, disponible antes de la aplicación efectiva.

A septiembre de 2026 la orden ministerial que dispara el cómputo sigue siendo el hito a vigilar. Conviene comprobarlo en la sede de la AEAT antes de fijar ninguna fecha interna: esto es normativa en curso y se ha movido más de una vez.

Lo que la norma te obliga a tener, dicho en arquitectura

Traduce los cuatro puntos anteriores a requisitos de sistema y aparece esto:

1. Un emisor único de facturas fiscales. Un sistema, no tres.
2. Datos maestros de cliente fiables. NIF correcto, razón social, dirección y, ahora, la dirección electrónica a la que se le entrega la factura.
3. Una conexión con una plataforma de intercambio (o con la solución pública) capaz de emitir en una de las sintaxis admitidas.
4. Un canal de vuelta. Los estados no son informativos: hay que capturarlos, guardarlos y responder en plazo. Esto es lo que rompe el modelo de “facturo y me olvido”.
5. Trazabilidad. Qué se emitió, cuándo, en qué estado está y quién lo cambió.

El punto 4 es el que cambia la naturaleza del problema. Hasta ahora una factura era un documento que salía. Ahora es un objeto con ciclo de vida que recibe eventos externos con plazo de respuesta. Eso es, literalmente, una integración con webhooks y cola de trabajo, no una plantilla de Word.

Dónde se rompe esto en un negocio real

Si tu negocio vende online, las facturas no nacen en el programa de facturación. Nacen mucho antes, en sitios distintos:

• En la pasarela de pago, cuando alguien compra con tarjeta.
• En la plataforma de suscripciones, cada renovación mensual.
• En el CRM, cuando el equipo comercial cierra una venta y se factura por transferencia.
• En la plataforma de cursos o membresía, con altas, bajas y cambios de plan.
• A mano, en los casos raros que siempre existen.

Y aquí es donde aparecen los fallos que ya he visto varias veces:

• Numeración duplicada. Dos sistemas emitiendo con la misma serie porque nadie decidió cuál manda.
• Cliente sin NIF. La compra online se hace con un email y el NIF se pide después, o no se pide. Cuando llega el momento de emitir la factura estructurada, falta un dato obligatorio y el proceso se para.
• El mismo cliente dos veces. Identificado por email en un sistema y por NIF en otro. Cuando el email cambia, aparece un cliente nuevo.
• La baja que no llega. El cliente cancela en la plataforma, pero la suscripción sigue viva en la pasarela y se factura un mes más. Devolución, rectificativa y una conversación incómoda.
• El estado que nadie escucha. El destinatario rechaza la factura, el webhook llega, nadie lo procesa y el plazo pasa.

Ninguno de estos es un problema de normativa. Son problemas de integración que la normativa convierte en visibles y con plazo. Es el patrón de siempre: los errores que fallan en silencio dejan de ser silenciosos cuando alguien externo empieza a mirar.

Cómo se monta para que la factura salga sola

El diseño que aplico, y que no depende de qué herramientas uses:

1. Decide la fuente de verdad de cada cosa

Tres fuentes, tres dueños:

Si dos sistemas se disputan un dato, ya tienes el bug. Es la misma regla que aplico a los accesos por suscripción en sistemas para negocios digitales: quien manda sobre un dato es uno solo, el resto lo reflejan.

2. Captura la identidad fiscal en el momento de la compra, no después

Si vendes a empresas, el NIF y la razón social son campos del checkout, no un email de seguimiento tres días después. Cualquier dato fiscal que se pida a posteriori se convierte en trabajo manual para alguien.

3. Relaciona los sistemas por identificador, nunca por email

Guarda el identificador de cliente de la pasarela en la ficha del CRM y en la del software de facturación desde la primera compra. El email cambia, se escribe distinto o se usa uno para pagar y otro para acceder. Un identificador estable es lo único que aguanta.

4. Dispara la factura con un evento, no con una persona

El cobro confirmado genera un evento; ese evento crea la factura. Con tres reglas que evitan la mayoría de los desastres:

• Idempotencia. El mismo evento dos veces no puede generar dos facturas. Guarda el identificador del evento procesado.
• Sin depender del orden. Ante cualquier evento, consulta el estado actual en la fuente de verdad y decide con ese dato.
• Cola con reintentos. Si el software de facturación no responde, el evento se reintenta; no se pierde.

5. Escucha los estados y responde en plazo

Los estados que vuelven (aceptado, rechazado, pagado) entran por el mismo tipo de canal y con la misma disciplina: verificación, idempotencia, registro y, cuando hace falta, aviso a un responsable con nombre. Cuatro días hábiles no dan para descubrir el lunes que el viernes llegó un rechazo.

6. Reconcilia todos los días

Una vez al día, compara cobros confirmados con facturas emitidas y facturas emitidas con estados recibidos. Cualquier diferencia es un fallo, aunque ninguna herramienta haya marcado error. Es la comprobación que más problemas destapa, y la que casi nadie monta.

7. Deja traza de todo

Qué evento entró, qué factura se generó, qué estado se comunicó y cuándo. Sin log no hay forma de responder a “¿por qué a este cliente se le facturó dos veces en marzo?”.

Checklist antes de que empiecen a correr los plazos

• Inventario de todos los sistemas desde los que hoy sale una factura.
• Decidido cuál es el emisor único de facturas fiscales.
• Declaración responsable del proveedor de ese software (requisito de Verifactu).
• Plataforma de intercambio elegida, o solución pública, con la sintaxis que vas a emitir.
• NIF y razón social capturados en el checkout para las ventas B2B.
• Identificador de cliente compartido entre pasarela, CRM y facturación.
• Emisión disparada por evento, idempotente y con reintentos.
• Estados entrantes procesados y respondidos dentro del plazo.
• Reconciliación diaria entre cobros, facturas y estados.
• Log por factura y un responsable que recibe los avisos.
• Fechas confirmadas en la sede de la AEAT, no en un artículo de blog (este incluido).

Dónde acaba el asesor y empieza el sistema

Tu asesor decide si te aplica, desde cuándo y con qué implicaciones fiscales. Ese reparto no lo discuto.

Lo que ninguna asesoría te va a montar es que tu pasarela, tu CRM, tu plataforma y tu software de facturación intercambien datos sin que nadie copie nada a mano. Eso es integración, y es donde está el trabajo real: eventos, identificadores estables, idempotencia, reintentos, reconciliación y trazas. Es un proyecto típico de automatización de procesos, con diseño, integración, pruebas y documentación; y cuando lo que tienes no encaja con ninguna herramienta del mercado, de software a medida.

Si no sabes con certeza desde cuántos sitios salen hoy tus facturas ni con qué datos, cuéntame cómo está montada tu operativa y lo revisamos.