En este artículo
Stripe Billing ante la factura electrónica alemana de 2027
Stripe Billing y Stripe Invoicing generan un PDF. Stripe remite a las apps de su Marketplace para generar y enviar facturas estructuradas. En las operaciones B2B nacionales sujetas a la obligación, la fecha de la operación y la facturación legal del emisor en el año anterior determinan cuándo termina la transición para los PDF.
Casi todo lo que se escribe sobre este tema viene de asesorías fiscales o de proveedores que venden un conversor de formato. Este texto está escrito desde el lado de la construcción. La pregunta que responde no es "qué dice la ley", sino qué tiene que construir de verdad un equipo de ingeniería alrededor de una pasarela de pago y qué partes puede comprar. Es una guía de ingeniería, no asesoramiento fiscal, y las posiciones fiscales siguen siendo de tu asesor.
Qué cambia y cuándo
Los plazos que importan a un equipo de software no son una fecha sino una matriz. Recibir pasó a ser obligatorio antes que emitir, y cada país vecino resolvió el transporte de otra manera.
| Jurisdicción | Fecha | Qué cambia para un sistema de facturación |
|---|---|---|
| Alemania | 1 ene 2025 | Toda empresa nacional debe poder recibir y procesar una factura EN 16931. Sin periodo transitorio y sin veto del destinatario. |
| Alemania | hasta 31 dic 2026 | El papel sigue permitido. El PDF solo con la conformidad del destinatario. |
| Alemania | 1 ene 2027 | Para operaciones B2B nacionales sujetas a la obligación en 2027, los emisores cuya facturación legal de 2026 supere los 800.000 euros generalmente deben emitir facturas electrónicas estructuradas. Hasta 800.000 euros inclusive se permite el papel o el PDF con consentimiento del destinatario hasta finales de 2027. La transición separada para EDI con consentimiento del destinatario también dura hasta finales de 2027. |
| Alemania | 1 ene 2028 | Terminan las transiciones por facturación y por EDI. Las excepciones permanentes siguen vigentes. |
| Austria | hoy | Las facturas estructuradas son obligatorias hacia la administración central. La ficha de país de la Comisión Europea registra ningún mandato B2B. |
| Francia | desde el 1 sep 2026 | La recepción ya es obligatoria para todas las empresas y la emisión para empresas grandes y medianas. Las más pequeñas siguen el 1 sep 2027. Las facturas circulan por una plataforma acreditada, no directamente al comprador. |
| Bélgica | 1 ene 2026 | Facturación electrónica B2B nacional, construida sobre la red Peppol. |
| UE (ViDA) | 1 jul 2030 | Factura electrónica EN 16931 y reporte digital para operaciones B2B intracomunitarias. |
Lee la fila de Francia junto a la de Alemania. Alemania impone un formato y deja el canal a las partes, así que el correo electrónico es un medio de entrega legítimo. Francia impone una red. Si tu hoja de ruta trata "factura electrónica" como una sola funcionalidad, ya está mal dimensionada: formato, transporte y reporte son tres ejes independientes que cada país fija por separado.
Qué queda fuera del ámbito
- B2C. Las facturas a consumidores no están afectadas por el mandato alemán.
- Importes pequeños. Las facturas hasta 250 euros brutos y los títulos de transporte pueden seguir sin estructurar.
- Determinadas operaciones exentas del catálogo de exenciones de la ley alemana del IVA.
- Régimen alemán de pequeños empresarios. Quienes se acogen al régimen Kleinunternehmer están exentos de emitir facturas electrónicas, pero deben poder recibirlas.
Para un SaaS B2B típico, el umbral de 250 euros es más trampa que alivio. Un plan por puesto de 49 euros al mes queda por debajo, un contrato anual no, y las mejoras en autoservicio cruzan la línea a mitad de año. Codificar "esta factura entra en el ámbito" como una regla que el sistema evalúa por documento es mejor que dejarlo como política en una wiki.
¿Sistema de facturación con plazo en 2027 y sin responsable?
Dimensionar el proyectoPor qué un PDF no es una factura electrónica
EN 16931 no describe un documento. Describe un modelo semántico de datos: una lista de términos de negocio como el identificador de IVA del vendedor, el importe neto de la línea, el código de categoría de IVA y la fecha de vencimiento, cada uno con una cardinalidad definida y un conjunto de reglas de negocio que deben cumplirse. Un archivo es una factura electrónica cuando lleva ese modelo en una de las dos sintaxis XML permitidas, UBL o UN/CEFACT CII, y supera las reglas.
Un PDF lleva píxeles y, como mucho, una capa de texto. Una máquina no puede saber con fiabilidad si el "19%" de la línea cuatro es un tipo impositivo, un descuento o parte del nombre de un producto. En eso consiste toda la distinción. "Legible por máquina" en sentido legal significa que el sistema receptor puede extraer cada campo obligatorio de forma determinista, sin heurísticas y sin un LLM adivinando.
| Formato | Qué es | Cuándo debería elegirlo un SaaS |
|---|---|---|
| XRechnung | XML puro, una restricción nacional alemana de EN 16931. Sin capa legible por humanos. | Compradores del sector público y clientes empresa cuyo sistema de cuentas a pagar lo pide por su nombre. |
| ZUGFeRD / Factur-X | Un PDF/A-3 con el XML CII incrustado. Un archivo, dos públicos. | La opción por defecto pragmática para un producto B2B de autoservicio, porque la persona sigue viendo una factura. |
| Peppol BIS Billing 3.0 | Un perfil UBL más una red de entrega con direccionamiento y acuses. | Ventas a Bélgica, los países nórdicos, Singapur, Australia o cualquier comprador que te dé un identificador Peppol. |
Fija el paquete de validación por destino y perfil. KoSIT mantiene XRechnung 3.0 en vigor al menos hasta el 31 de julio de 2027. El paquete de correcciones 3.0.2 del verano de 2026 incluye el validador 1.6.3. XRechnung 4.0 es un borrador. Para los archivos híbridos, FeRD publica ZUGFeRD 2.5.2 / Factur-X 1.09.2. Guarda las versiones del validador, las reglas y el perfil junto con el resultado.
Dos detalles de implementación cuestan una versión cada uno cuando aparecen tarde. Primero, no todos los perfiles de ZUGFeRD sirven: los perfiles MINIMUM y BASIC WL no llevan líneas de factura y por tanto no cumplen el requisito alemán, así que un valor por defecto de MINIMUM en la librería genera un archivo que parece conforme y no lo es. Segundo, en un archivo híbrido la parte estructurada es el original vinculante. Si el XML dice 1.190,00 euros y el PDF renderizado dice 1.180,00 euros, gana el XML y el sistema de tu cliente contabiliza el XML. Renderizar el PDF desde la misma estructura de datos que produjo el XML, en lugar de desde una plantilla paralela, es la única forma fiable de evitar esa clase de defecto.
¿Aplica el mandato alemán a un SaaS austriaco, suizo o estadounidense?
Normalmente no, y este es el punto peor leído de todo el tema.
Para aplicar la norma alemana, comprueba dónde están establecidas las partes para esa operación. Un establecimiento alemán a efectos del IVA cuenta si participa en la operación.
Tres matices impiden que eso sea una excusa para no hacer nada:
- Una entidad alemana o un establecimiento que participe en la operación puede incluirla en el ámbito.
- Recibir es distinto de emitir. Si tienes una entidad alemana, ya debe poder procesar facturas de proveedores estructuradas. Eso es un problema de cuentas a pagar e integración, no de facturación de producto.
- Tus clientes lo pedirán igual. Cuando el área de cuentas a pagar de un comprador alemán funciona con entrada estructurada, el PDF de un proveedor extranjero se convierte en la excepción que gestiona una persona, que se reclama y que se paga tarde. No estar estructurado cuesta comercialmente mucho antes de costar legalmente.
La misma lógica funciona al revés si vendes a Francia o Bélgica, donde lo exigido es pertenecer a una red, no un formato de archivo. Muchos de nuestros clientes facturan desde Austria hacia Alemania y más allá, que es justo la situación donde la respuesta legal y la práctica divergen. La versión amplia de este patrón la contamos en cómo se apilan el RGPD y la Ley de IA en un SaaS de DACH.
Qué te da Stripe y qué no
Stripe es muy bueno en lo que cubre. La brecha es concreta y conviene nombrarla con precisión en lugar de convertirla en una queja sobre la plataforma.
| Capacidad | Stripe hoy | Qué necesita un stack listo para 2027 |
|---|---|---|
| Documento de factura | PDF alojado y página HTML | XML EN 16931, autónomo o incrustado en el PDF |
| Factura electrónica estructurada | No se genera de forma nativa; los socios del App Marketplace cubren el hueco | Un generador bajo tu control, validado antes de salir |
| Determinación fiscal | Stripe Tax calcula tipos y gestiona registros | Ese resultado mapeado a los códigos de categoría de IVA y motivos de exención de EN 16931 |
| Numeración | Secuencial por cuenta, prefijos configurables | Numeración que sobrevive a abonos, reintentos y estructuras multientidad, con huecos explicables |
| Correcciones | Anulación, nota de crédito, reembolso | Un mapeo documentado de cada evento de Stripe a un documento de corrección legalmente correcto |
| Conservación | Acceso por API a los objetos de factura | Un archivo inalterable del original estructurado durante el plazo legal, bajo tu control |
| Transporte | Correo electrónico y enlace alojado | Correo, Peppol o una plataforma acreditada, elegido por país de destino |
Nada en esa tabla es un argumento contra Stripe. Es un argumento contra dar por hecho que la pasarela de pago es el sistema maestro para el cumplimiento. Pagos y facturación son dos productos que comparten base de datos por casualidad.
El formato es la parte pequeña: cuatro sistemas que ningún conversor construye por ti
1. Determinación fiscal mapeada a los campos de EN 16931
Tu motor de facturación ya decide entre tipo general, tipo reducido, inversión del sujeto pasivo, entrega intracomunitaria y régimen de ventanilla única. EN 16931 exige que esa decisión se exprese como categoría de IVA codificada, tipo, base imponible y, para todo lo que no tribute al tipo general, un motivo de exención legible por máquina. Un conversor recibe lo que tu sistema le entrega. Si aguas arriba la decisión es una nota en texto libre que dice "inversión del sujeto pasivo", el resultado es una factura estructuralmente válida con una posición fiscal equivocada, que es el peor de los dos desenlaces: pasa la validación y suspende la inspección.
2. Datos maestros del comprador e identificadores de enrutamiento
Una factura estructurada necesita un comprador real: denominación social, domicilio registrado, número de identificación a efectos de IVA y, para muchos clientes empresa y públicos, un identificador de enrutamiento como un Leitweg-ID o un identificador Peppol. Los formularios de alta en autoservicio no recogen nada de eso con fiabilidad. Los equipos descubren al salir a producción que una parte considerable de sus registros B2B tiene un nombre de persona en el campo de empresa y un número de IVA sin verificar. Validar los números de IVA en el checkout y hacer obligatorio el identificador de enrutamiento en los planes empresa es un cambio de dos semanas hoy y un proyecto de migración de datos en diciembre de 2026.
3. Un archivo inalterable del original estructurado
El XML es el original legal, así que el XML es lo que hay que conservar, sin modificar y legible por máquina, durante el plazo legal. Según el artículo 14b de la UStG, el plazo de ocho años a efectos del IVA se cuenta desde el cierre del año natural de emisión. "Está en Stripe" no es un archivo: es una API de un tercero cuyo ciclo de vida no controlas. Un patrón que funciona es almacenamiento de objetos con versionado y política de bloqueo de retención, un hash de contenido registrado al escribir y un índice que relacione número de factura con clave de almacenamiento. Junto a ello necesitas una descripción escrita del proceso que cubra cómo se crean, validan, envían, almacenan y corrigen las facturas. Los inspectores leen ese documento antes que tu código.
4. El ciclo de vida de las correcciones
Conserva el original y vincula cualquier rectificación a él. Cuando la factura electrónica sea obligatoria, emite la rectificación como factura estructurada del tipo correspondiente. Un cambio de la base imponible puede requerir un tratamiento distinto de corregir datos erróneos de la factura.
La carta del BMF de 2025 convirtió la validación en requisito de la pipeline
La segunda carta de aplicación del ministerio de finanzas alemán, de 15 de octubre de 2025, clasifica los defectos de una factura electrónica en tres clases. Para un equipo de ingeniería esto se lee menos como orientación fiscal y más como la especificación de una puerta de validación.
| Clase de error | Qué significa | Consecuencia |
|---|---|---|
| Error de formato | El archivo es sintácticamente inválido, o los campos obligatorios no se pueden extraer por completo. | No es una factura electrónica en absoluto. Cuenta como factura ordinaria, lo que tras el plazo significa obligación incumplida. |
| Error de regla de negocio | La sintaxis se sostiene pero se incumple una regla de negocio de EN 16931. | Sigue siendo factura electrónica, pero defectuosa y pendiente de corrección. |
| Error de contenido | El contenido con relevancia fiscal es incorrecto: tipo, descripción del servicio, fecha de la operación. | La deducción del IVA soportado del destinatario queda en riesgo. |
La implicación técnica es directa. Valida cada documento contra las reglas de negocio de EN 16931 antes de enviarlo, bloquea ante errores de formato y de regla de negocio, y envía los errores de contenido a una cola humana porque ningún validador los detecta. Tratar la validación como una puerta de salida y no como un panel de monitorización es la diferencia entre un defecto capturado en una cola y un defecto descubierto por el departamento fiscal de tu cliente. Es la misma disciplina que aplicamos en un encargo de aseguramiento de calidad de software: la comprobación va en el camino, no al lado.
"Los equipos presupuestan el XML y les sorprenden el archivo y las notas de crédito. El formato es una llamada a una librería. El ciclo de correcciones es una máquina de estados que alguien tiene que sostener durante ocho años."
Una arquitectura de referencia para un stack de facturación sobre Stripe
- Eventos de facturación. Consume los webhooks de Stripe en tu propio registro de eventos duradero. Nunca trates a la pasarela como fuente de verdad de los registros contables.
- Modelo de datos de factura. Proyecta esos eventos sobre una entidad de factura normalizada que contenga de forma explícita cada término obligatorio de EN 16931, incluidos los identificadores del comprador y el tratamiento fiscal codificado. Ese modelo, y no el PDF, es tu entregable real.
- Numeración e inalterabilidad. Asigna el número de factura en el momento en que el documento se vuelve definitivo, desde un único escritor, y haz el registro solo de adición a partir de ahí.
- Renderizado. Genera el XML y la versión legible por humanos desde el mismo modelo en un solo paso, para que no puedan divergir.
- Puerta de validación. Ejecuta validación de esquema más reglas de negocio. Bloquea si falla. Guarda el resultado junto al documento.
- Transporte. Elige el canal por destino: adjunto de correo para Alemania, un punto de acceso Peppol para Bélgica y los países nórdicos, una plataforma acreditada para Francia. Mantén el transporte detrás de una interfaz para que un país nuevo sea un adaptador nuevo y no una base de código nueva.
- Archivo y conciliación. Escribe el original estructurado en almacenamiento bloqueado con su hash y concilia el archivo contra el libro mayor de forma periódica. Un archivo que nadie concilia es una suposición, no un control.
Alrededor de una cuarta parte de esa lista se compra hecha. El resto es tu modelo de dominio, y ahí es donde se acumula la deuda técnica cuando el trabajo se corre contra un plazo legal.
Construir, comprar o acoplar
| Opción | Encaja cuando | Qué te sigue quedando |
|---|---|---|
| Socio del Stripe App Marketplace | Volumen bajo de facturas, un país, tratamiento fiscal estándar, facturas creadas en el propio Stripe | Calidad de datos maestros, propiedad del archivo, mapeo de correcciones |
| SaaS de facturación electrónica con API | Varios países, volumen medio, quieres formato y transporte resueltos juntos | La capa de mapeo de tu modelo de dominio a su esquema, más dependencia de proveedor en una ruta regulada |
| Proveedor de punto de acceso Peppol | Países con mandato de red, clientes empresa con identificador de participante | Generación de formato y todo lo anterior al transporte |
| Construir la capa de facturación en casa | La lógica de facturación ya es un diferenciador: precios por uso, marketplaces, pagos divididos, grupos multientidad | Trabajo continuo de conformidad conforme evolucionan EN 16931 y los perfiles nacionales |
La opción honesta por defecto para la mayoría de empresas SaaS B2B es un híbrido: comprar la generación de formato y el transporte, y construir el modelo de datos de factura, la puerta de validación y el archivo. Ese reparto sigue el mismo razonamiento que cualquier otra decisión entre software a medida y solución estándar. Compra lo que es commodity, posee aquello que tu lógica de negocio toca de verdad. Cuando llevamos la plataforma institucional de analítica de bonos de cero a nivel empresa, se cumplió el mismo principio: un resultado regulado solo es tan fiable como el modelo que lo produce.
Ocho modos de fallo que vemos en pipelines de facturación
- Dos fuentes de verdad. El PDF se renderiza desde una plantilla mientras el XML se construye desde la base de datos. Divergen en una sola versión.
- Perfil MINIMUM por defecto. Un valor por defecto de la librería produce un archivo que valida como ZUGFeRD e incumple el requisito legal.
- Redondeo en el nivel equivocado. Las reglas de EN 16931 comprueban que los totales de línea, los subtotales de impuesto y el total del documento cuadren. Redondear distinto por línea y por documento rompe las reglas.
- Tipos de IVA mezclados en un documento. Un paquete con una licencia al 19% y un artículo al 7% necesita subtotales correctos por categoría, no un tipo promediado.
- Datos de comprador sin validar. Números de IVA ausentes y nombres de persona en el campo de empresa, descubiertos al salir a producción.
- Borrar en lugar de anular. Un flujo de soporte que elimina una factura errónea destruye el rastro de auditoría que exige la inalterabilidad.
- Datos de prueba en la numeración productiva. Una prueba de carga que quema 4.000 números de factura deja un hueco que nadie sabrá explicar tres años después.
- Sin validación de salida. Los errores afloran en el sistema de cuentas a pagar del cliente, el detector más caro posible.
Un plan de 90 días
- Semanas 1 y 2, alcance. Determina por entidad legal si estás dentro de la obligación de emitir y por segmento de cliente si aplica la exención de importe reducido. El resultado es una decisión de una página, no un memorándum.
- Semanas 3 y 4, auditoría de datos. Mide cuántos registros de clientes B2B llevan un número de IVA validado, una denominación social y una dirección completa. Ese número decide tu calendario más que cualquier elección técnica.
- Semanas 5 a 7, modelo y mapeo. Define la entidad de factura, mapea cada tipo de evento de Stripe a un documento de factura o corrección y mapea tu lógica fiscal a los códigos de categoría de EN 16931.
- Semanas 8 a 10, generar y validar. Produce ZUGFeRD desde el modelo, conecta la puerta de validación y pasa los últimos doce meses de facturas como backtest. La tasa de fallo sobre datos históricos es tu verdadera métrica de preparación.
- Semanas 11 y 12, archivo y documentación del proceso. Levanta el almacenamiento bloqueado con hashing y conciliación, y escribe la documentación del proceso mientras las decisiones están frescas.
- Después, transporte por país. Añade Peppol o una plataforma acreditada solo para los mercados que lo exijan.
Doce semanas asumen que alguien es dueño de las decisiones. Cuando ese responsable no existe, el trabajo se atasca en la semana tres, y ese es un motivo habitual por el que las empresas incorporan un CTO fraccional para un programa regulatorio acotado en lugar de contratar para ello.
Cuatro mitos que conviene corregir
- "Los números de factura deben ir sin huecos." La ley alemana del IVA exige un número correlativo asignado una sola vez para identificar la factura. Una serie sin huecos no es obligatoria por ley. Los huecos sí llaman la atención en una inspección, así que documenta por qué existen.
- "Un PDF con XML dentro es un apaño." ZUGFeRD es un formato conforme de pleno derecho. El contenedor PDF no es el problema; un PDF sin los datos estructurados sí lo es.
- "Para Alemania necesitamos Peppol." Alemania prescribe el formato, no el canal. El correo electrónico basta. Peppol se vuelve necesario por a quién vendes, no por la ley alemana.
- "Nuestro software contable ya lo hace." Hace las facturas que él mismo crea. Las facturas que crea tu producto, en tu motor de facturación, sobre tu propia serie de numeración, son tuyas.
Preguntas frecuentes sobre Stripe y factura electrónica
¿Puede Stripe enviar una factura XRechnung o ZUGFeRD?
¿Sigue siendo legal una factura en PDF en Alemania después de 2027?
¿Debe una empresa austriaca o suiza emitir facturas electrónicas alemanas?
¿Qué formato debería elegir un SaaS B2B?
¿Valen los perfiles MINIMUM y BASIC WL de ZUGFeRD?
¿Es el correo electrónico una vía válida de entrega en Alemania?
¿Cuánto tiempo hay que conservar las facturas electrónicas?
¿Cuánto esfuerzo de ingeniería supone?
Reflexiones finales
Stripe es una pasarela de pago con una función cómoda de facturación, no un sistema maestro de cumplimiento, y así lo dice. Trata el plazo de 2027 por lo que es: la ocasión para dar a tu dominio de facturación un modelo de datos real, una puerta de validación, un archivo bajo tu control y un ciclo de correcciones con dueño. Compra el XML y la red. Construye el modelo. Los equipos que trabajan en ese orden acaban con un stack de facturación en el que el siguiente mandato es un cambio de adaptador y no una reescritura.
Fuentes primarias
- Ministerio Federal de Finanzas de Alemania, segunda carta de aplicación sobre la factura electrónica obligatoria, 15 de octubre de 2025
- Ministerio Federal de Finanzas de Alemania, preguntas frecuentes sobre la factura electrónica obligatoria desde el 1 de enero de 2025
- Artículo 14 de la ley alemana del IVA, emisión de facturas y numeración correlativa
- Stripe, factura electrónica obligatoria en Alemania
- Stripe, enviar facturas electrónicas mediante socios del App Marketplace
- FeRD, preguntas frecuentes de ZUGFeRD sobre versiones y perfiles
- Comisión Europea, ficha de país de facturación electrónica, Austria
- Ministerio de Economía francés, inicio de la factura electrónica B2B el 1 de septiembre de 2026
- Comisión Europea, IVA en la era digital