Si trabajas con varias razones sociales en España, no puedes mezclar facturas, series ni registros VeriFactu entre ellas. Yo lo resumiría así: una entidad = un NIF = una serie = una cadena fiscal. Si no lo haces, puedes romper el cumplimiento y exponerte a sanciones de hasta 50.000 € por ejercicio.
Esto es lo que tengo claro después de leer el contenido:
- Stripe Billing puede seguir cobrando igual, pero la parte fiscal debe ir separada por entidad legal.
- Cada entidad necesita sus propios datos fiscales: razón social, NIF y domicilio fiscal.
- Cada serie de facturas debe ser independiente y correlativa por entidad.
- El encadenamiento SHA-256 y la firma también van por entidad, no por cuenta mezclada ni por cliente.
- Las rectificativas deben salir en su propia serie y enlazarse con la factura original.
- En Stripe Connect, cada cuenta conectada debe tratarse como una entidad distinta.
- Fechas a tener en cuenta: 01/01/2027 para contribuyentes del Impuesto sobre Sociedades y 01/07/2027 para el resto.
En otras palabras: yo no tocaría el flujo de cobro si ya funciona, pero sí separaría el circuito fiscal desde el primer registro. Ese es el punto central del artículo, y puedes verlo en acción en esta demo del conector Stripe–VeriFactu.
Comparación rápida
| Tema | Lo correcto |
|---|---|
| Unidad fiscal | Cada entidad legal por separado |
| Numeración | Por entidad, no por cliente |
| Serie rectificativa | Separada de la ordinaria |
| Hash y firma | Cadena propia por entidad |
| Stripe Connect | Cada cuenta = una entidad |
| Envío a AEAT | Desde una capa fiscal ligada a esa entidad |
Yo leería el resto del artículo como una guía para montar ese esquema sin cruzar NIF, series, pagos ni abonos entre entidades.
Flujo VeriFactu por Entidad en Stripe: Guía Visual de Cumplimiento Fiscal
1. Configura cada entidad de Stripe con la identidad fiscal correcta
Configura los datos fiscales del emisor y del cliente por entidad
Antes de enviar nada a la AEAT, cada entidad debe tener cargados los datos del emisor: razón social completa, NIF y domicilio fiscal. En las facturas completas, además, debes incluir el NIF y el nombre o razón social del cliente.
También hace falta que cada factura muestre el desglose de la base imponible, los tipos de IVA aplicados y el importe total de impuestos. Dicho de forma simple: la factura tiene que dejar claro quién emite, a quién se factura y cómo se calcula el IVA. Si aplicas retención, gestíonala fuera del cálculo estándar de Stripe.
Cierra el alta fiscal antes del primer envío
El alta fiscal de cada entidad debe estar lista antes de emitir su primer registro VeriFactu. No hay margen para dejarlo para más tarde. El registro debe crearse de forma simultánea o inmediatamente anterior a la emisión de la factura.
Las fechas clave son estas:
- 1 de enero de 2027 para contribuyentes del Impuesto de Sociedades
- 1 de julio de 2027 para el resto de empresas y autónomos
Ninguna entidad debería emitir su primer registro sin haber cerrado antes el alta fiscal.
Una vez hecho ese trámite en cada entidad, ya puedes pasar a la automatización del envío de registros.
Conecta cada entidad a un sistema que genere y presente automáticamente sus registros VeriFactu
Cuando los datos fiscales ya estén validados, conecta cada entidad a una capa que genere, firme y envíe los registros VeriFactu de forma automática. El Stripe Verifactu Connector de itcons.app/conector-stripe recoge los datos de factura y pago de cada entidad, firma y presenta los registros por cuenta de cada entidad ante la AEAT, y genera un PDF de factura conforme con el código QR correspondiente.
Si los correos nativos de Stripe no incluyen el QR ni el encadenamiento exigidos, conviene desactivarlos.
Con la identidad fiscal ya cerrada, el paso siguiente es definir las series y la numeración de cada entidad.
sbb-itb-b01fb3c
2. Define las series de facturas, la numeración y la lógica de firma por entidad
Crea series de facturas separadas para cada entidad legal
Cada entidad legal debe trabajar con su propia serie independiente. En Stripe, lo más claro es usar un prefijo distinto por entidad, por ejemplo ENTIDAD-A-2026-. Así, cada factura queda ligada sin dudas a su emisor y resulta mucho más fácil cuadrarla con los libros contables y los registros fiscales.
El fallo más común es mezclar varias entidades dentro de una sola serie. Parece un atajo, pero acaba siendo un problema: se pierde trazabilidad y la conciliación contable se complica bastante.
Ahora bien, la serie por sí sola no basta. Para que el sistema tenga sentido, la firma y el encadenamiento también deben mantenerse por entidad.
Define la firma según la modalidad
Tanto en VERI*FACTU como en no VERI*FACTU, la cadena SHA-256 debe mantenerse por entidad. La diferencia no está en eso, sino en cómo se guarda la prueba.
| Aspecto | Modalidad VERI*FACTU | Modalidad no VERI*FACTU |
|---|---|---|
| Envío | Transmisión automática en tiempo real a la AEAT | Registros almacenados localmente; sin envío inmediato |
| Prueba de integridad | El propio envío garantiza la integridad | Firmas digitales y huellas encadenadas obligatorias |
| Texto en la factura | «Factura verificable en la sede electrónica de la AEAT» | No puede incluir la mención «verificable» |
Stripe no gestiona el hash ni la firma por entidad, así que esa parte debes resolverla en la capa fiscal.
Con eso claro, la decisión de fondo pasa a ser otra: cómo encadenas y firmas cada secuencia.
Comparativa: numeración por entidad vs. numeración por cliente
Aquí no hay mucho margen. Si facturas en España, la numeración por entidad es la vía correcta.
| Aspecto | Por entidad (recomendado) | Por cliente (no recomendado) |
|---|---|---|
| Ámbito de la secuencia | Una sola secuencia para toda la entidad legal | Secuencias independientes por cliente |
| Conciliación contable | Sencilla; se corresponde directamente con los libros oficiales | Muy difícil; hay que fusionar múltiples líneas para los modelos fiscales |
| Compatibilidad legal | Recomendado para la facturación fiscal española | No cumple la correlatividad exigida por emisor |
Dicho de forma simple: numerar por cliente puede sonar ordenado sobre el papel, pero en la práctica te mete en un lío. La contabilidad no se apoya en secuencias por cliente, sino en la correlatividad del emisor.
Con la numeración ya cerrada, el siguiente paso es reflejar rectificativas, abonos y devoluciones sin salir de la misma entidad.
3. Gestiona las facturas rectificativas, los abonos y la trazabilidad del pago correctamente
Relaciona las facturas rectificativas españolas con los abonos de Stripe
Con la serie ordinaria ya definida, las rectificativas necesitan su propia secuencia y una referencia clara a la factura original. En España, cualquier cambio en una factura ya emitida obliga a sacar una factura rectificativa. Pasa, por ejemplo, si hay errores en el tipo de IVA, devoluciones parciales o totales, o descuentos aplicados después.
En Stripe, CreditNote debe pasar a ser una rectificativa fiscal válida: firmada, encadenada y enviada a la AEAT con su QR.
Conviene usar una serie rectificativa separada de la ordinaria, por entidad. Un prefijo como R-2026- deja claro, de un vistazo, que ese documento no forma parte de la numeración habitual. Además, cada rectificativa debe incluir la referencia de la factura original: número, fecha y motivo. Si corrige una devolución, el IVA se registra en negativo.
Vincula factura, pago, devolución y abono dentro de la misma entidad
Si quieres mantener la trazabilidad sin grietas, todos los objetos de la operación deben quedarse dentro de la misma cuenta de Stripe asociada al NIF de la entidad emisora.
Cuando hay una devolución, Stripe genera el evento charge.refunded. Ese evento debe activar de forma automática la creación de la factura rectificativa en el sistema certificado, enlazada al Invoice original mediante su ID. También conviene guardar Invoice ID y PaymentIntent ID en los metadatos.
En Connect, cada rectificativa debe generarse desde la cuenta que emitió la factura original. Esa separación no es un simple detalle técnico: evita que se rompa la trazabilidad entre entidades.
Comparativa: factura ordinaria vs. factura rectificativa
En la práctica, la diferencia clave está en cómo corrige y cómo se enlaza con el documento original.
| Aspecto | Factura ordinaria | Factura rectificativa |
|---|---|---|
| Finalidad | Documentar una venta o servicio | Corregir un error o modificar una factura ya emitida |
| Objeto en Stripe | Invoice | CreditNote |
| Relación con el original | Independiente | Debe referenciar la factura original |
| Serie | Serie ordinaria por entidad | Serie rectificativa separada por entidad |
Con la trazabilidad ya cerrada, el siguiente paso es automatizar el flujo de emisión y validación por entidad.
El Stripe Verifactu Connector automatiza la devolución: captura el evento en Stripe, genera la rectificativa, la firma, la encadena y la envía a la AEAT con PDF y QR.
4. Construye el flujo de envío por entidad y las comprobaciones finales
Flujo paso a paso desde la emisión hasta el envío
Con la factura, el pago y la rectificativa ya unidos por entidad, el siguiente paso es mandar cada registro al circuito fiscal que le toca. Después de definir series, rectificativas y la relación entre pago e Invoice, falta automatizar el envío sin cruzar entidades.
El flujo es el mismo en cada entidad (similar al proceso del Conector Stripe TicketBai):
- Captura y generación: el conector toma los datos de la cuenta de Stripe de esa entidad y genera el RRSIF.
- Encadenamiento y firma: el sistema encadena y firma el registro de esa entidad.
- Envío a la AEAT: el registro firmado se remite de forma automática por la API SOAP de la AEAT. El sistema registra incidencias y vuelve a intentar el envío.
- PDF con QR y entrega: se genera el PDF con QR y la mención «VERI*FACTU», y se envía al cliente. Desactiva los correos automáticos de Stripe para evitar duplicados.
- Registro interno: el estado del envío y el código de registro VeriFactu quedan guardados y vinculados a la
Invoicede Stripe.
Controles para suscripciones, ecommerce y Stripe Connect
Ese mismo esquema solo cambia en la fuente del evento, no en la lógica fiscal. Se adapta a tres casos muy comunes:
- Suscripciones: cada renovación genera un nuevo registro que mantiene la cadena de esa entidad.
- Ecommerce: separa series por entidad para evitar que un pago active una factura de otra.
- Stripe Connect: trata cada cuenta conectada como una entidad independiente.
Conclusión: la configuración mínima por entidad
La configuración mínima por entidad es: NIF, razón social, domicilio fiscal, series separadas y el conector apuntando solo a esa cuenta de Stripe.
El Stripe Verifactu Connector automatiza la captura, la firma, el envío a la AEAT y el PDF con QR sin cambiar tu flujo de cobro.
La regla sigue siendo la misma: una entidad, una serie, una cuenta y una cadena fiscal. Si cada entidad mantiene su propio circuito, el cumplimiento queda automatizado y auditable.
VeriFactu: Guía Completa para Adaptar tu Software de Facturación a la Ley Antifraude AEAT
FAQs
¿Puedo usar una sola serie para varias entidades?
No. Cada obligado tributario debe llevar sus registros de facturación por separado, con su propia numeración correlativa ligada a su identidad fiscal.
Si gestionas varias entidades legales, no pueden compartir serie. Si lo hicieran, se rompería la trazabilidad fiscal ante la AEAT.
¿Qué pasa si una devolución afecta a una factura ya enviada?
Si una devolución afecta a una factura ya emitida en Stripe, tienes que generar una factura rectificativa para cumplir con VeriFactu.
Esa rectificativa debe firmarse digitalmente, quedar encadenada al hash de la factura original y enviarse a la AEAT. Si tienes el flujo automatizado, el reembolso en Stripe activa ese registro y deja el cambio documentado y comunicado sin trabajo manual.
¿Cuándo debo tener lista el alta fiscal de cada entidad?
Debe estar lista antes de la entrada en vigor: 1 de enero de 2027 para los contribuyentes del impuesto sobre sociedades y 1 de julio de 2027 para el resto de empresas y autónomos.
Aunque la obligación arranca en esas fechas, la Agencia Tributaria recomienda adoptarlo antes para ir cogiéndole el truco al proceso, ya que su uso es válido desde ahora.
