Una tienda online entra en el RRSIF cuando el vendedor incluido utiliza el ecommerce o una integración como sistema para expedir facturas completas o simplificadas. El canal digital no crea una excepción. Lo que complica la implantación es que pedido, pago, preparación, envío y factura suelen vivir en aplicaciones diferentes.
El proyecto debe contestar tres preguntas antes de instalar un plugin: quién es el vendedor, en qué evento se expide la factura y qué componente asigna serie y número. Si dos módulos responden a la tercera, es probable que el negocio esté duplicando o pueda duplicar facturas.
Antes de activar un plugin hay que decidir si la factura nace en la tienda, el ERP o el marketplace y desactivar los demás emisores para evitar duplicados.
Pedido, pago y factura no son lo mismo
Una confirmación de pedido acredita que la tienda recibió una orden. Un cargo de la pasarela acredita el pago. Un albarán acompaña la entrega. Ninguno tiene que ser por sí mismo la factura. El sistema debe decidir cuándo se expide conforme al Reglamento de facturación y a la operación.
En algunos negocios la factura nace al confirmar el pago; en otros, al enviar. Los anticipos pueden exigir documentación antes de la entrega. La configuración debe responder al criterio fiscal aprobado, no a la opción predeterminada del plugin.
Conviene anotar el estado que genera la factura. Prueba cambios manuales y automáticos. Un webhook repetido no debe crear otro número. Si el pago falla después de reservar número, define qué ocurre sin rellenar huecos con facturas ficticias.
La implantación debe fijar un único evento de expedición, generar el registro en ese punto y mantener el vínculo entre pedido, pago, factura, envío y eventual rectificación. Ese vínculo permite atender devoluciones y conciliaciones sin buscar a mano.
El RRSIF define el SIF por sus funciones de entrada, conservación y procesamiento de información de facturación, aunque estén repartidas entre varios componentes de hardware o software. Fuente oficial.
Una arquitectura habitual reúne tienda, plugin fiscal, ERP, pasarela, gestor de pedidos y servicio que envía PDFs. Dibuja las llamadas y bases de datos. Identifica quién conserva el original, quién puede rectificar y qué sistema crea el registro RRSIF.
Pide declaraciones responsables de la solución y ampliaciones. La Orden HAC/1177/2024 prevé componentes producidos por distintas entidades. Una declaración del ERP no cubre automáticamente un plugin que altera numeración o registros.
Es útil revisar trabajos programados. Muchas tiendas generan facturas en lote. Un proceso nocturno forma parte del circuito y necesita control de errores, reintentos y versión.
Marketplace: identifica al vendedor
Un marketplace puede vender en nombre propio, intermediar o prestar servicios logísticos. Mira contrato, ficha pública y factura. No presupongas que la plataforma es el vendedor porque cobra al cliente.
Si tu empresa es el vendedor, conserva la responsabilidad de facturación aunque la plataforma expida materialmente por delegación. Fuente oficial. Documenta el acuerdo, serie, entrega de registros, respuestas y correcciones. Si la plataforma es revendedora, tu factura puede dirigirse a ella y seguir otro circuito.
En una cuenta puede haber ventas de varios NIF. Sepáralos. Cada emisor tiene calendario, SII y territorio. No uses una serie compartida por comodidad.
Las liquidaciones de comisiones no son facturas al consumidor. Concilia venta bruta, impuestos, comisión, devoluciones y neto. El registro de facturación debe corresponder a la factura, no al ingreso bancario neto.
El checkout debe preguntar solo los datos necesarios, pero permitir factura completa cuando corresponda. Distingue consumidor, empresa y Administración. Valida identificadores sin rechazar formatos extranjeros legítimos.
El RRSIF afecta tanto a las facturas completas como a las simplificadas expedidas por el sistema. Fuente oficial. Si después el cliente pide completa, aplica el procedimiento que evite duplicar la venta y conserva relación con el documento inicial.
No uses el número de pedido como serie fiscal salvo que cumpla el diseño y esté controlado. Mantén identificadores distintos y enlazados. Así soporte puede hablar en términos de pedido y fiscalidad en términos de factura.
Protege el cambio de datos después de expedir. El cliente puede actualizar su perfil, pero la factura histórica no debe reescribirse. Una corrección requiere el mecanismo fiscal apropiado.
Devoluciones, cancelaciones y contracargos
Una cancelación antes de expedir no se trata igual que una devolución posterior. Define estados y acciones. Si ya existe factura, no la borres. Genera rectificación cuando proceda y vincúlala.
Vale la pena probar devolución parcial de un pedido con varios tipos de IVA, devolución de gastos de envío, cupón distribuido y cambio de producto. El cálculo debe conservar redondeos. Compara con una hoja independiente.
Un contracargo de tarjeta no convierte automáticamente la venta en inexistente. Revisa causa y documentación. El sistema de pagos no debe emitir abono fiscal por cualquier disputa sin aprobación.
En marketplaces, la plataforma puede iniciar reembolso sin avisar al ERP. Implementa una cola de eventos y una conciliación. Ninguna devolución debe quedarse solo en el banco.
Las suscripciones crean facturas automáticamente y pueden operar de madrugada. Prueba renovación, prorrateo, cambio de plan, pausa, impago y reintento. Define cuándo nace la factura si el cobro falla.
El motor de suscripciones puede ser otro emisor oculto. Si crea el PDF y la numeración, intégralo en la declaración y en las pruebas. Evita que el ERP genere otra factura al recibir el pago.
Revisa fechas y zonas horarias. Un cargo a medianoche UTC puede caer en otro día local. La fecha fiscal debe seguir el criterio correcto y ser estable entre sistemas.
Los descuentos iniciales y periodos gratuitos necesitan conceptos claros. No generes facturas de importe cero sin saber por qué y cómo se tratan.
Ventas internacionales
La OSS comprende regímenes opcionales de IVA para determinadas ventas a distancia y prestaciones B2C. Fuente oficial. Analiza por separado OSS, aduanas, facturación y RRSIF: el SIF registra el resultado fiscal configurado, pero no clasifica jurídicamente el destino.
Puede ser práctico separar B2C y B2B, territorio, bienes y servicios. Configura tipos y exenciones con asesoramiento. Guarda evidencia de localización cuando sea necesaria. Revisa cambios de umbrales o regímenes en fuentes vigentes.
Prueba direcciones sin provincia española, identificadores comunitarios, Islas Canarias, Ceuta, Melilla y terceros países. No obligues a elegir “España” para completar el checkout. Comprueba moneda y conversión.
Si la plataforma recauda impuestos en ciertos mercados, documenta quién es responsable y cómo aparece en la factura. No sumes dos veces el tributo por una integración paralela.
VERI*FACTU remite a la AEAT los registros de facturación de manera continuada, automática y consecutiva. Fuente oficial. La modalidad no verificable los conserva con controles adicionales. Fuente oficial. Compara volumen de pedidos, conectividad, soporte y capacidad técnica.
La respuesta de la AEAT identifica la aceptación o el rechazo y, en este último caso, informa del código de error. Fuente oficial. Cuando una incidencia técnica impide remitir, el sistema debe realizar el envío posterior en cuanto sea posible y respetar el orden temporal. Fuente oficial. El backoffice debería mostrar colas y permitir actuar.
Resulta sensato diseñar alertas con contexto: tienda, NIF, factura, error y próximo intento. No envíes solo un correo genérico. Define escalado y registro de resolución.
En modalidad no verificable, prueba exportación, firma, eventos y recuperación. No la elijas únicamente para evitar desarrollar un conector.
Calendario por forma jurídica
Las sociedades sujetas al IS deben adaptar antes del 1 de enero de 2027 y el resto de obligados del artículo 3.1, incluidos autónomos, antes del 1 de julio de 2027. Fuente oficial.
Un mismo software puede alojar tiendas de ambos colectivos. Configura fechas por vendedor, no por plataforma. La sociedad no puede esperar a julio porque su autónomo asociado comparta plugin.
Programa la migración fuera de campañas. Clona un entorno con datos anonimizados y reproduce volumen. Prueba colas y límites. Haz un despliegue gradual si la arquitectura lo permite.
A menudo ayuda coordinar cambios con actualizaciones de plataforma. Un salto mayor de versión al mismo tiempo complica aislar fallos. Reserva rollback técnico sin volver a expedir facturas ya creadas.
Ejecuta pedido ordinario, invitado, empresa, extranjero, cupón, gastos, anticipo, suscripción, devolución y contracargo. Sigue cada uno desde checkout hasta contabilidad. Compara factura y registro.
Repite con fallo de pasarela, webhook duplicado, caída de AEAT, timeout del ERP y reintento. Confirma idempotencia: el mismo evento no crea otra factura. Verifica que el orden de registros se conserva.
Examina QR en móvil y PDF. Comprueba correos y área de cliente. Una factura corregida debe mostrar el documento vigente sin ocultar el original.
Mide la conciliación. Suma ventas, impuestos, devoluciones, comisiones y cobros. Las diferencias deben explicarse por eventos conocidos, no por ajustes manuales.
Seguridad, accesos y conservación
Una opción razonable es limitar quién puede cambiar series, NIF, impuestos y evento de expedición. Activa registro de cambios en la plataforma. Revisa cuentas de agencias y plugins antiguos.
Conserva datos conforme a obligaciones y protección de datos. Evita copiar facturas completas a herramientas de soporte sin necesidad. Usa referencias seguras.
Exporta facturas, registros y declaración responsable. Prueba restauración. Un backup del proveedor sin prueba no garantiza acceso si termina el contrato.
Es útil documentar versiones de tienda, plugin, ERP y conectores. Una actualización de cualquiera puede afectar facturación. Repite pruebas críticas.
Antes del corte, exporta pedidos, clientes, facturas, abonos y series. No importes pedidos antiguos como si fueran nuevos: el nuevo sistema podría volver a facturarlos. Usa un marcador de migración y prueba con una copia.
Decide dónde se consultan facturas históricas. Puede mantenerse la tienda antigua en modo lectura o importarse la documentación, pero debe conservarse el original. Verifica enlaces del área de cliente y evita que desaparezcan al cambiar de plataforma.
Concilia el último número de cada serie y el primero nuevo. Si se abre serie por el cambio, documenta. Los pedidos pendientes en la fecha de corte necesitan una regla: cuál sistema los factura y cómo se evita el doble evento.
Haz el corte con pocos pedidos y personal disponible. Revisa manualmente las primeras facturas, registros y cobros. No desactives el antiguo hasta confirmar exportación y acceso.
Catálogo e impuestos
Cada producto o servicio debe tener tipo, descripción y regla territorial correctos. Revisa variantes, packs, productos digitales, tarjetas regalo y gastos. Una categoría comercial no siempre coincide con un tratamiento tributario.
Vale la pena evitar permitir a marketing cambiar impuestos sin revisión. Define flujo de alta de producto. Prueba precios con IVA incluido y excluido; la tienda debe calcular base y redondeo de forma coherente con factura.
Los cupones fijos y porcentuales pueden distribuirse entre líneas. Ejecuta pedidos con tipos distintos y devuelve una línea. Compara cálculo. Un redondeo erróneo se multiplica con volumen.
Mantén un informe de productos sin regla fiscal o con configuración por defecto. Bloquea publicación cuando falten datos necesarios.
Un pedido marcado como fraude antes de factura debe cancelarse sin crear documento. Si la detección llega después, el equipo fiscal decide el tratamiento. No conectes el motor antifraude directamente a abonos sin control.
Los agentes crean pedidos manuales, aplican descuentos y cambian direcciones. Limita permisos y registra. Prueba ese canal, porque puede saltarse validaciones del checkout.
Soporte debe distinguir reenvío de factura, duplicado y rectificación. Reenviar el PDF no crea otra factura. Cambiar datos fiscales sí puede requerir actuación. Entrena con casos y no con definiciones abstractas.
Los pedidos de prueba internos no deben mezclarse con producción. Usa entorno separado. Si se hace una compra real de verificación, trátala como operación real y corrígela conforme al procedimiento.
Observabilidad técnica
Registra un identificador común en tienda, cola, ERP y respuesta. Permite seguir un caso sin exponer datos personales en logs. Conserva estados, tiempos y error.
Puede ser práctico configurar alertas por cola creciente, rechazos y ausencia inusual de facturas. Una tienda que vende pero no genera registros durante una hora debe avisar. Define umbrales según volumen.
Los reintentos deben ser idempotentes. Prueba el mismo mensaje varias veces. La recuperación después de una caída no puede crear facturas ni registros dobles.
Revisa logs con protección de datos. No guardes PDFs, NIF y direcciones completos si basta un identificador seguro. Limita acceso y retención.
Si una agencia mantiene la tienda, aclara quién produce cada componente y quién aporta declaración responsable. El cliente debe recibir documentación y versiones. El contrato debe cubrir cambios normativos y soporte.
No permitas despliegues directos a producción sin prueba de facturación. Define revisión de código o configuración para módulos fiscales. Conserva historial de cambios.
Al terminar la relación, entrega credenciales, repositorio, datos y manual de operación. Revoca cuentas. Prueba que el nuevo equipo puede atender una incidencia.
La empresa sigue siendo el obligado. Externalizar desarrollo no externaliza la decisión fiscal ni la conservación.
Hoja de control para el día del despliegue
Antes de abrir ventas, confirma copias, serie, fecha, versión, certificado, conexión con AEAT, conexión con ERP y correo. Realiza un pedido de bajo importe y sigue el flujo. Comprueba que solo aparece una factura, que el registro contiene los mismos importes y que la contabilidad recibe el identificador.
Durante las primeras horas, revisa cada lote. No esperes al cierre si la tienda tiene volumen. Mantén a desarrollo, fiscalidad y atención al cliente en un canal común con responsables claros. Registra incidencias por identificador, no mediante capturas sin pedido.
Si hay un fallo bloqueante, pausa el evento de facturación sin perder pedidos. No elimines mensajes ni vuelvas a ejecutar lotes completos sin comprobar idempotencia. Decide con fiscalidad cómo tratar documentos ya expedidos. El rollback técnico debe conservarlos.
Al final del día, concilia pedidos pagados, facturas, devoluciones, registros, cobros y asientos. Guarda resultado y decisiones. Repite durante una semana hasta que las diferencias sean conocidas y estables.
Estima facturas por minuto en campañas. Prueba la cola con volumen superior al normal. Observa tiempos de generación, envío y respuesta. El cliente no debería recibir una pantalla de error solo porque el registro tarde unos segundos si la arquitectura permite procesamiento seguro.
Resulta sensato configurar límites y reintentos sin saturar. La Orden prevé control de flujo; el proveedor debe respetar las respuestas. Un bucle agresivo puede empeorar una incidencia. Un reintento demasiado lento puede acumular horas.
Define prioridad sin romper orden temporal. No envíes una factura posterior saltando de manera indebida un registro pendiente. El sistema debe seguir la especificación y mostrar estado.
Después de la campaña, compara máximo de cola, rechazos y tiempo de recuperación. Ajusta capacidad antes de la siguiente. La observabilidad es parte de la operación, no un informe decorativo.
Clientes sin cuenta y privacidad
La compra como invitado no elimina la factura. Conserva los datos requeridos y permite acceso seguro al documento. No obligues a crear una cuenta si no existe otra razón legítima.
A menudo ayuda separar consentimiento comercial de entrega de factura. El correo usado para el documento no autoriza boletines. Configura plazos de conservación según obligaciones y evita duplicar datos en herramientas de marketing.
Si el cliente solicita corrección de datos personales, distingue el derecho de protección de datos de la integridad de una factura expedida. Rectifica donde proceda sin reescribir el histórico fiscal silenciosamente.
El RRSIF se aplica al sistema que soporta la facturación de las operaciones de la actividad del obligado incluido, también cuando ese sistema forma parte de una tienda online. Fuente oficial.
La definición de SIF comprende hardware y software que admiten, conservan y procesan información para expedir facturas. Fuente oficial.
El registro de alta debe generarse de forma simultánea o inmediatamente anterior a la expedición de la factura. Fuente oficial.
Un mismo sistema puede servir a varios obligados si diferencia sus registros y cumple por separado los requisitos para cada uno. Fuente oficial.
Las correcciones de datos registrados requieren al menos un registro adicional posterior y deben conservar inalterados los datos originales. Fuente oficial.
Desde aquí hablamos de arquitectura y operación. Son decisiones de diseño recomendadas, no frases tomadas del reglamento.
La primera decisión técnica
Dibuja cinco objetos: pedido, pago, factura, envío y rectificación. Escribe qué sistema crea cada uno y cuál es el evento de expedición. Busca duplicidades. Después solicita declaración responsable y prueba los diez casos que más alteran totales.
Consulta la guía de sistemas VERI*FACTU para pymes y utiliza el servicio fiscal-contable de TaxFactory si necesitas revisar arquitectura y reglas fiscales. Esta página contiene información general para España, revisada el 17 de julio de 2026; no sustituye el análisis de las ventas, mercados y componentes concretos.