Stripe Billing envía PDF. Desde 2027 eso no es una factura en Alemania

Stripe Invoicing y Stripe Billing producen un PDF. La propia documentación de Stripe dice con claridad que ninguno de los dos productos puede crear ni enviar facturas electrónicas sin integrar una aplicación de facturación electrónica, y remite a los socios del App Marketplace. Para una venta B2B nacional en Alemania, ese PDF deja de cumplir la obligación de emisión el 1 de enero de 2027 para los vendedores grandes y el 1 de enero de 2028 para el resto.

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.

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.

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.

Por 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.

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.

La obligación alemana de emitir aplica a operaciones entre dos empresas ambas establecidas en Alemania, donde establecimiento significa sede, dirección efectiva o un establecimiento permanente a efectos de IVA allí. Una GmbH austriaca sin establecimiento permanente en Alemania que factura a un cliente de Berlín queda fuera de la obligación de emitir. Además, el servicio suele ser una operación con inversión del sujeto pasivo, en la que el cliente alemán liquida el IVA.

Tres matices impiden que eso sea una excusa para no hacer nada:

1. Una entidad o establecimiento alemán te mete dentro. Muchos grupos extranjeros tienen uno y olvidan que cuenta la entidad que factura, no la matriz.
2. 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.
3. 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.

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. Las facturas emitidas o recibidas desde 2025 tienen en Alemania un plazo de conservación de ocho años. "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

Aquí es donde los productos de suscripción se diferencian de los vendedores puntuales, y donde aterriza la mayor parte del esfuerzo de ingeniería. El prorrateo, los cambios de plan a mitad de ciclo, los reintentos de cobro, los reembolsos parciales, los créditos y los cambios de divisa generan eventos financieros que deben convertirse en documentos de corrección, no en ediciones. Bajo las reglas de inalterabilidad se anula y se vuelve a emitir; no se sobrescribe. Un reembolso no es automáticamente una nota de crédito, y un borrador descartado no es lo mismo que una factura anulada. Escribir ese mapeo como una máquina de estados, con una fila por tipo de evento de Stripe, es el artefacto más valioso que produce este proyecto.

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.

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

1. 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.
2. 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.
3. 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í.
4. Renderizado. Genera el XML y la versión legible por humanos desde el mismo modelo en un solo paso, para que no puedan divergir.
5. Puerta de validación. Ejecuta validación de esquema más reglas de negocio. Bloquea si falla. Guarda el resultado junto al documento.
6. 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.
7. 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

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

1. 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.
2. Perfil MINIMUM por defecto. Un valor por defecto de la librería produce un archivo que valida como ZUGFeRD e incumple el requisito legal.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

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
• Comisión Europea, ficha de país de facturación electrónica, Francia
• Comisión Europea, IVA en la era digital